Calling in the Foreman

For what feels like a really long time now, configuration management systems such as Puppet have been the norm. Even in a small charity I do work for I’ve had it deployed for managing the workstations.
Compared to the bad old days, life’s amazing now. Replacing and rebuilding a broadcast playout workstation that went pop took no time at all. In the past I’d be following some “how to” guide written years before and lacking the small changes we forgot to document. That would then trigger hours of troubleshooting problems.
In the workplace, we’ve got a whole host of Linux boxes that pop up for small projects. While admittedly the hosting and digital guys were all over their systems, there wasn’t quite so much consistency among the little utility boxes. Wikis, web servers and whatnot were all built by hand to fill a specific need.
When I got the chance to build a base standard for these systems, I took it. The extra insight and security alone make the project worthwhile.
So, what do you use to configure a base standard on a bunch of Linux systems? Well, it’s a configuration management system of course. The decision to go with Puppet was driven by previous experience in supporting these systems.
While Puppet does what it does amazingly well, it relies on manifests. Much the same way Munki, another system we use internally, does.
Those can be a bit painful to manage when there’s a number of one-off systems that’ll be built and configured under this system. Classes and custom modules help somewhat but it’s still a clunky process for what we do.
For that reason, I’ve called in the Foreman. Yeah, I know it’s powerful tool with all sorts of provisioning features. That said, we’ve been using it as a GUI for Puppet and it’s amazing at that.
On a side note, I’ve been working on making use of our existing WDS infrastructure to image both Windows and Linux systems. Making use of preseed/kickstart on Linux and MDT on Windows, you get one system to manage for both operating systems. Kinda neat (especially when you’ve got WDS distributing the files) and something I’ll be covering in a later article.
Back to Foreman and we’ve been making extensive use of the multiple environments it allows (off the back of Puppet). With one base configuration group, we’re able to both add new features and keep things running production.
When it comes to the actual Puppet classes themselves, the modules made available by the community have been a godsend. The Puppet forge has gotten us going with things like firewalls, SSH, log forwarding, fail2ban, enrolment in Spacewalk, and even VMware tools installations.
That said, there’s been a lot of stuff I’ve had to develop in-house. Turns out not a lot of other people are binding their Linux systems to Active Directory or deploying McAfee agents for protection.
We could get into an argument about whether AV is really required on Linux systems. On one side, there’s very little in the way of Linux viruses. On the other, we run a mixed OS environment and have seen numerous instances of malware hitting our OS X fleet.
Taking all this into account, it might seem a bit odd to be using configuration management on one off boxes. That said, the knowledge that every system built from now on will meet a minimum standard is well worth the work put in.
When you add in tools like Spacewalk and Logstash/Kibana for fleet-wide insight, I think we’re definitely on top of things now.
If you’re sitting there with your Linux powered radio station, wondering if you should use such tools – you can probably guess my answer. The ability to deploy Rivendell workstations in minutes is absolutely amazing. If only we could do that for every playout system…