We decided to store the master copy in the repository of our file system revision control system fsrcs. It can handle at least text and binary files, symbolic and hard links, character and block device files and directories with proper access permissions and ownership.

The current implementation stores the master copy on the server. A new version of the master copy is manually created when a major change in the software configuration of the clients occurred.

Multiple revisions can be managed by our system. The repository is implemented as a file-tree. Underneath the root there are directories with the name of each revision. New or changed files (and directories and links) are stored inside each version-directory. However, a symbolic link to the original file in the repository is created when there was no change. Symbolic and hard links are stored in separate directories for each version. The initial repository is created by copying the whole tree into the directory of the first version.

The program is implemented in the programming language perl [WCSP96].

Check-In

This section describes the updating process, done on the check-in of the new version. We distinguish a different behavior for files (plain files, character and block special files), symbolic links, hard links and directories. The procedure for directories is fairly obvious. If a directory is found, the check-in function is called with its name (recursion). Directories are created with the access rights and ownership of the original. If a directory does no longer exist in the new version, no reference to the previous version is made. Files are compared with the current version of the file in the repository if it exists. If the size, permissions, ownership and group are the same, this file is first marked as unchanged. The check- in function performs link optimization.

If a whole subtree is unchanged, a symbolic link is created at the highest possible level in the repository. If a reference to a prior version of an object within the repository is necessary, another link optimization is done. The check-in function does not simply create a symbolic link to the prior version, instead it creates a reference to the original object in the repository. These two levels of link optimization guarantee a minimum number of symbolic links in the repository. Compared with RCS and SCCS [BB95], the smallest piece is an entry of a directory. Your software does not bother about the differences between text or binary files.

REGEDIT4
[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\VNETSUP]
"ComputerName"="hostname"
"Workgroup"="PC7"
[HKEY_LOCAL_MACHINE\System\CurrentControlSet\control\ComputerName\ComputerName]
"ComputerName"="hostname"

Check-Out

On check-out, the program compares the entries of the given check-out directory with the entries in the repository. Missing entries are created and entries in the checkout-directory that are not in the repository are recursively removed (directories) or unlinked.

Limitations

The current version of fsrcs has no support for access control lists (ACL). Some UNIX operating systems support ACL which allows the file owner to permit or deny access to a list of users. However, this feature is neither used nor supported by Linux and Windows 95 installations. Another restriction exists for symbolic links. Many UNIX operating systems do not set the permissions for symbolic links correctly. On repeated checkouts symbolic links will probably be recreated even if they have not been changed.

Availability

Our file system revision control system is available from ftp://ftpai.wu-wien.ac.at/pub/fsrcs/fsrcs.tar.gz.

Administration tasks

The time to administer a set of PCs is reduced to the installation or update of new software on a single PC. Our tools guarantee the correct installation of the software on all other PCs. If some files or partitions have been changed, our tool repairs the installation automatically and quickly without user interaction.

Installing New Software on a PC

Administration sessions require the following steps to install or upgrade software:

• Make a full update (boot with option ``c'').
• Uninstall the prior version of the software, if required.
• Install the new version of the software.
• Upload the new installation to the server.

Finding the Correct Configuration

The most complicated task is searching for mandatory customizations between different PCs. First, we tried to eliminate individual configuration parameters, if possible.

Linux

Linux software distributions often configure their network parameters statically. A networked Linux PC needs a unique IP address and hostname. First we installed the Linux distribution Redhat 4.0 (Colgate) and then replaced the file /etc/rc.d/init.d/network with the file /etc/rc.d/init.d/rc.bootp of the package bootpc [Haw96]. This package demands the network parameters with a bootp request from the server, configures the network interface and creates the files /etc/hosts and /etc/resolv.conf. After this change in the configuration of Linux, there are no individual configuration parameters left.

Windows 95

We configured IP networking to obtain the network parameters with a DHCP request from the server. Windows 95 uses the binary files system.dat and user.dat to store its configuration. These files are modified by the program regedit (see Table 1) of Windows 95 which is called from dosemu [LS97] after the file checking phase. Plug and play (PNP) cards need entries in the registry, too. Otherwise Windows 95 will wrongly detect new hardware and try to install new software. First we exported the registry as text files of two different PCs using regedit. Then we looked at the differences between the files with the program diff. We found that the necessary entries for our PNP sound cards are in HKEY_LOCAL_MACHINE\Enum\ ISAPNP\. We generated a similar text file in which we replaced a generic string with the PNP-ID of the sound card.

Periodical Checks

The cron daemon of each PC is configured to run our management software each day early in the morning.

Performance

For software distribution a UNIX server with Pentium processor, approx. 128 MByte main memory and a PCI based network interface will be enough to serve approx. 30 client PCs.

Our hardware consists of one Digital Alpha Server 4000 5/300 (2 × 300 MHz CPUs, 1 GByte main memory, 20 GByte hard disk, 2 × 100 Mbps full duplex ethernet cards), one Cisco Catalyst switching hub, 27 PCs (Pentium Pro 200 MHz CPU, 64 MByte main memory, 2 GByte hard disk, 10/100 Mbps ethernet card currently used in 10 Mbps mode).

The size of Windows 95 and applications is currently 202 MBytes (3413 files in 194 directories). The size of Linux is currently 707 MByte (38372 files, 2797 symbolic links, 735 character special files, 304 block special files, 706 hard links in 2171 directories)

Installation from scratch is done with the prior described kernel and root file system on a boot floppy which requires approx. 42 minutes for partitioning, formatting, checking and copying of both operating systems. After automatic reboot of the installation system, the two operating systems are available.

Checking of the whole installation (Linux and Microsoft Windows 95) with minor modifications requires approx. eight min. Checking our installation of Microsoft Windows 95 requires approx. two min.

Each of the 27 clients needs about 20 minutes when all of them check their whole installation at the same time against the server. In this case the server is the limiting resource. Currently, the server is not tuned for optimal performance.

Conclusion

By using open operating systems for systems management, it was easy to develop a powerful tool for UNIX and Windows 95 operating systems. The users are greatly satisfied with the ability to repair the local installation by themselves if something goes wrong with the software. The time spent on troubleshooting has decreased by 90%.

Future Work

This implementation proves, that Linux is a suitable operating system for automated installation and update of software.

This version of software requires PCs with an equal hardware configuration. We plan to extend the shown concept to handle different hardware installations by extending the revision control system to find the differences between two software installations. The program rdist seems to be the limiting factor on the server side. There is one independent rdist process for each client which scans the state of each file. This causes a heavy system load on the server when many clients perform an update at the same time. This problem could be solved by extending rdist using a state database. Another area of improvement is in adding revision control capabilities to rdist directly.

Author Information

Gottfried Rudorfer works at the Department of Applied Computer Science at the University of Economics and Business Administration where he received his MBA. His research interests are centered on issues of distributed database systems, administration of heterogeneous computing environments, operations research and artificial intelligence. He has been a system administrator since 1993. Reach him via mail at University of Economics, Augasse 2-6, A-1090 Vienna, Austria; or electronically at Gottfried.Rudorfer@wu- wien.ac.at.

Bibliography