Two Weeks With Spacewalk
After using Chef and Puppet, I have the opportunity to compare and contrast the pair with Spacewalk, the open source component of RedHat Satellite. Spacewalk represents one perspective on data center management applications, which if you are more inclined to work in the command line might not agree with you. Spacewalk, Chef, and Puppet are configuration management and data center automation tools, and if there is any truth to the state of such tools today, it is that we still have so much farther to go.
Spacewalk reminds me of LAMP applications I played around with in the early 2000’s, around the time my aversion to web based tools developed. As I stated before, I don’t want to become a dinosaur, unable to grow and adapt to a change technology industry, but the concept of managing the servers through a web interface still seems foreign to me. Spacewalk is the open source component of Red Hat’s Network Satellite, The Fedora to Red Hat’s RHEL server. As such, Spacewalk works perfectly with RHEL clone CentOS.
Walking through managing servers with Spacewalk, I can’t help but get a little confused following the clicks through the different screens. I fail to understand why navigating web interfaces are still considered to be easier than editing a text file, especially if you are familiar with navigating the command line, which if you are a systems administrator interested in automation, I’m going to just go ahead and assume you are. In fact, to get the client configured to communicate with the spacewalk server, you still need to get into the command line to register it. Spacewalk does do a few interesting things in interesting ways. For one, Spacewalk provides you with a WebMin like interface to run an arbitrary command as root on a connected file. However, it does so as a batch job, which reminds me of big data, and big iron, systems where job scheduling was (and is) important.
Spacewalk’s main purpose is distributing software, since it is developed as Red Hat’s satellite. Red Hat’s business model is to basically sell support for Linux, and a good portion of the support that businesses pay for is access to patches and updates. Spacewalk does a good job at scheduling patches to be installed, and can reboot the server for you at the appropriate time. This works out great in pre-production environments, but I do not yet have enough faith in the system to use the scheduling to patch production. I have, in the past, seen patches restart services during the patching process. That might be a big problem, depending on your specific setup. That being said, Spacewalk does do a good job, and a sysadmin can not keep applying patches on the command line forever. Something has got to give, but it seems like this is still one area where there are no great answers.
Comparing Spacewalk to Chef and Puppet is a little bit apples and oranges. Chef and Puppet are similar, although I prefer Puppet because of how Chef splits the configuration between the API on the server and the cookbooks edited locally. Puppet keeps one master configuration directory of plain text files. Very easy to move around and integrate with version control systems. Puppet and Chef were developed by systems administrators and developers to make managing large numbers of servers easier, Spacewalk feels like it was developed by Red Hat to make money. I don’t fault them at all for that, its just that it seems to have a different aim than Chef and Puppet.
To me, Puppet is the clear winner here. Easy configuration, one central repository of text files, easy integration with version control, extremely flexible, and supports multiple operating systems. I’m aware that Puppet has a web interface, but I have never bothered to use it. Puppet is the type of tool that will bring us into the next ten years. Spacewalk seems like a tool from ten years ago.