NRH-up2date

After absorbing the information decribed on the "up2date" page, being an open source developer, and a system administrator, i have decided to put some time into finding an acceptable solution for the problem - back then i already had 3 separate sites with 5 to 10 machines each, and updating all these machines using basic RHN service took considerable amount of time.

Considering that there is at least 1 update per month that has to be applied, taking several days of work to investigate possible solutions that didn't involve paying (tens of ?) thousands of dollars to RedHat for their "satellite" service (which caches all updates on your own server inside your LAN, eliminating the download time for each client system) seemed like a worthy investment.

First of all, up2date can take previously downloaded packages from a local directory on that machine, using the -k switch, thus saving you the download time for each machine, you can just download the packages once, put them on some central server, and mount the directory from the clients by nfs. This can be done in a low security zone, like an internal corporate lan, but on a production server farm, running an nfs client on an edge server seems unwise. And you still need an RHN subscription for each machine, which costs 60$ per system.

Generally speaking, you can just copy the "/etc/sysconfig/rhn/systemid" file to each of the machines, so RHN will think that only one system accesses it, while you are actually using one system id for several servers. But of course, this approach is against Red Hat Network Services Use and Subscription Agreement (http://rhn.redhat.com/help/terms.pxt ). Clause 2 clearly states "Customer may not use one subscription for Services for more than one system concurrently."

The solution

After absorbing all that information, i have decided to try setting up my own up2date server. Some some tinkering with the up2date client on my RH 7.3, provided me the following information about it's workings:

1. Communicates with the RHN servers using XMLRPC
2. Has extensive configuration options built in, can allow to change 20+ parameters without modifying the code, including the server address it uses
3. Can be configured to store locally all content downloaded from RHN
4. It's communication protocol with the RHN is pretty simple :
   • Connect to the RHN, provide a valid system id
   • In return, receive an authentication token, a list of channels the machine is subscribed to (RedHat 7.1, 7.2, 7.3, powertools and others) and the the date the list of updates for the channel was updated
   • Download the latest update list, if it is not already downloaded. The update list is a simple XML file containing the list of all available rpm's and their properties (version, size, others)
   • Decide what of the available packages are relevant to the system
   • Download all relevant rpm headers that are not already downloaded
   • Run some checks on the rpm headers to resolve conflicts and dependencies
   • Download all relevant rpms
   • Install downloaded rpms
   • Notify redhat's server of the installed packages, so they would be able to update your system profile

Having the above information, emulating an up2date server by a simple apache server was simple : a standard up2date client connects to the redhat's server to get an authentication token, a list of channels it is subscribed to, and the date of latest updates list. It expects an xml response, such as this.

In this case, "redhat-linux-i386-7.3" is the channel this machine is subscribed to, and "20020806033416" is the latest update date. After that, the client will connect to redhat's server to download the updates list and save it to /var/spool/redhat-linux-i386-7.3.$date . It will parse the updates list and get all necessary rpm headers from redhat's server, saving them as .hdr files in /var/spool/up2date , and last but not least, it will download all necessary rpms, and also save them to /var/spool/up2date . After such update we reasonably expect to have all the necessary content to update other machines in /var/spool/up2date . The only thing we need is to provide that content in the same way that RHN servers do.

Implementation

After 3 hours of perl coding, i have produced the first product. It was a perl cgi, about 30 lines, that covered the most basic functionality. Along with some directory aliases added to the apache configuration, it was able to successfully emulate an up2date server.

Of course, there was much more then that to providing a viable solution, so the code was enhanced till the 1.0 release, and completely rewritten for the 1.1 release, providing a modular and extensible framework for farther development.

Generally, NRH-up2date allows you to provide exactly the same content to your clients as RHN provides, with minimum administration. Having a full, updated package repository also suggests that you can greate your own, updated cds and iso's for redhat releases, also allowing you to customise your new installations, even farther than the kickstart method would allow.

Future development

NRH-up2date is being actively developed. It has already reached a state where it provides full capabilities of an anonymous up2date server. The next logical step is implementing client systems tracking, and creating your own, easely manageable, update subchannels.

Finally, i want to believe, that NRH-up2date will be able to reach a level, where it will be able to provide an alternative to the commercial services RedHat is currently providing, like basic up2date functionality that does involve client tracking. In an open source world, RedHat is currently nearing a position of monopoly in several areas, so it believes that it can dictate their rules to us, like cutting support for their releases to one year, making us pay at least 350$ per year per server, which is completely unacceptable, and is more expensive than even M$ products.

I hope, that competition from open source projects like NRH-up2date, will balance the open market forces, which eventually will allow us to get better service, for lower costs.