So you’re at a conference in a foreign country, and its lunch time. The menu at the head of the table is in a language you don’t read. Now to judge the food by looks. All the food looks impossible. Even the vegetables are on the same tray as the sandwiches, all mingling with a bit too much friendliness. One dish looks like potatoes covered in a gravy dressing. Skipping over all the sandwiches, the next, dish looks like Quinoa salad, so let’s try some of that.
For the last few months I’ve been learning the Go programming language while working on various work related projects, and as I do, I reflect on the older tools and patterns that I’ve used and developed over the years and wonder if there is a better approach.
Each time I pick up a new language, every few years, I start this evaluation process. In this case, a friend from work pointed out a new static website generation tool.
Sometimes Puppet providers execute their logic based on the contents of a @property_hash, which is just a representation of a resource’s actual state. Its easy enough to test a provider for the basics, but populating the @property_hash for a unit test has always been something of a chore, and often gets skipped, leaving large portions of provider code untested. I wish I’d understood this years ago, but now that I’ve got my head round it, its pretty simple.
Using DNS to validate LetsEncrypt certificates for use on private networks
User management can be a bit of a sore subject for some admins, but I’ve found it can really pay off when done correctly, though its not always clear what that means. I’ve been on both sides of that line in the past, sometimes when the line moves, and sometimes not.
I’m a believer that managing the users and groups in your organization proficiently and with low overhead is important. It should be done well, if for no other reason, than to be able to state authoritatively who should have access to what and why, ideally requiring as little administrative time as possible once the system is in place.
Over the last year, I’ve been slowly moving some of my private Puppet code to use LDAP as a data source. Through this process, a bit of strategy, some tool and some schema has emerged I’ll share here.
It’s worth noting that Puppet has had an LDAP Node Classifier for quite some time, probably longer than I’ve been using Puppet. Though looking over the documentation, you wouldn’t know it, but the most useful bit of this whole work is that fact that Puppet supports the configuration variables necessary to make a connection to an LDAP server, and those variables are available for reference.
For the past several years, I’ve been running the majority of my lab services out of FreeBSD jails. I don’t have but a handful of services to run and some underpowered hardware to put them on, but jails have grown to become a staple in how I deploy my private infrastructure. One such service that I run is LDAP. I got a wild hare yesterday and though I’d glue the two of them together with a bit of Puppet.
I recently had some network trouble that isolated a system I use to host FreeBSD jails to be without network. The bummer of it is, that I used this particular system for hosting most of my primary working system. Things like CI and Puppet and such all lived in neat little jails, and while all the little jails and all the little services are still on disk I have no access.
Failure happens. Its a part of working in technology, and as a techno worker bee, my job is to ensure that those failures have as little impact on my team and my company as can be summoned. Part of this (as the business peeps say) “risk mitigation strategy”, is backups. Its a part of working in technology that I want to give as little attention as possible, so its important its low touch and that its done correctly and is available when I need it.
Fabric describes itself as a “library and command-line tool for streamlining the use of SSH for application deployment or systems administration tasks”. To get this work done, Fabric uses what are called “fabfiles’, which is just some python stored in a file called fabfile.py. In terms of execution, it works a lot like Rake from the Ruby world. You have a base command, in this case fab and each task is read from the fabfile.