Tiger Lab Migration Part 3: Radmind
Okay. So, Tiger client is working. Moreover, Tiger client seems to work with my Panther Mac Server. And I have a backup disk image of my working Tiger install, should anything go amiss. Time to start setting up Radmind.
The Logic:I have about thirty Mac systems to maintain in a lab set up for art students doing all manner of computer-based art, including: web design, graphics, video, audio, interactive authoring (from screen-based to installation art), and some 3D. Certain software -- like the operating system, for instance, is installed on all the machines. Certain software -- like Max/MSP, for which we have only so many licenses -- is installed only on select machines. Also, some systems are workstations used by students for the creation of their work, but there are also staff machines which serve vastly different purposes and are set up very differently. This means we have multiple hardware/software configrations for the various systems in our department. Keeping these machines up to date can be very challenging. Not only do we need to keep tabs on which systems have which software, we also need to keep tabs on which systems have been recently updated and which ones are in need of being updated. In the past, this has meant keeping a database of system configurations, logging into or polling (via ARD or some such utility) systems to see which ones need updates, and, when updates are required, personally sitting at machines and running software updates by hand. This process is tedious, inefficient, and more importantly, quite error-prone: Do one thing differntly on one machine, and you've suddenly introduced inconsistencies throughout the lab. And with no way to track them, or even revert them should the need arise.
Clearly what is needed is a centralized system for software and OS update management and reversion, whereby changes to be made to workstations on the lab floor can be applied to a single system, tested, and then propagated to the appropriate systems during off-hours or scheduled maintenance times. Radmind is such a solution. And, miraculously, it's completely free.
Wow.
The Goal:We have several different configurations of Mac on the lab floor, and in the various staff offices. Before we start, let's outline them: We have Basic Workstations (BWs) with a basic (though still quite large) set of software; we have what I'll call Max Workstations (MW), which are essentially the same as the BWs, but with a Max/MSP added; we have Physical Computing Workstations (PW), which have the Max/MSP config plus certain drivers required for programming Basic Stamp and the like; we then have Staff Workstations (SWs), which have a leaner software set overall, but which also have software not generally found on the public workstations; next, we have Audio Worksations (AWs), which have the basic set plus -- you gussed it -- audio software and drivers; and finally we have Video Workstations (VWs) that are set up like the Basics, but with a few video do-dads to boot.
A quick note about the Audio and Video workstations: I share maintenance of these machines with our A/V SysAdmin. Essentially, he manages them, but I provide him with a baseline OS install (by way of some sort of cloned image) and advise him with regards to OS updates and the like; he installs, configures, manages and updates any audio- or video-specific software not found in my base config. This area of the lab will be tricky to control with Radmind, particularly the Audio Stations as they often require certain hardware to be available for the software to be installed. Also, since our A/V guy handles upadates to those systems, and since I do not (and this is a good thing), using my Radmind system for A/V updates might prove tricky. I will save the A/V systems for last, and figure out how best to handle them later. Fortunately, Radmind allows for this sort of gradual implementation. Ultimately, though, I may leave them out of my Radmind setup.
The ultimate goal will be to set up one alpha workstation that has everything required for every configuration. Then Radmind can be used to create subsets of this uber-station (henceforth referred to as the Master Client or "MC"), for propagation to workstations with less than the maximum of software installed. The MC will be built around the configuration of the Physical Computing Workstations, as those systems have all the software needed on any other system.
The Process:The first step is to set up the Radmind server, which will be my admin box. That's really easy, and is done. It's simply a matter of downloading the Radmind software packages, and then running the Radmind Assistant application. These can be found here. In the Radmind Assistant I just set my system up as a server. That's all. Oh, and I made sure to set it to use Bonjour for discovery. This makes server discovery from the client a breeze. The client simply looks on the network, via Bonjour, for any Radmind servers, and when it finds them it gives you a list of available server IPs to chose from. Nice.
The next step is a bit more complex. It's time to build the MC. To begin, I am doing a fresh install of Tiger, running all current system updates (were on 10.4.1 as of this writing), and then setting this base install up the way I want it. A surprising amount of stuff gets set at this stage: Network, Energy Saver, Sharing, QuickTime Pro (license and settings), Accounts, and Security preferences all get set here. I am setting up my two local admin accounts at this stage as well. Also, I'm setting up binding to my Macserver for authentication, as well as installing my custom NFS mount Startup Item for mounting our home account RAID. Finally, I will install Radmind, of course. What I want to end up with is a very basic, clean system that represents the bare minimum installation for running in the lab, with no third party apps yet installed, and no customization of cron or any login scripts or anything, except Radmind, which should be set up as well, and should be part of the Base Install on the server so that it can create Radmind-controllable clones of itself, which can then be easily updated. This is my Base Install.
Once the Base Install is done, I will configure the machine to be a Radmind client that is controlled by the Radmind server. The MC will doesn't know it's the MC, and it doesn't really have to. In fact Radmind doesn't even need to be aware of this. The concept of the MC is really for us humans. So the MC will be set up as a client, just like any of the other clients. Essentially, Radmind will then begin using this machine to set up lists of files. These lists are what's really important. The lists will be used to compare files on various clients. Additional clients will be updated based on these lists.
At least that's how it's supposed to work.
Failure:I spent an entire day attempting to set up my MC with Radmind. You need to do two things on the MC before you can really get down to business with Radmind: 1) create a negative transcript for the server to use, and 2) create a positive transcript for the server to use. These are the most basic, fundamental lists that the server uses to compare against clients. The negative transcript is a list of files that should not be propagated to clients, and the positive transcript is a list of files that should get propagated. For some reason, I had endless problems creating these transcripts. The first problem was a discrepency between how the GUI application creates transcripts, and how it reads them, by default. The GUI app is set to "Begin transcript comparison from this path: / (slash)" whereas, the default transcripts created by the application use ./ (dot slash) at the beginning of their file paths. So, right out of the box, the Radmind GUI fails horribly, and my first, vanilla, Radmind-built negative transcript generated all manner of error message. Changing the defaults fixed it, and I was able to generate a useable negative transcript.
The second problem... Well, I don't know what caused the second problem. Basically, I can't seem to generate a positive transcript that will verify without errors. All I'm trying to do is create the base-loadset.T transcript, using all the defaults in Radmind, and each time I do, on my server I get a list of positive transcripts with numbers like "994" appended to the file names, and my base-loadset.T file generates an unspecified error when I try to verify it on my server. I've tried this numerous times, and the same thing happens each time. Frankly, I'm sick of it. Each base-loadset.T creation takes upwards of half an hour, as the client must compare and then copy the entire loadset (essentially, all the files on the hard drive) to the server. Multiple failures at this stage are infuriating. But what's worse is that there seems to be no way to modify the configuration once it's been uploaded. Making a new loadset with the same name gives me the error "Loadset exists." So the only way to re-attempt loadset creation, or modify a loadset, is to erase it and start over. For a system that's all about monitoring and tracking changes to systems, this seems like a backwards approach. In any case, after a day of trying, I still have not successfully created a working positive transcript.
There are lots of problems with the Radmind implementation. One irksome problem is the inconsistency of just about everything in the application. (I'm talking about the GUI here.) For instance, running through the setup steps frequently yielded different results, both on the server and on the client -- sometimes I'd get errors, go back, repeat and get no errors; sometimes, after setting up my negative transcript, I'd be asked to set up my positive, sometimes I wouldn't. Also, the interface is ridiculously inconsistent: while running the setup steps, pressing the "Go Back" button does not take you back to the beginning of the setup steps. WTF? Maybe they should rename that button "Go Somewhere You've Never Been Before," because that's where it takes you. Another issue I faced was in altering a transcript: the latest version of the Transcript Editor completely garbles your transcript if you add an item. I had to use a previous version to add items to the list. And there's more: Adding a server to your server list in the Radmind preferences does nothing apparently. Even after doing this I was always queried for my server IP. Also, once added, a server cannot be removed from the list. There is a "remove" button, but it does nothing.
This is why Systems Admins should never design software.
It's been suggested that I try using Radmind from the command-line. I am tempted. But the problem is that the Radmind CLI environment and implementation is so complex that I'm liable to spend a week learning it, only to find that it still doesn't work. I've already been online reading various Radmind mailing lists, and people are having all manner of difficulty there as well, particularly going to Tiger. I just don't think, at this stage, it would be wise to continue with this plan when the product is clearly so problematic on so many levels.
Resignation:So, after all this planning and testing, I've decided not to use Radmind after all. My reasoning is basically twofold: 1) Radmind is supposed to make my life easier, not harder. Thus far it's only introduced complications to my life and to the process of administrating my systems. And this is just in setting up my base system. What problems will I encounter when I start adding the many gigabytes of application files? Seems to me a product that is designed to simplify lab management should be fairly straightforward and easy to master. If it's not, what's the point? Using Radmind only adds an extra layer of complexity that I'm not even sure I really need. 2) Radmind is supposed to make updates and installs less error-prone and more consistent throughout the lab. But, again, the Radmind process itself is inherently error-prone, at least in my (and many others online) experience. How can I rely on such a system for lab maintenance with any confidence at all? I simply don't trust it. And if Radmind breaks with each upgrade of Mac OSX (which it might or might not, I just don't know, but indications are that it does), then again, what's the point? For all my work, what do I get?
There's got to be a better way.
Seems to me like the ultimate Radmind solution, at least in GUI-land (or maybe even as CLI solution -- why not?) would be something quite seamless to the admin. (And yes, I will now try to outline what I would like to see in a Radmind-like solution despite having said, not three paragraphs earlier, that Sys Admins should never design software.) I envision something like this: There is an interface called "Base Builder." Here you configure your base system, which would be your Master Client. On the MC you open Base Builder and tell it to use the "Current System" as your base install and it uploads everything to your server. I don't need to see a list of files at this point. Just build the damn system. Keep your lists to yourself, thank you. After the system is built, you can create your "Exclusions" from within the Base Builder app. This is real simple too. You just drop the folders you want to exclude into a GUI window, and then the properties of each exclusion. Now you've altered your base install, so you get a window that says something like, "Base install has changed. Would you like to rebuild the base install on the server?" and a big, fat "Yes" button. Hit "Yes" and your changes are propagated to the server. Simple. And when it's time to add applications or other layers to your base, you go to the "Layer Builder" interface. This is similarly easy to use. Here, you tell the app where to find your base install, or you can say "User Current System." Layer Builder will take a snapshot of the base install and keep that snapshot. You'll install your apps, then tell Layer Builder to create the new layer from a comparison between the base install snapshot and the new system. Layer Builder will allow you to name your new layer, and then save a snapshot of the layer. Finally, you'll have a "Sets Builder" interface. Here you can combine various sets of layers to create different configuration for different machines. This would have three panes: A "Layers" pane, a "Sets" pane and a "Computers" pane. You'd drag layers from the Layers pane into sets in the Sets pane to create your various configs. Then you'd drag sets to computer lists in the Computers pane. In the Computer pane you could run "Compare" to see differences between the actual computer's files and the files in the set. And if there were differences, you could propagate them to the client using something like, oh, I don't know, an "Update" button, let's say. And that's it, basically. For advanced users, you could look at the file lists and make changes between the server and the MC and the various clients. This seems like a key missing feature in Radmind. The ability to change the base config, or any of its transcripts in any meaningful way seems to be absent. These sorts of changes require rebuilding everything, which takes a great deal of time and effort, and is error prone. And isn't the whole point of this to make the process of lab maintenance easier and less error prone?
I realize that what I've described is essentially what Radmind is and does. But Radmind does it in such an abstract and confusing way that the process becomes needlessly complex and defeats its own purpose. Something that companies like Apple understand -- and this is a large part of why I prefer the Mac platform -- is that good visual design and clear language can make an interface, or even a CLI app, a breeze to use, and that that is actually the point of GUI applpications: To make a difficult and confusing process clear and intelligible. Radmind's visual interface is a mess, and its language is dizzingly obscure. Here's a list of terminology, for example: negative transcript, positive transcript, command file, loadset, base loadset, overload, configuration. Here is a list of some of the files involved: negative.T, base-loadset.T, base.K. The files that end in .T are transcript files, which are lists of files belonging to a loadset. Get it? Of course not. Who would?
It's totally ridiculous.
Now that I've gotten that off my chest, I need to come up with a good way to proceed with my lab update. And although I am scrapping Radmind for now, I would still like to think of a way to ease future updates and remove the inconsistencies from the way I've done things in the past. There are a few options here. These involve disk images and databases for the most part. In any case, I will be giving this some serious thought as I move forward. But these issues will be the topic of a future article.
The Logic:I have about thirty Mac systems to maintain in a lab set up for art students doing all manner of computer-based art, including: web design, graphics, video, audio, interactive authoring (from screen-based to installation art), and some 3D. Certain software -- like the operating system, for instance, is installed on all the machines. Certain software -- like Max/MSP, for which we have only so many licenses -- is installed only on select machines. Also, some systems are workstations used by students for the creation of their work, but there are also staff machines which serve vastly different purposes and are set up very differently. This means we have multiple hardware/software configrations for the various systems in our department. Keeping these machines up to date can be very challenging. Not only do we need to keep tabs on which systems have which software, we also need to keep tabs on which systems have been recently updated and which ones are in need of being updated. In the past, this has meant keeping a database of system configurations, logging into or polling (via ARD or some such utility) systems to see which ones need updates, and, when updates are required, personally sitting at machines and running software updates by hand. This process is tedious, inefficient, and more importantly, quite error-prone: Do one thing differntly on one machine, and you've suddenly introduced inconsistencies throughout the lab. And with no way to track them, or even revert them should the need arise.
Clearly what is needed is a centralized system for software and OS update management and reversion, whereby changes to be made to workstations on the lab floor can be applied to a single system, tested, and then propagated to the appropriate systems during off-hours or scheduled maintenance times. Radmind is such a solution. And, miraculously, it's completely free.
Wow.
The Goal:We have several different configurations of Mac on the lab floor, and in the various staff offices. Before we start, let's outline them: We have Basic Workstations (BWs) with a basic (though still quite large) set of software; we have what I'll call Max Workstations (MW), which are essentially the same as the BWs, but with a Max/MSP added; we have Physical Computing Workstations (PW), which have the Max/MSP config plus certain drivers required for programming Basic Stamp and the like; we then have Staff Workstations (SWs), which have a leaner software set overall, but which also have software not generally found on the public workstations; next, we have Audio Worksations (AWs), which have the basic set plus -- you gussed it -- audio software and drivers; and finally we have Video Workstations (VWs) that are set up like the Basics, but with a few video do-dads to boot.
A quick note about the Audio and Video workstations: I share maintenance of these machines with our A/V SysAdmin. Essentially, he manages them, but I provide him with a baseline OS install (by way of some sort of cloned image) and advise him with regards to OS updates and the like; he installs, configures, manages and updates any audio- or video-specific software not found in my base config. This area of the lab will be tricky to control with Radmind, particularly the Audio Stations as they often require certain hardware to be available for the software to be installed. Also, since our A/V guy handles upadates to those systems, and since I do not (and this is a good thing), using my Radmind system for A/V updates might prove tricky. I will save the A/V systems for last, and figure out how best to handle them later. Fortunately, Radmind allows for this sort of gradual implementation. Ultimately, though, I may leave them out of my Radmind setup.
The ultimate goal will be to set up one alpha workstation that has everything required for every configuration. Then Radmind can be used to create subsets of this uber-station (henceforth referred to as the Master Client or "MC"), for propagation to workstations with less than the maximum of software installed. The MC will be built around the configuration of the Physical Computing Workstations, as those systems have all the software needed on any other system.
The Process:The first step is to set up the Radmind server, which will be my admin box. That's really easy, and is done. It's simply a matter of downloading the Radmind software packages, and then running the Radmind Assistant application. These can be found here. In the Radmind Assistant I just set my system up as a server. That's all. Oh, and I made sure to set it to use Bonjour for discovery. This makes server discovery from the client a breeze. The client simply looks on the network, via Bonjour, for any Radmind servers, and when it finds them it gives you a list of available server IPs to chose from. Nice.
The next step is a bit more complex. It's time to build the MC. To begin, I am doing a fresh install of Tiger, running all current system updates (were on 10.4.1 as of this writing), and then setting this base install up the way I want it. A surprising amount of stuff gets set at this stage: Network, Energy Saver, Sharing, QuickTime Pro (license and settings), Accounts, and Security preferences all get set here. I am setting up my two local admin accounts at this stage as well. Also, I'm setting up binding to my Macserver for authentication, as well as installing my custom NFS mount Startup Item for mounting our home account RAID. Finally, I will install Radmind, of course. What I want to end up with is a very basic, clean system that represents the bare minimum installation for running in the lab, with no third party apps yet installed, and no customization of cron or any login scripts or anything, except Radmind, which should be set up as well, and should be part of the Base Install on the server so that it can create Radmind-controllable clones of itself, which can then be easily updated. This is my Base Install.
Once the Base Install is done, I will configure the machine to be a Radmind client that is controlled by the Radmind server. The MC will doesn't know it's the MC, and it doesn't really have to. In fact Radmind doesn't even need to be aware of this. The concept of the MC is really for us humans. So the MC will be set up as a client, just like any of the other clients. Essentially, Radmind will then begin using this machine to set up lists of files. These lists are what's really important. The lists will be used to compare files on various clients. Additional clients will be updated based on these lists.
At least that's how it's supposed to work.
Failure:I spent an entire day attempting to set up my MC with Radmind. You need to do two things on the MC before you can really get down to business with Radmind: 1) create a negative transcript for the server to use, and 2) create a positive transcript for the server to use. These are the most basic, fundamental lists that the server uses to compare against clients. The negative transcript is a list of files that should not be propagated to clients, and the positive transcript is a list of files that should get propagated. For some reason, I had endless problems creating these transcripts. The first problem was a discrepency between how the GUI application creates transcripts, and how it reads them, by default. The GUI app is set to "Begin transcript comparison from this path: / (slash)" whereas, the default transcripts created by the application use ./ (dot slash) at the beginning of their file paths. So, right out of the box, the Radmind GUI fails horribly, and my first, vanilla, Radmind-built negative transcript generated all manner of error message. Changing the defaults fixed it, and I was able to generate a useable negative transcript.
The second problem... Well, I don't know what caused the second problem. Basically, I can't seem to generate a positive transcript that will verify without errors. All I'm trying to do is create the base-loadset.T transcript, using all the defaults in Radmind, and each time I do, on my server I get a list of positive transcripts with numbers like "994" appended to the file names, and my base-loadset.T file generates an unspecified error when I try to verify it on my server. I've tried this numerous times, and the same thing happens each time. Frankly, I'm sick of it. Each base-loadset.T creation takes upwards of half an hour, as the client must compare and then copy the entire loadset (essentially, all the files on the hard drive) to the server. Multiple failures at this stage are infuriating. But what's worse is that there seems to be no way to modify the configuration once it's been uploaded. Making a new loadset with the same name gives me the error "Loadset exists." So the only way to re-attempt loadset creation, or modify a loadset, is to erase it and start over. For a system that's all about monitoring and tracking changes to systems, this seems like a backwards approach. In any case, after a day of trying, I still have not successfully created a working positive transcript.
There are lots of problems with the Radmind implementation. One irksome problem is the inconsistency of just about everything in the application. (I'm talking about the GUI here.) For instance, running through the setup steps frequently yielded different results, both on the server and on the client -- sometimes I'd get errors, go back, repeat and get no errors; sometimes, after setting up my negative transcript, I'd be asked to set up my positive, sometimes I wouldn't. Also, the interface is ridiculously inconsistent: while running the setup steps, pressing the "Go Back" button does not take you back to the beginning of the setup steps. WTF? Maybe they should rename that button "Go Somewhere You've Never Been Before," because that's where it takes you. Another issue I faced was in altering a transcript: the latest version of the Transcript Editor completely garbles your transcript if you add an item. I had to use a previous version to add items to the list. And there's more: Adding a server to your server list in the Radmind preferences does nothing apparently. Even after doing this I was always queried for my server IP. Also, once added, a server cannot be removed from the list. There is a "remove" button, but it does nothing.
This is why Systems Admins should never design software.
It's been suggested that I try using Radmind from the command-line. I am tempted. But the problem is that the Radmind CLI environment and implementation is so complex that I'm liable to spend a week learning it, only to find that it still doesn't work. I've already been online reading various Radmind mailing lists, and people are having all manner of difficulty there as well, particularly going to Tiger. I just don't think, at this stage, it would be wise to continue with this plan when the product is clearly so problematic on so many levels.
Resignation:So, after all this planning and testing, I've decided not to use Radmind after all. My reasoning is basically twofold: 1) Radmind is supposed to make my life easier, not harder. Thus far it's only introduced complications to my life and to the process of administrating my systems. And this is just in setting up my base system. What problems will I encounter when I start adding the many gigabytes of application files? Seems to me a product that is designed to simplify lab management should be fairly straightforward and easy to master. If it's not, what's the point? Using Radmind only adds an extra layer of complexity that I'm not even sure I really need. 2) Radmind is supposed to make updates and installs less error-prone and more consistent throughout the lab. But, again, the Radmind process itself is inherently error-prone, at least in my (and many others online) experience. How can I rely on such a system for lab maintenance with any confidence at all? I simply don't trust it. And if Radmind breaks with each upgrade of Mac OSX (which it might or might not, I just don't know, but indications are that it does), then again, what's the point? For all my work, what do I get?
There's got to be a better way.
Seems to me like the ultimate Radmind solution, at least in GUI-land (or maybe even as CLI solution -- why not?) would be something quite seamless to the admin. (And yes, I will now try to outline what I would like to see in a Radmind-like solution despite having said, not three paragraphs earlier, that Sys Admins should never design software.) I envision something like this: There is an interface called "Base Builder." Here you configure your base system, which would be your Master Client. On the MC you open Base Builder and tell it to use the "Current System" as your base install and it uploads everything to your server. I don't need to see a list of files at this point. Just build the damn system. Keep your lists to yourself, thank you. After the system is built, you can create your "Exclusions" from within the Base Builder app. This is real simple too. You just drop the folders you want to exclude into a GUI window, and then the properties of each exclusion. Now you've altered your base install, so you get a window that says something like, "Base install has changed. Would you like to rebuild the base install on the server?" and a big, fat "Yes" button. Hit "Yes" and your changes are propagated to the server. Simple. And when it's time to add applications or other layers to your base, you go to the "Layer Builder" interface. This is similarly easy to use. Here, you tell the app where to find your base install, or you can say "User Current System." Layer Builder will take a snapshot of the base install and keep that snapshot. You'll install your apps, then tell Layer Builder to create the new layer from a comparison between the base install snapshot and the new system. Layer Builder will allow you to name your new layer, and then save a snapshot of the layer. Finally, you'll have a "Sets Builder" interface. Here you can combine various sets of layers to create different configuration for different machines. This would have three panes: A "Layers" pane, a "Sets" pane and a "Computers" pane. You'd drag layers from the Layers pane into sets in the Sets pane to create your various configs. Then you'd drag sets to computer lists in the Computers pane. In the Computer pane you could run "Compare" to see differences between the actual computer's files and the files in the set. And if there were differences, you could propagate them to the client using something like, oh, I don't know, an "Update" button, let's say. And that's it, basically. For advanced users, you could look at the file lists and make changes between the server and the MC and the various clients. This seems like a key missing feature in Radmind. The ability to change the base config, or any of its transcripts in any meaningful way seems to be absent. These sorts of changes require rebuilding everything, which takes a great deal of time and effort, and is error prone. And isn't the whole point of this to make the process of lab maintenance easier and less error prone?
I realize that what I've described is essentially what Radmind is and does. But Radmind does it in such an abstract and confusing way that the process becomes needlessly complex and defeats its own purpose. Something that companies like Apple understand -- and this is a large part of why I prefer the Mac platform -- is that good visual design and clear language can make an interface, or even a CLI app, a breeze to use, and that that is actually the point of GUI applpications: To make a difficult and confusing process clear and intelligible. Radmind's visual interface is a mess, and its language is dizzingly obscure. Here's a list of terminology, for example: negative transcript, positive transcript, command file, loadset, base loadset, overload, configuration. Here is a list of some of the files involved: negative.T, base-loadset.T, base.K. The files that end in .T are transcript files, which are lists of files belonging to a loadset. Get it? Of course not. Who would?
It's totally ridiculous.
Now that I've gotten that off my chest, I need to come up with a good way to proceed with my lab update. And although I am scrapping Radmind for now, I would still like to think of a way to ease future updates and remove the inconsistencies from the way I've done things in the past. There are a few options here. These involve disk images and databases for the most part. In any case, I will be giving this some serious thought as I move forward. But these issues will be the topic of a future article.
Labels: Lab, Systems, Tiger, TigerLabMigration
This entry was posted
on Monday, June 27, 2005 at 6:19 PM.
You can skip to the end and leave a response.
» Post a Comment