Author: Brian Jones
Ximian Red Carpet Tools
Ximian’s Red Carpet comes in a variety of flavors to suit the needs of different users. Enterprise customers looking for top-rated support for a Ximian Red Carpet solution can find such programs at the Ximian web site, for a fee. However, you can also get Ximian’s Red Carpet Daemon (called ‘rcd’) and their command-line package management tool, called ‘rug’.
For the time being, these tools are free, and open source. In addition, they run on a variety of Linux distributions, and I believe it even runs on Solaris! The reason I say ‘for the time being’ is that Ximian was recently purchased by Novell, an event that brings with it at least a small amount of suspicion and uncertainty as to the future of the Ximian tools, their usefulness, and their availability. I’ll put that aside for now, since the tools do certainly work and are certainly available for most relatively recent popular distributions, including Redhat (6.2-9), SuSE (7.3-8.2), Mandrake (8.1-9.1), and even Debian woody, YellowDog, and Solaris 7 and 8. I’ve only ever run these tools on Redhat (7.3 – 9), and I’ll be focusing on Redhat 9 for the remainder of the discussion.
By default, installing and starting ‘rcd’ will allow you to use ‘rug’ to query the locally running daemon for package information about the local machine, as well as channel information stored by the daemon itself. Once you start ‘rcd’, running ‘rug ch’ will list available channels that you can subscribe to. Each channel represents a different group of packages. For example, there’s a ‘redhat-9-i386’ channel, which you can subscribe to (for free) to keep up with the latest Redhat errata and security fixes. The nice thing about the ‘distribution channels’ is that they’re really just interfaces to access mirrors which supply the vendor’s packages – these are not Ximian packages. Other channels exist for your perusal, and once you subscribe to a channel, you’re free to investigate the packages therein, querying them for information on what they do, what they depend on, etc. You can also ask for information about which available packages are newer than those currently installed on the system. Here’s a quick outtake from a session on a Redhat 9 box:
Below (click on the thumbnails for full-size images) we see a listing of the available channels. Pay attention to the ‘rh9’ one I’m subscribed to below! This is actually a local channel I’ve created myself using features built into the ‘rug’ command-line tool. Very nice. It’s certainly worth reading the long ‘rug’ manpage. I’ll go over how to do this later.
After subscribing to the channel that is specifically devoted to Ximian’s Evolution and related packages, I can immediately query for updates and package info, etc. It easy enough to find the updates available. Just enter the command “rug lu” and they will all be listed.
Now we’re getting somewhere. You don’t have to install everything in a channel. You can pick and choose what you want. Here, I’ve chosen to upgrade the older, Redhat supplied ‘unzip’, with the latest and greatest.
So there’s pretty much the whole process. Notice that all dependencies, as well as package conflicts, were completely handled by ‘rug’ without me having to do anything at all except for watch! Please note that this is for demonstration purposes only. You can see that on this machine, I have some Ximian packages installed. On production machines, I try not to update using anyone else’s packages but Red Hat’s. Furthermore, there are known issues with mixing packages from both Ximian and Redhat on the same system. However, this is just a demo of rug’s functionality, and you’re not required to subscribe to channels or install anything you don’t want on your systems. But how do you automate this in such a way that things you don’t want touched stay untouched, and everything stays secure? What’s this rcd daemon doing anyway?
Well, this is all really quite simple, though it takes a brain cell’s worth of attention to set up.
The rcd daemon, by default, does open a port to listen for remote calls, presumably from ‘rug’ clients on other machines, which can be configured to update all of the boxes in your machine room from a single station. Pretty sweet! However, I’ve opted to turn this feature off, because I’m not really ‘in the know’ about the security of this daemon. The way to do this is to create a file (if it’s not there already) called /etc/ximian/rcd.conf, and enter the following lines:
[Server]
remote-enabled=false
While you’re in the rcd.conf file, production admins may want to take the extra step of enabling the ‘repackage’ option:
[System]
repackage=true
This option will allow you to rollback any changes or updates you make by keeping data and packages locally on disk. It should be mentioned that this takes up a lot of disk space, and greatly slows down updates and installs. On the whole, I don’t find this to be unbearable, and the recoverability is worth it.
Upon restarting rcd, you can run ‘rug get-prefs’ to make sure the change has taken affect (and to check out the other settings):
With that out of the way, let’s give ourselves a safety net. What I mean is that, for example, my environment uses custom configurations for things like the kernel, sendmail and sshd. As a result, I don’t want anything happening to them that’s automated. What I can do is setup a few ‘locks’, to ensure that ‘rcd’ doesn’t, say, update my kernel and blow away my machine in the process (this happened once, during early testing):
Locking a package is as easy as entering “rug lock-add package-name”. As you can see below,you can list all existing locks by calling rug with the “ll” option, and delete delete an existing lock using “rug lock-delete list-item-number”.
It should be noted that the man page contains information about other ways to lock packages. For example, you can allow upgrades to a package only if the version remains below a user-defined threshold. Nice!
So we’ve now seen how to install things and put locks on packages. Let’s have a look at starting to get more automated, and closer to a system an administrator might begin to trust. First, be aware that the ‘rcd’ daemon really exists so that the user interface (‘rug’, or if you like GUIs, the RedCarpet interface) can communicate with entities across the network. This might be a mirror site where packages are downloaded and package lists are refreshed, or it may be another one of your own machines that you update from a single admin station. As I’ve mentioned, the prospect of this somewhat unknown daemon opening a port to the outside is a bit scary, so until I know more about it, I run it with the ‘remote-enabled=false’ setting, so it doesn’t listen for external connections. However, this doesn’t stop it from going out to the mirror sites to get packages.
Getting rcd and rug to use local package sources is actually Mind-Numbingly Easy(tm). What I’ve done for my systems is have them all mount a directory that is constantly updated from a trusted mirror site, and then use rug’s ‘mount’ flag to tell it to look there for updates. Assuming the directory is NFS mounted and is called /redhat on the local system, the command to set this up is:
rug mount -a rh9updates /redhat
The above command says to mount the /redhat directory on the local system, and I’ve exercised my option to have rug refer to the mounted directory as a channel called ‘rh9updates’. Without this argument (the ‘-a’ stands for ‘alias’) the channel would’ve been called ‘redhat’, after the directory that’s been mounted. Another thing to note is that once the rcd service is restarted, this mounted channel will disappear, and you’ll have to mount it again. Whenever you mount a channel, however, you are automatically subscribed to the channel. You could simply add a line to rcd’s init script to take care of this at startup time.
So now we have the rcd daemon listening only for connections on the local loopback interface, we have a mounted channel, which (if it’s the only channel used) keeps rcd from going out to mirrors for packages, so now we must find a way to automate the process of keeping the systems updated. Of course, as always, ‘cron’ and ‘bash’ are the good friends of the administrator,
All that’s remaining to do now is to write a script to throw into my cron.daily or cron.weekly directory to keep things patched automatically. That’s an exercise that will be left to the reader, but if you drop me a note I’ll be happy to email you a copy of what I have. I strongly suggest anyone thinking about deploying a solution like this get to know the packages in use on the systems, and definitely check out the man pages for rug and rcd.conf.
Enjoy!
Editor’s note: This story appeared originally in slightly different form at LinuxLaboratory.org.
