Managing Multiple FreeBSD Machines with radmind -- Part Four
This is part Four of an N-part series (Definitely 4 parts, plus an epilogue) discussing the investigation of radmin as a patch/deployment tool for FreeBSD.
This part deals with creating and deploying patch sets using radmind. I'm assuming you already built an radmind server, created a base load and deployed it to some machine(s).
Now you just found out about a "ZOMG SUPER CRITICAL MAY CAUSE YOUR SYSTEM TO SPONTANEOUSLY COMBUST!" vulnerability in the base load, and you need to patch your systems. This is why I started looking at radmind in the first place, and it's pretty well suited to the task.
In order to build a patch set for deployment via radmind you need a machine that matches the current deployment. If you use a build server to make your radmind load sets your build server is this machine (if you don't use a build server you'll need to set up a machine and deploy your base load to it -- in either case, we're calling this machine the "build server").
Fire up your build server and do whatever needs to be done -- Typically a make world, mergemaster, portupgrade and rebuild of your local binaries if they're affected by the changes).
Now is a good time to triple-check the system and make sure that it works the way it needs to. Make sure that all your local daemons start, nothing important is broken, etc. If you don't test it now you'll be testing it live when you deploy the patch.
Patch load sets are essentially lists of what changed between a given deployment (as defined in command.K) and the current machine, so as long as your build server was current and had the latest command.K and transcript (.T) files you can build your patch load set the same way you built the base load back in Part Two, except you don't go through the process of creating negative and defaults transcripts -- just run the fsdiff -C command (against your current command.K file) and store its output as the patch transcript, then create, upload and publish the patch load set.
If you downloaded the scripts I attached to Part Two you probably noticed a script I didn't talk about, mkpatch.sh . As the name implies, this script creates a patch transcript between the command.K file and the current state of the build server (It automatically names the patch PATCH-YYYYMMDD.T and adds it to the local command.K file). The version of mkpatch I supplied doesn't do the lcreate part for you, but you can easily add an extra few lines to the script to handle that. I prefer to manually check the transcript in case it pulled in anything undesirable. Note that mkpatch.sh as written does not create any additional negative space or update negative.T and defaults.T -- any changes it sees are included as positive, managed files and the assumption is that your negative space was already defined. If you need to create more negative or defaults entries you need to create those transcripts & load sets manually and add them to command.K before you run mkpatch.sh. That's all there is to managing a FreeBSD environment with radmind. In my opinion it has simply and elegantly filled a gaping hole in the deployment and management of large-scale FreeBSD environments.
Everything I have talked about so far has been based on deployments in a test lab. We've done everything from initial deployment to OS upgrades (7.0->7.1) without breaking the universe. Our first production radmind deployments will be done later this month. Check back in early April for the Managing Multiple FreeBSD Machines with radmind epilogue with Juicy Practical Benefits™
If you downloaded the scripts I attached to Part Two you probably noticed a script I didn't talk about, mkpatch.sh . As the name implies, this script creates a patch transcript between the command.K file and the current state of the build server (It automatically names the patch PATCH-YYYYMMDD.T and adds it to the local command.K file). The version of mkpatch I supplied doesn't do the lcreate part for you, but you can easily add an extra few lines to the script to handle that. I prefer to manually check the transcript in case it pulled in anything undesirable. Note that mkpatch.sh as written does not create any additional negative space or update negative.T and defaults.T -- any changes it sees are included as positive, managed files and the assumption is that your negative space was already defined. If you need to create more negative or defaults entries you need to create those transcripts & load sets manually and add them to command.K before you run mkpatch.sh. That's all there is to managing a FreeBSD environment with radmind. In my opinion it has simply and elegantly filled a gaping hole in the deployment and management of large-scale FreeBSD environments.
Everything I have talked about so far has been based on deployments in a test lab. We've done everything from initial deployment to OS upgrades (7.0->7.1) without breaking the universe. Our first production radmind deployments will be done later this month. Check back in early April for the Managing Multiple FreeBSD Machines with radmind epilogue with Juicy Practical Benefits™
Trackbacks
No Trackbacks
Comments
Display comments as Linear | Threaded