Radmind, being a set of UNIX tools, originally supported only case-sensitive transcripts. Mac OS X’s HFS+ filesystem, developed by Apple pre-NeXT purchase, is a case-preserving, case-insensitive filesystem.
Support for case-insensitive transcripts was later added to the radmind tools.
As it turns out, it is perfectly possible to use radmind with case-sensitive transcripts to manage an OS X HFS+ filesystem. There are sometimes a few annoyances, but it generally works OK. Worst case, you might have to run the radmind tools twice to get the filesystem update when there is a case change: the first run might remove the lowercase version of the file, and the second run would install the uppercase version. Or a sharp radmind admin might be able to avoid the problem altogether by renaming files in troublesome transcripts.
Continue reading “Radmind: converting to case-insensitive transcripts”
In an earlier article about putting MCX data into the local DS store, I mentioned that I’m using radmind to deliver the pieces to each client machine. Here’s a little more detail on that.
Continue reading “MCX, dslocal, and radmind”
I haven’t found the time to write up all the changes, but here are my current scripts and associated tools I use to run radmind. Of special note is the updated run_radmind.pl script, which uses Ian Ward Comfort’s techniques to successfully survive a
/usr/lib/dyld upgrade (or downgrade).
Quite a while back, I did a series of posts on using radmind to update a machine from 10.3.x to 10.4.x. A major element of the strategy, developed by Andrew Mortenson, was to copy vital tools and their needed libraries to a “cache” directory and coerce the OS to use those copies instead. This worked around problems to reared their heads when radmind replaced those tools and libraries while it was updating the filesystem.
While working on building a radmind loadset for 10.4.8, I discovered that if I used my current script to have radmind update an Intel Mac from 10.4.7 to 10.4.8, that the machine would hang when the script attempted to reboot the machine. You could manually reboot it, and the machine would come up fine. This behavior seemed very similar to what happened when trying to go from 10.3.x to 10.4.x before I implemented Andrew’s technique. It seemed that Andrew’s technique didn’t go quite far enough. There was much discussion of the issue on the radmind-users mailing list, and Ian Ward Comfort of Stanford came up with a solution. It takes Andrew’s ideas, and builds on them in two ways:
- It dynamically determines if any tools or required libraries need to be cached, using Apple’s
/usr/lib/dyld is being replaced, it calls all the tools using a chroot-ed environment so that the cached version of
dyld is used. This was the key change for the 10.4.7 to 10.4.8 update on Intel – without the chroot-ed environment, the OS was calling dyld in its original location after radmind had swapped it out, leading to a crash.
In my testing, this technique works perfectly. Here is Ian’s script, and here’s a link to the tool-caching bit of code. I did a lot of hacking to meld Ian’s code with mine, and I’ll probably post my version of the script soon.
Yesterday we had a near-disaster where another admin created a mountpoint at /mnt and mounted an NFS filesystem for testing. After testing, he proceeded to run the radmind tools to update his machine. He noticed that radmind was scanning the contents of /mnt and aborted the run. If he had not aborted it, it’s likely that lapply would have started deleting items on that mount.
In the dim, dark past I asked for a feature for fsdiff that would cause it to ignore remotely mounted filesystems to prevent just this problem, having seen it crop up a few times here, usually due to an error.
Normally this is not a problem, as things like AFP and SMB servers normally mount under paths that are already in a negative transcript – places like /Network, /Volumes, and /automount. But a user with sudo rights (or an admin) can create mountpoints virtually anywhere and mount things. A more likely scenario that can lead to this type of problem is implementing classic UNIX NFS automounts like /home – a radmind administrator’s mistake in a transcript could lead to lapply trying to remove the contents of /home!
When this almost happened again yesterday, I had the flash of insight that I could script around the problem, and I came up with the attached script.
Continue reading “Radmind and mountpoints”
Radmind supports the use of OpenSSL certificates as a means of identifying clients and for encrypting communications between client and server. I don’t really care about the encryption, but using certificates to identify clients allows laptops to run radmind no matter what network they use to connect to my radmind server – Ethernet, wireless, or VPN from home.
Setting up certificate support on a radmind server is a bit of a pain. I used the “Using TLS with Radmind” document available here.
But adding and removing certificates involves a lot of steps, and therefore is tedious and error-prone. And I wanted to be able to let several people at my organization be able to do this. When faced with repetitive, tedious, error-prone tasks, the lazy admin will write a script to do most of the work for him/her. So that’s what I did. Continue reading “Certificate creation for radmind”
Earlier this month, I posted about an issue with radmind 1.5.1 when used under Tiger — symlinks could be created in such a way that they were unusable by anyone but root. This causes lots of other problems.
This was actually caused by a combination of a change in radmind to make the creation of temporary files more secure, and a difference in how symlinks behave in Tiger vs just about every other UNIX in existence.
radmind 1.6 was released this week, and contains changes that prevent this issue from happening under Tiger. Add in the new support for optional network compression and Universal Binary goodness, and you should definitely check it out.
Note that radmind 1.6.1 was released shortly after the release of 1.6. The only change was a fix for a compile problem on non-OS X OSes. There is a Mac OS X installer for 1.6; with 1.6.1 you have to compile from source. When I tried compiling 1.6.1, I got platform-specific binaries instead of Universal Binaries. So I didn’t spend any more time on the issue, and grabbed the 1.6 release instead.