Skip to content

Managing Multiple FreeBSD Machines with radmind -- Part Three

UNIX This is part Three of an N-part series (I'm thinking 4 parts, plus an epilogue) discussing the investigation of radmin as a patch/deployment tool for FreeBSD. This part deals with initial deployment of machines using radmind, and it has some prerequisites: - You need to have a target machine (a naked FreeBSD install w/ the radmind package installed) - You need to have an radmind server set up - You need to have a base load built If this is the first time you're doing an radmind deployment there is an additional requirement: You need to be willing to break the target machine (It might happen -- If there is a problem with your base load you might wind up with an unusable or even unbootable system). As with Part Two, I'm not getting into the details of how to meet the prerequisites. If you can't get FreeBSD installed and add a package you really don't belong here.
  This is the shortest post I'm going to write: Doing a load set deployment is so easy a Windows admin could do it. Assuming you used to build your base load, uploaded & published the load set and put the command.K file it generated on your radmind server all you need to do is:
# ktcheck -c sha1 -h radmind_server # fsdiff -A -c sha1 / | lapply -h radmind_server
ktcheck snags the latest version of the command.K and transcript files from the radmind server. Our old friend fsdiff, with the -A option, generates an Appliable transcript. lapply reads the Appliable transcript and wherever adds, replaces, adjusts or deletes files to make your target machine look like the build machine that generated the load set (modulo anything in the Negative space that is allowed to change locally).
Note that some things can cause lapply to freak out (and the below is by no means an exhaustive list):
  • Immutable files (uchg or schg flag) As far as I'm aware lapply doesn't understand flags - If lapply has inexplicable trouble try adding the -F option (clears flags). Most of the FreeBSD universe doesn't use flags (even the kernel isn't immutable anymore), and if you do use them you know where and why you're setting them (and can wrap lapply in a script that clears/resets them as needed).
  • Missing path constructs By default lapply errors out if it can't find a path to a target. If your transcripts are good that's not a problem, but if you somehow create an island in your transcript (a file/directory with no parents) you can pass the -C flag to lapply to make it create the parent path.
In all my testing I had no problems with clean FreeBSD 7 installs and transcripts generated using my scripts. It's possible you could create islands, but you would need to do something STUPID to make that happen (putting something in defaults.T that's deep inside the negative space defined in negative.T is suitably stupid).
That's all I have to say about deployments. The next posting will be all about making & deploying patch sets (which is why we started this whole damn thing in the first place)


mikeg's blog on : Managing Multiple FreeBSD Machines with radmind -- Part Four

Show preview
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 b


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.

Form options