Radmind For Os X [PORTABLE]
See, it's possible to forge a FQDN (or something like a man in the middle attack), but it is suppose to be technically impossible to produce a C unless you have A, and A is the super secret guarded key and should never be put on the internet. That's how a computer proves it is who it says it is. This is how radmind uses certificates.
Radmind For Os X
Radmind has multiple authorization levels. This article is going to discuss 2 levels, aptly named 1 and 2. To set the authorization level, you add -w followed by the level to all radmind tools that do network communication, e.g. ktcheck, lapply, lcreate, radmind. Therefore I'll call the 2 levels "-w1" and "-w2".
This directory can be on any computer or any path, but it's easier to keep it on the radmind server at /var/radmind/CA. This folder isn't required by radmind, it's required to create and update certs. It's easiest to put it on the radmind server because then you can just cp the files around on the same machine.
This command is interactive and requires you to enter in the passphrase and the other information like your location and organization. If you edited openssl.cnf correctly than you can just hit return for the default values for almost all of the questions. Do not forget the passphrase!! For Common Name (CN), use the FQDN of the server. If your server is radmind.example.com, then enter that for the CN. This will produce 2 files, private/CAkey.pem and ca.pem.
The ca.pem file goes on the clients at /var/radmind/cert/ca.pem. To prevent radmind for deleting the file repeatedly, you need to either ignore the path or put the path in an exclude, or you need to create an overload of the file, which is what I suggest because then you can use radmind to distribute the file (best method).
If you need another way to distribute the file use ARD to copy the file to each client. Or you could put the file on a flash disk and walk around and copy it to each computer (yuck). Or you could scp the file to each machine (if you have sshd running on the radmind server). To make scp easier, I actually create symlinks from /certs/ to the overloads.
Make sure you are in the CA directory and then run these commands. Enter in the same information that you used when you created the CA. Again, use your radmind server FQDN for the Common Name (like radmind.example.com). When asked, enter the passphrase. It will display the information in the CA and ask if you want to sign the certificate (that is the whole point). If the CA information is correct then type "y". This will also update the index.txt file to record that a certificate has been signed.
If you have more than one radmind server, a really easy way to handle the server cert is to give each one a different name and sync them with something like rsync. Just add /var/radmind/cert to the directories you sync.
If you are already running radmind without certificates then it is probably running on port 6222. It is a good idea to create a second instance of radmind using certificates on a different port so that each can run at the same time. And it helps to transition back and forth if you have both setup to run. If you decide to get rid of the -w0 version, then you can do it and keep the config files around as a backup.
If you have more than one radmind server and are not using the default cert path, you need to specify the custom path with the -y and -z options. This is what the manpage for radmind says about -y and -z.
But I thought I would at least share some perl code that I use to select the radmind server. Basically it has 3 lists of servers, one list for each authorization level. Each list contains the hostname or ip of a server and the port that supports that authorization level.
The point of the code is to try to connect (first a syn ping and then a repo command) to servers starting with the most secure -w2 and if that doesn't work, then -w1, and if that doesn't work to fall back to -w0. This way, if you setup all of this and if for some reason authorization doesn't work in the future, you can just kill the process on the radmind server that runs authorization and start the daemon without authorization and your clients will fall back to that. Of course, if you don't want to fall back, just leave a particular list empty and it wont try it.
Second, you need to have at least 2 partitions on your test computers with 2 bootable operating systems on each. They can both be managed by radmind or not. Either way, if you get into radmind too much, you're bound to accidentally make one of those partitions upbootable at least once if not more. Having the 2nd bootable partition makes fixing it so much easier and faster.
I have written a whole blog post to recovering a computer and you should know all of these methods. The braver you get with radmind, the more likely you'll kill a computer. I've killed so many computers using radmind it's not even funny. It's forced me to learn how to fix them quickly (well, the worst case is me walking around with a firewire drive to each computer). But the benefit of being able to fix the computers quickly is that it made me quite brave (wreckless?) and so I can push out changes with radmind very quickly.
There are two ways to use the command line on the radmind server. You can ssh into the radmind server, or you can mount the radmind volume using afp/smb and then use the Terminal on your local box and change directory to the mounted volume. The advantage of ssh'ing into the server is everything is faster. The advantage of using the mounted volume is that you can drag files from the Finder to the Terminal to get their paths.
In my command folder I have all of my machine command files (any command file that is listed in /var/radmind/config) in a folder named /var/radmind/command/machine. If I have a kink (k-in-k or commandfile in a commandfile) then I put it in a different folder named after function like "os", "software", "config", etc.,.
I have no idea if you can use git or some other version control to create this kind of branching. It would require far more git knowledge and skill than I've got to do it. And this is such a non-standard why of using git that I don't think anyone ever really discusses it. I once asked a coworker who understood git pretty well to set it up and he couldn't simply because this is such a crazy setup from the perspective of git. This is basically why I don't use git or any other version control with my radmind setup except (cringe) Time Machine.
Put the new overload in the dev command file and run radmind on the test computer. When you know there are no problems with the transcript update the stable branch with the new command file. This is how you avoid most errors.
If you are making major changes to all of the overloads, then yes, duplicate everything in /var/radmind/transcript and /var/radmind/file. I realize this will take forever and will take a lot of hard disk space. However, if you are changing all of the overloads, and you want to avoid errors, you pretty much have to do this. I've tried so many tricks to avoid duplicating the whole thing and I always screw it up, every single time.
If you use sub directories on your radmind server for both command and transcript then you don't always have to search through everything (speeds up searches). For example, if I'm looking for all of the transcripts that specify /etc/authorization that are OS overloads, then I can run this next command.
You can't mix transcripts created with "." with ones created with "/", you will get errors if you try. You can add a "." to the beginning of all the transcript paths once they are on the server. It doesn't really change the overload files or anything. But be sure to change your radmind script on your clients to use "." as well.
So probably the biggest hurdle of beginners is learning to make changes on the server. It's easy to scan something on a client with fsdiff, upload it with lapply, but once it's on the server don't be afraid to make changes to the uploaded transcript located in /var/radmind/tmp/transcript (or /var/radmind/transcript).
radmind needs to run as root to do its thing, and I need an unprivileged user to be able to tell radmind to run. For most users, I accomplish that with a logout hook. The user runs an app that touches a file and then tells the system to logout; a logout hook (which runs as root) sees the file exists and runs radmind. This is good for several reasons: radmind gets to run as root, and the user is logged out, so radmind can make changes to the system without stomping on the user.
But what happens with laptop users who are connected via VPN or 802.1x? If they logout, the VPN or 802.1x connection is broken and they can no longer connect to the radmind server. So I need to be able to let the user run radmind even while they are logged in. The potential exists for radmind to stomp on them, but without this option, there may be users who never run radmind because they are never on the (hard-wired) network.
So I thought of using a launchd job to run radmind with an adaptation of the method used to run it at logout. I'd set up the launchd job in /Library/LaunchDaemons, so it would run as root, and using the "WatchPaths" key, have it watch for my trigger file. Sounds good, right?
Labelcom.disney.fa.runradmindProgramArguments/Users/Shared/radmindNow-forceWatchPaths/private/var/radmind/client/.radmindOnDemandOnDemandBut I couldn't get it to work consistantly. I'd start the launchd job, touch the file at the WatchPath (/private/var/radmind/client/.radmindOnDemand) and nothing would happen. I'd unload the job, reload it, touch the file again, and then it would fire. Touch it again, and it wouldn't. Maddening.So I started looking around for info on debugging launchd and found this: I turned on debugging, and eventually figured it out when I saw lines like this in my /var/log/launchd.log:
For Mac OS X, it is provided the Radmind Assistant, a wrapper for the radmind command-line clients. The Radmind Assistant provides a point-and-click interface to create radmind loadsets and update radmind clients. Radmind is a suite of Unix command-line tools and a server designed to remotely administer the file systems of multiple Unix machines. For Mac OS X, there's also a graphical interface. 350c69d7ab