Managing Multiple FreeBSD Machines with radmind -- Part Three
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 mkbase.sh 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:
Note that some things can cause lapply to freak out (and the below is by no means an exhaustive list):
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)
# ktcheck -c sha1 -h radmind_server # fsdiff -A -c sha1 / | lapply -h radmind_serverktcheck 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.
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)
Trackbacks
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
Comments
Display comments as Linear | Threaded