Skip to content

Managing Multiple FreeBSD Machines with radmind -- Part One

This is part One 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. This part deals with the basics: Getting radmind up and running on a FreeBSD system. radmind is not a complex system -- It doesn't require anything beyond a basic FreeBSD installation to run, and as a bonus it's in the FreeBSD Ports tree / package collection. I'm using the package, and you probably should too. The package can be installed on any fresh naked FreeBSD system, at which point you can use it to apply the radmin transcripts to the naked machine and deploy your custom installation. No fuss, no muss, and most importantly it's FAST. I'm not going to get into how to install FreeBSD packages - If you can't figure that out you're not ready to be reading this. Go familiarize yourself with the FreeBSD Handbook and get some real-world experience, then come back. If you're back in less than 3 months go get some MORE real-world experience - I promise you you don't have enough yet.
With your freshly installed radmin package, you now need to set up the server to start/run. There is essentially less than nothing to this if you installed the port or package:
  1. Add radmind_enable="YES" to your /etc/rc.conf file
  2. Optionally specify radmind_flags in your /etc/rc.conf file. You probably want to specify -D (the radmind root directory. Your load sets get stored here, so it needs lots of space. Defaults to /var/radmind). You may also want to specify other options as described below for SSL based authentication
Everything I talk about from here on will refer to /var/radmind as the radmind root directory because that's the default (and what I use in our test lab). Make the mental substitution if you're not using the defaults. You will then want to create a /var/radmind/config file. This file describes which load set/command file goes to which machine. The format of the file is pretty straightforward: Machine_ID [whitespace] Command_File Every machine that needs to access the radmind server needs to have a valid entry in the config file.
Machine_ID is either a reverse DNS hostname, an IP Address, or the Common Name of the Client Certificate. The wildcard * is acceptable in the ID strings, and if you have only one load set it's perfectly acceptable to have a config file that consists of one entry:
* command.K
Command_File needs to exist in order for an entry to be valid. You don't have to populate it (it can be an empty file), but if the file doesn't exist any entries referring to it won't work and the affected machine(s) won't have access to the radmind server. The syntax of command files will be discussed in the next part, but essentially it's a list of transcripts to apply (and the order to apply them in).

For my purposes, IP-based identification is "good enough" -- My radmind installation is on a closed, secure network so I'm not worried about encrypting or authenticating my traffic, and I'm dealing with servers which have static IP addresses so I don't need certs for identification. If your installation requires a bit more security, or if god forbid you are managing machines with dynamic or overlapping (!) IP addresses you'll have to enter the wonderful world of certificate-based authentication (and this is why I chased all the n00bs off before). No help will be provided with your CA/PKI woes - I assume if you're considering this you already have a CA set up for your organization with good policies and procedures, and that you have a solid understanding of how the whole PKI thing works. If you don't meet those criteria certificate-based authentication is not for you. See the note waaay at the top and come back when you've done the whole PKI thing. For those of you who need/want to use certificate-based authentication, here's the thumbnail sketch:
  • The radmind server and clients get a copy of your CA's certificate (to verify its clients) and their identifying cert in /var/radmind/cert The server's cert is like an Apache certificate (its CN needs to match the hostname of the server), the client cert CNs can be anything you want as long as they don't have whitespace -- these are what you will put in the server's config file.
  • You need to specify TLS authentication to the server and all of its clients (and the authentication you specify must match). The -w flag sets the authentication level: -w 0 is "no TLS", the default. -w 1 is Server Verification, The clients make sure the server's cert is trusted & the hostname matches. -w 2 is "Mutual Verification", -w 1 plus the server makes sure the client cert is signed by a known/trusted CA.
  • Clients need to contact the radmind server by hostname -- This implies you have DNS working (or use NIS, or are otherwise disting out a hosts file), and if you're advanced enough to be using certs for authentication you better have SOME kind of working name service.
  • You need to push out new certificates before they expire -- Expired certs implicitly fail validation because they are expired The implementation of a good system for redeploying certs is left as an exercise for the reader - you can actually use radmind to push them out as long as you do it before the certs expire...

The next part will talk about creating transcripts/load sets/command files for deployment. I even promise you some actual sample code in the form of a tarball because I know that's what you all want (fucking perverts!)


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

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

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

Michael Graziano on :

*Note that the FreeBSD port for radmind is ANCIENT (port version is 1.10.0, the latest release is 1.13.0. The port is over a year behind the last update of the code). I have a PR submitted (ports/132117) with a patch to get it updated.

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