albatrossflavour.com

Using Let's Encrypt with the Puppet Enterprise console

Thu, 30 Mar 2023 00:00:00 +0000

Had an itch I’ve been meaning to scratch for a while. I build my Puppet environment using Terraform, which makes it nice and easy to tear things down and rebuild them. That is great, but it does leave me with an issue when it comes to the console SSL certificates.

Puppet will generate self-signed certs for the console, which work fine, but it was always a niggle that the certs couldn’t be automagically coaxed into being valid.

Since moving over to kubernetes for my home lab, I’ve come to expect managed SSL certificates for any public facing services, without me having to do anything.

Finally set some time aside to look at the options and thought I’d publish the details of the journey as well as where I ended up.

Step 1 - Let’s Encrypt

Obviously I wasn’t going to reinvent the wheel. If I wanted to manage and use Let’s Encrypt on a Puppet Enterprise server, I’d be using the Let’s Encrypt module. The module makes it very simple to get the relevant packages installed and configured.

class { 'letsencrypt':
  config     => {
    email  => 'certs@albatrossflavour.com',
  },
  config_dir => '/etc/letsencrypt',
}

One of the beauties of this module is that it also sets up a cron job to renew the generated certs, so you don’t need to keep an eye on it.

Classify your server with that and you’ll end up with certbot and it’s dependencies. Great start and feeling confident about the future!

Then we need to generate a certificates:

letsencrypt::certonly { 'puppet.gcp.albatrossflavour.com':
  domains       => ['puppet.gcp.albatrossflavour.com'],
  manage_cron   => true,
  plugin        => 'webroot',
  webroot_paths => ['/var/www],
}

Annnnnnnd that’s where things start to go south.

When you request a cert, the most simple method of validating you are who you say you are is to have a web server on the host respond to a query sent to port 80. Sure we say, easy, couldn’t take much to do!

By default, the Puppet Enterprise nginx config does a 301 redirect for http requests to https. This means any queries from Let’s Encrypt to validate the requests will end up as https requests and the cert request will fail.

Step 2 - `nginx`

Let me introduce you to puppet_enterprise::profile::console::proxy::http_redirect::enable_http_redirect. This parameter controls if that redirect is in place. So step …. 6(?) was to use hiera to disable the http redirect:

❯ cat data/role/role::pe::master.yaml
puppet_enterprise::profile::console::proxy::http_redirect::enable_http_redirect: false

Once we run this through a puppet run, the redirect gets removed! Score!

Only problem is, without the redirect, the nginx server doesn’t listen on port 80. OK, we can fix that easily. We could use the pe_nginx::directive type, but I found it to be a bit of an overkill for what I needed. Instead I opted for a simple template:

  file { '/etc/puppetlabs/nginx/conf.d/certs.conf':
    ensure  => file,
    owner   => 'root',
    group   => 'root',
    mode    => '0644',
    content => template("${module_name}/cert_vhost.conf.erb"),
    notify  => Exec['pe_nginx'],
  }

and the template is just:

server {
  listen       80;
  server_name  <%= @fqdn %>;
  index        index.html;
  location /.well-known {
    root /var/www;
  }
  location / {
    return 301 https://$server_name$request_uri;
  }
}

(Sorry, still using erb, I will at some point rewrite everthing in epp)

The template keeps the 301 redirect in place for anything other than a request to /.well-known, which is where Let’s Encrypt looks for the validation info.

Run this through and the nginx vhost gets created. However the letsencrypt::certonly call still fails on the first run. The notify to the pe_nginx service, which is done when we create the cert_vhost.conf, doesn’t happen in the order we need. The Let’s Encrypt module is trying to get a response before we’ve setup the vhost. Now this would work on subsequent runs, but Golden Rule #1 is to make sure, whenever possible, that you get a clean puppet run in one pass. Plus this was a challenge.

Before I worked on fixing that, I wanted to make sure I could make the rest of it work. Let’s sum up where we are:

I’ve got the Let’s Encrypt client installed and configured
I’ve got a new nginx vhost running that allows the Let’s Encrypt web validation queries through and redirects any other http traffic.
After a couple of puppet runs, I’ve got valid SSL certs in /etc/letsencrypt

Step 3 - The console certs

It’d been a while since I played with the Puppet console SSL certs, so I checked in with the source of truth, which outlines the steps we need to go through to use custom SSL certs with the console:

Retrieve the custom certificate and private key.
Move the certificate to /etc/puppetlabs/puppet/ssl/certs/console-cert.pem, replacing any existing file named console-cert.pem.
Move the private key to /etc/puppetlabs/puppet/ssl/private_keys/console-cert.pem, replacing any existing file named console-cert.pem.

So we can just create a file resource that takes the Let’s Encrypt cert/key and places them into the console SSL directory structure.

  file { '/etc/puppetlabs/puppet/ssl/certs/console-cert.pem':
    ensure    => file,
    owner     => 'pe-puppet',
    group     => 'pe-puppet',
    links     => 'follow',
    mode      => '0640',
    source    => "/etc/letsencrypt/live/${facts['puppet_server']}/cert.pem",
    backup    => '.puppet_bak',
    notify    => Service['pe-nginx'],
    subscribe => Letsencrypt::Certonly[$facts['puppet_server']],
  }

  file { '/etc/puppetlabs/puppet/ssl/private_keys/console-cert.pem':
    ensure    => file,
    owner     => 'pe-puppet',
    group     => 'pe-puppet',
    links     => 'follow',
    mode      => '0644',
    source    => "/etc/letsencrypt/live/${facts['puppet_server']}/privkey.pem",
    backup    => '.puppet_bak',
    notify    => Service['pe-nginx'],
    subscribe => Letsencrypt::Certonly[$facts['puppet_server']],
  }

Sure enough, when I try this on the Puppet server, life is good and we have a console with valid SSL certs.

Time to crack open a bottle of red and tick an item off my to do list.

Damn it, Golden Rule #2 raises it’s head. It’s not finished until you know it works fine from scratch… WITHOUT breaking Golden Rule #1.

Step 4 - Rebuild

Nuked the Puppet server and rebuilt it. Lots of failures on the first run (we kinda expected that), however they didn’t go away. The nginx service never gets restarted as the various dependencies can be resolved, but not in the way we need.

This is the fun (?) of declarative configuration management. I can only manage things once, which includes only being able to notify the pe-nginx service once. Then the compiler will figure out when the service is restarted, based on all of the dependencies in the catalog.

I played around with a lot of options, some waaaaay hackier than I wanted to go with. Plus this was becoming a fun exercise.

All I needed to be able to do was to inject a restart of the pe-nginx service twice in a single run.

To get there, I bent a few of the future Golden Rules and came up with:

exec { 'restart_nginx':
  command     => '/bin/systemctl restart pe-nginx',
  refreshonly => true,
}

This exec resource will allow me to do a restart of pe-nginx outside of, and before, the notify => Service['pe-nginx'] parameters.

Yes, it’s a hack, but it’s a hack on the side of the angels. Not only will it solve the issue of the process not working at all, but it will also allow the certs to be generated, and installed, in a single run.

Step 5 - Quick Robin, to the `pdk` mobile

I did a fair bit of testing and found the end result to be far more reliable and useful than I thought it would be.

I first created a fully parameterised profile to manage the certs. Once I got that working, it was a no-brainer to create a module to share the love.

That’s how I ended up with the pe_console_letsencrypt module. You can also just check out the code.

I’ve done a fair bit of testing, but I’m certainly not saying it’s bulletproof.

Step 6 - Profit?

I’m still scratching my head to think of another way I could get the certs generated and in place in a single run without the exec hack. That being said, I’ve had hacks a lot worse go live in the past!

Note

While researching the links for this post, I came across a blog less frequently updated than mine which has a post from 2017 showing a similar way of achieving the same thing, but without the hack to make it work in a single run.

os_patching in the news

Tue, 25 Jun 2019 00:00:00 +0000

I’ve been working on an article about my puppet os_patching module for a while. I finally finished it a couple of weeks ago and it’s been picked up by https://jaxenter.com.

It feels great to be able to write and talk about the things I’m working on. That’s one of the biggest changes since leaving $old-job.

Moving to github pages

Tue, 28 May 2019 00:00:00 +0000

I’ve moved the site over to Github pages, it’s early days but I’m really enjoying being able to manage the whole site as a plain text repo.

Everything had been hosted on Squarespace for years. While the platform is great, it offered a lot of power where I didn’t need it and didn’t offer the features I did want.

Since I’m trying to resurrect the site, I thought it’d be good to be able to have a base platform that I feel happy with and one that doesn’t lock me into a hosting provider. Github pages offers integration with Jeykll which has made my migration so much easier. It also allows for the use of custom domains rather than using the $yourname.github.io.

Getting the old site redirects into place took a bit of effort and I’m not 100% sure I’ve nailed all of them, but I’m pretty happy with how things are going so far. I’ve played around with customising the theme, it’s not where I want it to be yet, but it feels a lot more like what I want already.

Using Terraform and Puppet Bolt together ... Terrabolt? Boltform?

Sun, 26 May 2019 11:34:29 +0000

I was playing around with Terraform and GCP the other day to run up a couple of different environments. It niggled me that I needed to hack around to get my instances working with Puppet, sure it was only a provisioning script, but it still lacked elegance.

A bit of google-fu led me to Lucy Wyman’s awesome post about combining Bolt and Terraform. I spent a while diving into how Lucy had set things up and I was really impressed, it was fairly easy to adapt that workflow to what I was looking for.

A few days of effort later and I had a single bolt plan which would call terraform to provision the infrastructure and then use bolt to apply all of the configuration. It was neat, but a little loquacious when it came to adding nodes to the inventory.

Lucy’s (and the one I used too) used the following code to build the inventories.

plans/build_pe.pp

run_command("cd ${$tf_path} && terraform apply", $localhost)

$ip_string = run_command("cd ${$tf_path} && terraform output public_ips", $localhost).map |$r| { $r['stdout'] }

$ips = Array($ip_string).map |$ip| { $ip.strip }

# Turn IPs into Bolt targets, and add to inventory
$targets = $ips.map |$ip| {
  Target.new("${$ip}").add_to_group('terraform')
}

inventory.yaml

groups:
  - name: terraform
    nodes: [] # This will be populated by the Bolt plan
    config:
      transport: ssh
      ssh:
        private-key: ~/.ssh/id_rsa-phraseless
        user: ubuntu
        host-key-check: false

Not a huge problem to iterate over that for different inventory groups, but the lack of elegance still bothered me, but it was a great solution and the best that could be done. Sorry, that should be “and was the best that could be done”.

On the 17th May Bolt V0.20.0 was released. The feature that really caught my eye was :

A new plugin in inventory v2 loads Terraform state and map resource properties to target parameters. This plugin enables using a Terraform project to dynamically determine the targets to use when running Bolt

The inventory file changes were straight forward and made life far easier going forward.

I decided to try setting up a moderately complex set of infrastructure which could be setup with as few moving parts as possible. My idea was to do a full Puppet Enterprise deployment, including :

Puppet Enterprise Master
PE HA replica
Compilers behind a load balancer
Continuous Delivery for Puppet Enterprise (CD4PE)
Workers for the CD4PE

The terraform side looks like this :

pe.tf

resource "google_dns_managed_zone" "frontend" {
  project    = "puppet"
  dns_name   = "gcp.example.com."
  name       = "gcp-example"
  visibility = "public"
}

resource "google_dns_record_set" "frontend" {
  project      = "puppet"
  name         = "puppetmaster.gcp.example.com."
  managed_zone = "gcp-example"
  rrdatas      = ["${google_compute_instance.master.network_interface.0.access_config.0.nat_ip}"]
  ttl          = "300"
  type         = "A"
}

resource "google_compute_firewall" "puppet" {
  project = "puppet"
  name    = "pe-master"
  network = "${google_compute_network.pe-network.name}"
  target_tags = [ "pe-master" ]
  allow {
    protocol = "tcp"
    ports = [ "22", "5432", "443","8140","8142","8143","8170","4433","8123","8080","8081" ]
  }
}

resource "google_compute_network" "pe-network" {
  project                 = "puppet"
  name                    = "pe-network"
  auto_create_subnetworks = "true"
}

resource "google_compute_instance" "master" {
  project      = "puppet"
  zone         = "australia-southeast1-b"
  name         = "master"
  machine_type = "n1-standard-4"
  boot_disk {
    initialize_params {
      size = 30
      image = "centos-cloud/centos-7"
    }
  }
  network_interface {
    network       = "${google_compute_network.pe-network.self_link}"
    access_config = {
    }
  }
  lifecycle {
    ignore_changes = [ "attached_disk" ]
  }

  tags = [ "pe-master", "https-server" ]

  metadata = {
   "sshKeys"        = "tony_green:${file("~/.ssh/gcp.pub")}"
   "enable-oslogin" = true
  }
}

resource "google_compute_instance" "compiler" {
  count                     = 3
  allow_stopping_for_update = true
  project                   = "puppet"
  zone                      = "australia-southeast1-a"
  name                      = "compiler-${count.index + 1}"
  machine_type              = "n1-standard-2"
  boot_disk {
    initialize_params {
      image = "centos-cloud/centos-7"
    }
  }
  network_interface {
    network       = "${google_compute_network.pe-network.self_link}"
    access_config = {
    }
  }

  tags = [ "compiler", "pe-master" ]

  metadata = {
   "sshKeys"        = "tony_green:${file("~/.ssh/gcp.pub")}"
   "enable-oslogin" = true
  }
}

resource "google_compute_instance" "cd4pe" {
  project      = "puppet"
  zone         = "australia-southeast1-a"
  name         = "cd4pe"
  machine_type = "n1-standard-4"
  boot_disk {
    initialize_params {
      size = 30
      image = "centos-cloud/centos-7"
    }
  }
  network_interface {
    network       = "${google_compute_network.pe-network.self_link}"
    access_config = {
    }
  }

  tags = [ "pe-master", "cd4pe", "https-server" ]

  metadata = {
    "enable-oslogin" = true
    "sshKeys"        = "tony_green:${file("~/.ssh/gcp.pub")}"
  }

  depends_on = ["google_compute_instance.master"]
}
resource "google_compute_instance" "replica" {
  project      = "puppet"
  zone         = "australia-southeast1-a"
  name         = "replica"
  machine_type = "n1-standard-4"
  boot_disk {
    initialize_params {
      image = "centos-cloud/centos-7"
    }
  }
  network_interface {
    network       = "${google_compute_network.pe-network.self_link}"
    access_config = {
    }
  }

  tags = [ "pe-master", "https-server" ]

  metadata = {
    "enable-oslogin" = true
    "sshKeys"        = "tony_green:${file("~/.ssh/gcp.pub")}"
  }

  depends_on = ["google_compute_instance.master"]
}

resource "google_compute_instance_group" "compiler-cluster" {
  project     = "puppet"
  name        = "compiler-cluster"
  description = "Terraform test instance group"

  instances = [
    "${google_compute_instance.compiler.*.self_link}"
  ]

  named_port {
    name = "puppet-8140"
    port = "8140"
  }

  named_port {
    name = "puppet-8142"
    port = "8142"
  }

  zone = "australia-southeast1-a"
}

resource "google_compute_forwarding_rule" "compiler-forwarding-rule" {
  project               = "puppet"
  name                  = "compiler-lb"
  load_balancing_scheme = "INTERNAL"
  network               = "${google_compute_network.pe-network.name}"
  backend_service       = "${google_compute_region_backend_service.compiler-lb.self_link}"
  ports                 = [ "8140", "8142" ]
  region                = "australia-southeast1"
}

resource "google_compute_region_backend_service" "compiler-lb" {
  project          = "puppet"
  name             = "compiler-lb"
  protocol         = "TCP"
  timeout_sec      = 10
  session_affinity = "NONE"
  region           = "australia-southeast1"

  backend {
    group = "${google_compute_instance_group.compiler-cluster.self_link}"
  }

  health_checks = ["${google_compute_health_check.compiler-healthcheck.self_link}"]
}

resource "google_compute_health_check" "compiler-healthcheck" {
  project            = "puppet"
  name               = "compiler-healthcheck"
  check_interval_sec = 5
  timeout_sec        = 5

  tcp_health_check {
    port = "8140"
  }
}

output "master_ip" {
  value = ["${google_compute_instance.master.network_interface.0.access_config.0.nat_ip}"]
}

output "compiler_ip" {
  value = ["${google_compute_instance.compiler.*.network_interface.0.access_config.0.nat_ip}"]
}

output "replica_ip" {
  value = ["${google_compute_instance.replica.network_interface.0.access_config.0.nat_ip}"]
}

output "cd4pe_ip" {
  value = ["${google_compute_instance.cd4pe.network_interface.0.access_config.0.nat_ip}"]
}

The bolt plan and inventory look like this :

inventory.yaml

---
version: 2
groups:
  - name: master
    target-lookups:
      - plugin: terraform
        dir: ~/dev/terraform_puppet
        resource_type: google_compute_instance.master
        uri: network_interface.0.access_config.0.nat_ip
  - name: replica
    target-lookups:
      - plugin: terraform
        dir: ~/dev/terraform_puppet
        resource_type: google_compute_instance.replica
        uri: network_interface.0.access_config.0.nat_ip
  - name: compilers
    target-lookups:
      - plugin: terraform
        dir: ~/dev/terraform_puppet
        resource_type: google_compute_instance.compiler
        uri: network_interface.0.access_config.0.nat_ip
  - name: cd4pe
    target-lookups:
      - plugin: terraform
        dir: ~/dev/terraform_puppet
        resource_type: google_compute_instance.cd4pe
        uri: network_interface.0.access_config.0.nat_ip
config:
  transport: ssh
  ssh:
    private-key: ~/.ssh/gcp
    user: centos
    host-key-check: false
    run-as: root

plans/build_pe.pp

plan terraform_puppet::build_pe(
  String $tf_path,
) {

  $localhost = get_targets('localhost')
  run_command("cd ${$tf_path} && terraform apply --auto-approve", $localhost)

  # Pull targets out of terraform, configured in the inventory.yaml file
  $master = get_targets('master')
  if $master.size != 1 { fail("Must specify a single master, not ${master}") }

  $replica = get_targets('replica')
  if $master.size != 1 { fail("Must specify a single master, not ${master}") }

  $cd4pe = get_targets('cd4pe')
  if $master.size != 1 { fail("Must specify a single cd4pe, not ${cd4pe}") }

  $compilers = get_targets('compilers')

  # Transfer installer scripts to the master and do the install
  upload_file('~/dev/terraform_puppet/provision','/tmp/provision',$master)
  run_command('/tmp/provision/setup.sh',$master, '_run_as' => 'root')

  # Install the agent on the replia
  run_command('curl -k https://master.c.puppet.internal:8140/packages/current/install.bash | sudo bash -s -- --puppet-service-ensure stopped',$replica, '_run_as' => 'root')
  run_command('/opt/puppetlabs/bin/puppet agent -t || exit 0',$replica, '_run_as' => 'root')

  # Configure the replica
  run_command('/opt/puppetlabs/bin/puppet-infrastructure provision replica replica.c.puppet.internal',$master, '_run_as' => 'root')

  # Install the agents on the compilers
  run_command('curl -k https://master.c.puppet.internal:8140/packages/current/install.bash | sudo bash -s main:dns_alt_names=puppet.example.com',$compilers, '_run_as' => 'root')
  run_command('/opt/puppetlabs/bin/puppet agent -t || exit 0',$compilers, '_run_as' => 'root')
  run_command('/opt/puppetlabs/bin/puppet agent -t || exit 0',$master, '_run_as' => 'root')

  run_command('curl -k https://master.c.puppet.internal:8140/packages/current/install.bash | sudo bash -s -- --puppet-service-ensure stopped',$replica, '_run_as' => 'root')
  run_command('/opt/puppetlabs/bin/puppet agent -t || exit 0',$replica, '_run_as' => 'root')

  # Install the agent on cd4pe
  run_command('curl -k https://master.c.puppet.internal:8140/packages/current/install.bash | sudo bash -s -- --puppet-service-ensure stopped',$cd4pe, '_run_as' => 'root')
  run_command('/opt/puppetlabs/bin/puppet agent -t || exit 0',$cd4pe, '_run_as' => 'root')

  run_command('/opt/puppetlabs/bin/puppet task run pe_installer_cd4pe::install cd4pe_admin_email="puppet@example.com" cd4pe_admin_password="p@ssword" -n cd4pe.c.puppet.internal', $master, '_run_as' => 'root')
}

The step to provision PE just copies up a script to download the latest version of Puppet Enterprise, untar it, and run the setup with a custom pe.conf to get things like code manager working.

What worked

In under 30 mins I can go from not having any PE infrastructure to having a full HA master, compile masters and CD4PE. Everything other than CD4PE is fully automated and is running in it’s final state by the end of the process.

This was a proof of concept for me, using PE as it’s a platform I’m very familiar with. Adapting it other applications is trivial.

What didn’t work

Getting started with the dynamic inventory was tricky, however it turns out the problem was because I was using a remote backend for my terraform state. Mine was stored on GCP storage, so the terraform.state file just contained a pointer to the remote storage, so the new bolt plugin didn’t work. Once I moved back to local state storage (not something I want to do long term) everything “just worked”.

I need to look into that in more detail and talk to the Bolt team to see if there’s something that I’m missing.

The plugin also needs to have the terraform state in place before the plan starts, so having the terraform apply command inside the plan won’t work on the first run and may not work correctly on subsequent runs. Again, this isn’t a huge problem and could be something that I’m doing wrong or a feature that will be added in future.

I’m looking forward to seeing the CD4PE setup get a bit more puppetized. It’s still a fair bit of pointy clickyness once you have it installed.

What’s next?

I’m still pretty new to terraform and I know there’s a lot of duplication in my code, I’m going to clean that up next.
I’m not happy with the way I’m using bolt to do the install of the puppet agents on the nodes. I know I could just use the prep function, but that just installs the agent, it doesn’t point it to the puppet master (at least as far as I could tell). I’ll look into how I can make that nicer.
Using terraform import to pull state information out of existing infrastructure so that I can use bolt to mange it

Conclusion

Bolt continues to go from strength to strength. The dynamic inventory (currently supporting terraform and PuppetDB connections) really makes life a lot easier.

Since you can drive bolt off your existing puppet control repository, you can get even more creative with how you stand up and manage infrastructure.

This process could easily work with a mixed-vendor/hybrid cloud environment.

@waiting for, @agenda, delegation and OmniFocus

Sat, 04 Jun 2016 11:34:29 +0000

There was a kink in my workflow for OmniFocus for quite a while, I could never find the right way to handle items I’ve delegated to or need feedback from others on. There are dozens of different workflows that I’ve seen out on the interwebs but none of them fitted right.

I’ve slowly changed role at $work over the last couple of years, from being a full time techie to running a (growing) team. I was finding having a single @waiting-for context didn’t scale, I tried putting tagging into the task summary but that didn’t allow me to see things at varying levels.

What finally worked for me is to nest some contexts like this:

By nesting in this way, I do a couple of things which are important to me. Firstly, any items I need to talk to John Doe about will sit in the base “John Doe” context. Secondly, any items which I need John to come back to me on will sit in the “WF: John Doe” context.

This simple change to my workflow means I can simply select one context (“John Doe”) and see both the items I need to talk to John about and the items I’m waiting for him on.

When taken to the next level, it becomes even more powerful. By continuing the nesting idea, you can give more structure to your agenda contexts:

Now I have layers to the agendas. I can select the “Engineering team” context if I want to see every task I have that involves that team, from individuals to the meetings. I can also drill down to individuals to see the micro view.

When used with the new OmniFocus “quick open” function, you get REALLY fast access to the data you need at whatever level you need to see it at. It makes it easy when I catch up with anyone to pull up a list of what I could ask them and what they’re supposed to be coming back to me on.

The down side is you end up with a lot of contexts. I have almost 100 at the moment, 80 of them nested under my base “Agenda” context. I’ve not noticed a performance issue from doing it though and the payoff is more than worth the potential clutter.

Inside OmniFocus by OmniGroup

Wed, 02 Jul 2014 11:34:29 +0000

I was stunned to find that the OmniGroup mentioned my project layout post on the new Inside OmniFocus Collected page. OmniGroup have always been great at building a community around their products, it’s great to see them pulling together some tricks and tips into a portal like this.

OmniFocus Quick Wins

Fri, 13 Jun 2014 11:34:29 +0000

Could it be? Yes, it is, another OmniFocus workflow post.

This is an evolution of the classic 2 minute rule that is a core part of the GTD workflow.

I’ve been struggling finding free time at $work to be able to work off my lists. We’re down a few people and are busier than usual at the moment, so things are starting to back up.

While I’m not dropping things, I’m certainly seeing a build up in my action lists at the moment.

I started paying attention to where and when I was able to find slots of time to action things off my lists. They tended to fall into the following categories:

5 minute window because people hadn’t turned up for a meeting
15-30 minute window because either a meeting had been cancelled or I didn’t have back to back meetings for some reason (yes, it was that bad)
60 minute windows, usually when I get in early

There are a few limiting criteria when choosing the tasks you can work in when you follow the . You have:

Context (phone/office/agenda/errands etc.)
Energy available
Time available

There is an option in OmniFocus to include details of estimated time in actions. You might have a phone call to make that you know will only be 5 minutes, but another that will take at least 30. Having that information available to you helps when you know you’re short of long stretches of time.

By putting the estimated effort into these tasks, you can create a perspective which shows all tasks that can be completed within defined times.

Once you have this in place, you can use this “Quick Wins” perspectives to see your tasks, ordered in the time it’ll take you to do them.

One thing to be careful of is that tasks WITHOUT an estimated date will not show up in the “Quick Wins” perspective.

I’ve been using this for a while and it’s really helped me make use of the small bits of time that crop up. It’s amazing how many projects you can push forward with just a few minutes of action.

OmniFocus Project Layout

Tue, 10 Jun 2014 11:34:29 +0000

We’ve been having a lot of discussions about Omnifocus at the Sydney GTD Meet-Up over the last few weeks. One of the common questions is around how to lay out the projects view.

OmniFocus gives you a lot of flexibility in how you arrange your projects, giving you folders and nesting as ways of customising things.

Over the years, I’ve played around with many different ways of laying things out. It was about 12 months ago that I hit on my current layout that works really well for me.

Being an avid GTDer I have a mindmap which lists my areas of focus. These are the key areas of your life that will be the focus of your projects and next actions.

You might want to think about these are the different hats we wear in different parts of our lives. This is an excerpt of my areas of focus:

Work
- Management
  - Budgets
  - Training
  - Strategy and roadmaps
  - Communication and PR
- Service Improvement
- Projects
- Monitoring and reporting
- Personal Development
Personal
- Family
- Health
- Personal Development
- Jobs around the house
- Administration
- Finance
- Holidays and recreation

I found that if I laid out my folder structure in OmniFocus in the same way, I could accomplish two things. Firstly, I could use the structure as part of my weekly review. Because all of the projects would appear under the relevant area of focus, I can tell at a glance if there is an area that I’m not focusing on enough.

This happened to me in the last few days. I did my review and noticed that I didn’t have any projects in my budget folder - yet we’re fast approaching budget season.

The second reason is a bit more subtle but, in my opinion, more powerful. Unless you have put a due date on a project or action, the context view will list tasks in a set order. That order is the order they appear in the projects list.

That means, all things being equal, tasks for projects in my Management folder will appear higher up the next action list than tasks for projects in my Monitoring and reporting folder.

For example. I have two phone calls to make, one to book in a budget meeting (area of focus == budget) and one to talk to a project manager about resourcing (area of focus == project). If neither of the tasks or projects have due dates, the call about the budget meeting would appear above the call to the project manager.

This means you can arrange your folders with a pseudo level of importance. This helps a lot if you’re working off larger next action lists. It doesn’t remove any other filtering or sorting you may do, just adds another metric to assess your next action decisions against.

This workflow is valid in all versions of OmniFocus (Mac and iOS)

Digital Tickler File on macOS Using Hazel

Wed, 14 Aug 2013 11:34:29 +0000

I’ve never really found a place in my physical life for a tickler file in my Getting Things Done workflow, they seem like a great idea but I have no real world paper to manage.

When carrying out GTD training, I’m often asked if there is digital equivalent of a tickler file. I’m usually training fairly technical people who’re trying to embrace the paperless lifestyle, the idea of having a draw dedicated to 43 folders and having to remember to check it isn’t that appealing. Tickler files only work if you have the discipline to check them daily.

There are various ways to fake a tickler file, some of which I use already. My current method is to put a link to the file I want “tickled” into [Omnifocus][http://omnifocus.com] with a start date of the day I want to see it. That works pretty well and certainly gives the desired (fully automatic) result.

Well, this would be a pretty short post if that was the end of it….. But it’s not.

I was over in Houston doing training a couple of weeks ago and the topic of tickler files came up again. We discussed the idea of having a digital version of the tickler and some people though it would be really useful. I put a loop into Omnifocus’s inbox and didn’t think too much more about it.

A few days later I was at the airport processing my inbox while waiting to board. I got to the inbox item “Digital tickler files?” and when I got to the standard GTD question of “is it actionable?” I decided, “yes, it is”.

I spent the next couple of hours figuring out how to setup a fully automated tickler file system on a Mac using a wonderful tool called Hazel. For those of you who (for some unknown reason) don’t know what Hazel is, I’ll quote their website : “Hazel watches whatever folders you tell it to, automatically organizing your files according to the rules you create.”

I use Hazel extensively to manage my files, handle my filing, organise my backups and perform housekeeping on my directories, amongst many other things. I figured if there was a tool that could take care of the hard work involved in a digital tickler file, Hazel would be it.

What I’ve come up with is a couple of rules that take your files and put them under a tickler directory structure, which Hazel manages. The rules also then “untickle” the files on the day that you’ve requested them back, moving the files back into a specified directory.

Enough waffling, let’s get into how you can set this up. Firstly, obviously, you need a Mac running the Hazel. At the time of writing this I’m running version 3.1.3 of Hazel, I’d recommend a recent version as one of the conditions (Current Time) was only recently added to the product.

You need to decide two things, which directory will be your “inbox” and which directory will contain your “tickle” directory. I use my Downloads folder as an inbox and put the tickle directory on Dropbox under $user/Dropbox/Documents/tickle. You can obviously change these to suit your setup.

You then need to download the rules and import them into Hazel. The rule “Downloads” needs to be associated with your chosen inbox folder, the rule “tickler” needs to be associated with your chosen tickle folder.

Once those files are in place, you can start testing. Easiest initial test is to add a filename suffix to a file in your inbox. Hazel will look for anything that has a filename that ends in - tickle MMM DD (e.g. example - tickle Jan 01.txt). Hazel will strip out the - tickle MMM DD and put the file into your tickle folder in a structure like this tickle/MMM/DD. You can use textexpander to automate the addition of the suffix, there is a snippet in the download which will help you out.

Once the file is in the tickle structure, you can safely forget about it. On the day you’ve chosen, the file will automagically be placed back into your chosen inbox folder, ready for you to work on it.

I’m actively developing the code, but it seems pretty solid at the moment. You can download the code from my GitHub site.

If you have any comments, suggestions or problems, feel free to e-mail me.

Monospace font joy

Tue, 30 Apr 2013 11:34:29 +0000

I really love writing in a decent mono-spaced, non-serif, font. From hacking in the vim to writing Markdown in nvAlt, having a nice font seems to make things just a little more motivating.

There’s a great article which I’ve just read which gives you the chance to view the best programming fonts, including a sample of code.

Source Code Pro has edged ahead (yes, there’s a vote!) but I’m glad to see a few new mono-spaced friends I can add to my list.

albatrossflavour.com

Using Let's Encrypt with the Puppet Enterprise console

Step 1 - Let’s Encrypt

Step 2 - nginx

Step 3 - The console certs

Step 4 - Rebuild

Step 5 - Quick Robin, to the pdk mobile

Step 6 - Profit?

Note

os_patching in the news

Moving to github pages

Using Terraform and Puppet Bolt together ... Terrabolt? Boltform?

plans/build_pe.pp

inventory.yaml

pe.tf

inventory.yaml

plans/build_pe.pp

What worked

What didn’t work

What’s next?

Conclusion

@waiting for, @agenda, delegation and OmniFocus

Inside OmniFocus by OmniGroup

OmniFocus Quick Wins

OmniFocus Project Layout

Digital Tickler File on macOS Using Hazel

Monospace font joy

Step 2 - `nginx`

Step 5 - Quick Robin, to the `pdk` mobile