Lists & Archives
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."
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:
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.
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.
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.