Skip to content

Managing Multiple FreeBSD Machines with radmind -- Part Zero

Posted by mikeg on
UNIX This is part Zero of an N-part series (I'm thinking 4 parts) discussing the investigation of radmin as a patch/deployment tool for FreeBSD. It will be filled in over the course of Q2/2009 as we test (and possibly deploy) radmin at Premier Heart. As many (if not all) of you know, I'm a BSD Bigot - I firmly believe that the BSD projects have a huge edge over Linux on servers in all the areas that matter to me most: Performance, Security & Stability. That being said, there's one area where they suck big floppy donkey dick: Patch Management. Over the years I've had several solutions:
  1. Ignore the Problem
    Don't patch and hope you never get compromised. This has never been an acceptable solution to me.
  2. Patch Manually
    Log in to every machine in your organization once a quarter, do a Make World / Portupgrade and deal with the fallout.
    This is great if all you have are 1-2 machines, and it's how I patch bsd-box.net.
  3. Deploy a Build Server
    A central machine builds the world and ports, then you log in to each machine to install them. It's manual patching, but you don't wait for Make World to run a bunch of times.
    This is what most BSD admins do, but I'm lazier than the average admin.
  4. Deploy a Commercial Solution
    This is OK as far as it goes, but using commercial solutions puts you on someone else's patch schedule.
    Also, I'm not aware of any commercial solutions that Don't Suck™.
  5. Use freebsd-update
    While I greatly admire what the FreeBSD Security Team has done with freebsd-update, it's just not for me -- Patching my custom software and ports with freebsd-update is a pain in the ass (I would have to essentially roll a custom release - More work than I want to do.) Also, freebsd-update is geared toward applying the security team's patches, not managing system deployments - that's only half of what I want.
None of these solutions work for me, so for the last 3 years or so I've been trying to find one that does. I've examined a few options, from the traditional "let a junior admin do the patching" through writing a remote execution program to handle it. None of these give me what I need: A simple, straightforward way to go from configuration X to configuration Y without breaking anything.
radmind from the University of Michigan may be the silver bullet. The radmin suite is essentially Tripwire on crack, with the ability to push changes down to clients. It operates on the "whole filesystem" level, and basically does exactly what I want: "Make the files on server X look like the template T." The radmin suite was designed for managing (Mac OS X) computer labs, so it does the whole deploy-and-make-X-look-like-T thing well. It also appears to have the flexibility to handle server deployments and their inherent variability. The radmin tools also have the advantage of being usable for flexible deployments within the framework: Since it isn't a binary image of the system you don't have the restrictions of a dd or ghost solution (same-size disks and same-size partitions), so can size things as you see fit, provided the partitions are at least large enough to hold the deployment you're pushing out. This solution has entered testing at work -- I've built some virtual machines to run the radmin server and client, and I'm messing about with how I can make it not destroy the universe during upgrades (creative use of "negative transcripts" to keep it from updating stuff that I don't want touched - eg /opt , /usr/local/apache/{conf,htdocs} , large chunks of /etc (rc.conf, periodic.conf, pf.conf, newsyslog.conf)). There are a few shortcomings, but most of those are our environment rather than radmin:
  • We can't use it to manage the firewalls
    Our firewalls are FreeBSD+pf machines, but they have a MUCH lighter port/package load than our production servers. Firewalls shouldn't have things like Apache and Postgres installed on them, and they don't authenticate against LDAP.
  • We can't use it to manage our support servers
    Our support servers are very similar to the firewalls -- Client machines connect to them (over port 80), and then we connect to run remote assistance sessions on the client, so they're kept very much separate from our main network.
This means that every site has at least 3 machines (2 filrewalls, 1 support server) which have to be handled manually, but since that's only 3 out of 16 (assuming a minimally redundant site) we're doing pretty well.
The next part of this series will discuss the initial deployment of the radmin toolset -- Getting the client/server operating, creating the "base load" image that will be distributed.

Trackbacks

No Trackbacks

Comments

Display comments as Linear | Threaded

No comments

Add Comment

E-Mail addresses will not be displayed and will only be used for E-Mail notifications.
To leave a comment you must approve it via e-mail, which will be sent to your address after submission.

To prevent automated Bots from commentspamming, please enter the string you see in the image below in the appropriate input box. Your comment will only be submitted if the strings match. Please ensure that your browser supports and accepts cookies, or your comment cannot be verified correctly.
CAPTCHA

Form options