BOFH Hunter

Spacewalk’s first steps

A few days ago RedHat announced that they had open-sourced their satellite product under the moniker of Spacewalk, and I’ve taken a few days to play around with it and get some first impressions of what’s been put out. I do not by any means claim to be an expert on the RHN satellite from whence this came, or the current spacewalk incarnation. This is simply meant to be a linux enthusiast’s first look at the product they’ve put out.

The directions to install spacewalk are very clear and relatively simple to follow. It only took about 10 minutes to get it up and running. From there, it’s a whole different story.

Spacewalk requires its own machine

The directions don’t say this, and it’s not really 100% true, but for nearly all real-world cases, it’s much simpler just to give it a box. There are two basic reasons for this. First up is that spacewalk drops a number of packages on top of other things you may be running, like apache. The spacewalk server setup drops in a ’satellite-httpd’ process instead of using the distro provided httpd package. Since RHN satellite was/is a boxed solution, this fact can be overlooked as I figure it’s probably something that will change as the project matures and gains popularity. The second issue with spacewalk is storage, which is primarily an organization based issue. Sure it’s going to take a few gigs of disk space to mirror your favorite distribution, updates and any associated 3rd party repositories that you might want. However:

Channels cannot cross organisations

This one kind of surprised me considering that RHN seems to do this just fine, though it’s probably due to a different back end.  To illustrate this point a little, lets assume that we’re running the Spacewalk server for a university.  The IT department has their own organization for the university infrastructure, with a CentOS5 channel for base, a child channel for updates, and another child for Extras. A fairly boring example to be sure, but a good foundation to work from. The CS department runs CentOS for this systems as well, using it for both instruction, and the servers related to instruction. They have require the exact same channels the IT department uses, but Spacewalk currently requires them to duplicate the entire tree; Base, Updates, Extras, all of it.  If you expand this out for a few more organizations, and figure 20G or so per channel for the life of the distribution, you’re very easily looking at a few hundred gigs of storage. And while you’re busy pushing these packages to the Spacewalk server, you’ll be doing so manually.

Syncing Repositories

Part of the RHN satellite feature was that it would sync with redhat’s RHN proper, and then you could move out with your updates locally. The old RHN satellite would pull from RedHat’s RHN proper, and then you could manage your machines locally. With Spacewalk, the RHN sync capability was removed, and no base for syncing to other repositories (via yum, rsync or otherwise) currently exists. If you want to keep spacewalk updated with the latest and greatest for your distribution, you’ll have to script something up yourself. The methods for doing so are not difficult, and anyone with a basic grasp of shell scripting should be able to pull this off.

The good stuff

I really don’t want this to seem like I’m simply complaining about Spacewalk as it is a very good product, and RedHat did a good thing by releasing it. It simply has a bit of growing to do as it begins life as an open source project. There’s already a rather vibrant community springing up around it, both as a mailing list and in irc on freenode. Additionally, Spacewalk provides functional centralized management of multiple boxes across different distributions which is indeed quite useful.

If you’re in the market for centralized system management and you have a box with storage to spare, then I would highly recommend folks take a look at Spacewalk. It is definitely a project to keep an eye on as it matures.