Document Home

Cluster Package Management

By now some of you have likely started to wonder how one goes about managing packages within the cluster when we have not configured any route to the external world for machines within the cluster? For a generic cluster machine this may be a minor concern, but from the standpoint from the cluster as a whole it is hardly such. In the Ralphzilla cluster, for example, it might be regarded as desirable at some point to install an updated version of postgresql, or there may be an updated version of mfs we want to use. While it is true that one would be far less likely to routinely upgrade a cluster than a workstation, that is not the same as saying that the capability to do so is irrelevant. It is, in fact, precisely that kind of capability that makes the cluster useful beyond a relatively short time frame.


When I started to consider methods for creating a package repository visible from within the cluster, my first thought was to maintain a local mirror of the testing debian distribution on the cluster controller, Ralphzilla. I dropped that when I realized that it would either require a substantial download and a storage area large by the standards of this cluster or a rather laborious process of going through the distribution identifying packages of interest, but it did get me thinking along the appropriate line, and I ultimately realized that the appropriate approach would be to employ the apt-move utility.


The apt-move utility script is employed to move a collection of debian package files into the proper directory structure for a debian distribution. In the Ralphzilla cluster, virtually all of the packages that are installed within the cluster are also installed on Ralphzilla. This is likely to represent a characteristic common to many mosix systems, as processes would tend to be spawned on the cluster controller and migrated to other machines in the cluster. Given this context, the basis of the distribution mirror for the cluster can be created from the package cache for the cluster controller, as long as the downloaded deb have not been deleted from that machine. If you installed from a set of CD's you can still follow this strategy, because the local package cache exists regardless of the source used by used by apt-get. Even if each of the cluster workstations have CD drives installed, you will have a much easier time with general package management if you install from a common intra-cluster mirror.


Before you go further, you should give some thought to the location of the repository. While the base distribution used by cluster workstations may not be much more than 20-30 Mb. in size, if you have much installed in the way of Xwindows applications on the controller and dedicated applications around the cluster you are probably going to want to allow for at least 150 Mb. to give the repository room to grow. I installed an older 850 Mb. ide drive in the cluster controller which is mounted at the mount point deb_mirror in the system fstab, and I use that space as storage for copies of the gzipped tarballs of source packages I install elsewhere on the cluster as well as for the cluster deb repository. There is no way I'm going to fill that 850 Mb. drive with the debs used on cluster machines, and this gives me a handy reference repository of what is installed on the cluster.


Before you can create the repository you have to customize the file /etc/apt-move.conf to reflect your system configuration. The customized copy from Ralphzilla is included here - if you have installed debian without altering the location of package directories the only setting you will have to change is LOCALDIR on line 19. The file is well-documented internally and on the man page for apt-move. Rather than going through the changes I'll just suggest that reading through it should make those changes apparent.


Once you have customized that file as appropriate for your installation, the command "apt-move update" will copy files from you local package cache and create the local mirror. To move deb files into the repository that have not been installed on the machine, use the command "apt-get movefile file(s)", which will add the file(s) specified on the command line to the repository. Although I've not yet had reason to use it, the command "apt-move mirrorbin file(s)" will fetch the specified file(s) from the sites specified in the APT-SITES setting of /etc/apt-move.conf and place them in your local mirror. Unless you have gone through the rather laborious process of creating an .exclude file, do not run the "apt-move mirror" command. That would compare the list of packages in your mirror with the packages at the sites listed in the apt-sites tag, and synchronize your mirror with those sites. I can virtually guarantee that you do not want to do this.


Once you have created the repository on the cluster controller, you need to figure out how you want to access the repository within the cluster. If the cluster is functioning as a cluster and you have installed mfs, you have at least three options: ftp, file (using mfs, or samba if installed and configured), and ssh/rsh. Since ftp is easiest to configure, and it is possible you would want to use apt-get to configure one of the others, this example will use ftp. (Besides, that is what I used.)


First, make sure that the ftpd daemon is installed on the cluster controller ("apt-get install ftpd"). The repository will have to be readable by the id under which ftp will connect to the machine, so for the sake of simplicity I will create an id and assign appropriate rights to that id. First, log on to the cluster controller and su to the root account. I'll just call the new id "cluster" and use "clusterpass" for the password in this illustration. First, run "adduser" to create the id and assign the password. Then su to that account and grant it rights to the repository. ("su cluster" and "chmod u+r /deb_mirror") Once that is done you can access the repository directory under that id. Now all you have to do is create a sources.list file that can be created to the /etc/apt directory on each of the cluster machines. In the example I've created, assuming that the name is the cluster controller is Ralphzilla, the only line this file would need reads

"deb ftp://cluster:clusterpass@ralphzilla/deb_mirror testing main contrib non-free"

(Obviously, Ralphzilla myst be identified in the /etc/hosts file for this to work.)


That's it ... you should now run "apt-get update" on the workstation to synchronize package lists. After that you'll be able to install packages to the workstation using "apt-get install".