3. Introduction

The configuration described here was developped since Summer 1996 at the CUI, University of Geneva. The Computer Science Department uses several servers and a number of PCs, which fall into two classes:

• computers devoted to students
• computers devoted to research and teaching assistants

• Every computer should be able to run under Linux, DOS, Windows 3.1, Windows 95 or Windows NT. One should be able to choose the desired operating system for each session.
• All softwares, including operating systems, should be take from the server, in order to facilitate the installations and upgrades.
• Clients computers should be able to run without any write-access on the server (for security reasons), except for their home directory.
• Client-side configuration should be reduced to its very minimum. Clients should automatically get their IP configuration parameters from the server, and this information should be located in a single file, used for all operating systems.
• Since almost every computer now has a hard-disk, clients should be able to take profit of it for reducing network load and as temporary storage space for the user.
• Users must have a login to be able to use any of the computers.
• The login should be the same for all operating system and should let the user access its unique home directory, common to all operating systems.
• Student (and secretary :-) computers should be fully cleaned up at each start. That is, the PC should always look like if it were just installed.
• Every computer has to be protected from virus attacks.

3.1 Boot ROM and Hard-disk

Bootproms exist for quite a long time, but until recently, they were solely used with diskless computers. Since 1996, this How-to has been claiming that bootproms are even more interesting for computers which have a local harddisk, since they allow to take profit of both sides:

• A boot rom make the configurations more robust, since it ensure that the computer will always boot the same way, no matter any virus or partition table crash. It can be used, as we did, to cleanup the harddisk even before the operating system is loaded.
• A local harddisk make the configuration more efficient, since it can reduce the network trafic through caching, and allows for efficient swap.

Note that you can still use the tools described below in an old fashioned way, that is as a simple kernel/ramdisk loader, even for diskless computers. However, we do not encourage this use.

3.2 The Network

The University of Geneva owns a class B domain, subdivided into several subnets. The CUI uses four subnets, among them one is dedicated to students.

Originally, our PCs were concerned about two network protocols: IPX and IP. On the IPX side, we used a single Novell Netware 3 server for sharing software and users files for DOS and Windows. On the IP side, we used a SUN server for sharing software and users partitions for Linux, with NFS.

In our latest configuration, we do not any more use IPX. There is a single Unix server (which could be Linux as well as a SUN), sharing software and user files using NFS for Linux clients and using SMB (NetBIOS) over TCP/IP for Dos and Windows clients. In this way, we have a single home directory used by all operating systems.

3.3 How it Works

1. When a client PC is turned on, it first performs the traditional system checks before the TCP/IP Bootprom or PXE Boot ROM takes the control.
2. The bootprom issues a BOOTP/DHCP request in order to get its IP configuration parameters.
3. If the server knows the PC issuing the request, it will send back a BOOTP/DHCP reply with informations such as the client's IP address, the default gateway, and which bootdisk image to use.
4. In case of a PXE boot ROM, there might be some more exchanges between the client and the server to determine installation parameters.
5. The bootprom then downloads the boot image from the server using the TFTP protocol. The boot image happens to be a small program called bpbatch, our boot-time batch file interpreter.
6. The batch interpreter is started. At this time, it is almost alone in the computer memory. There is no operating system loaded, except the preboot execution environment (offered by the Boot ROM).
7. The batch interpreter look in the BOOTP/DHCP reply for command-line options, and in particular for the name of the batch to execute.
8. According to the instructions in the batch file, it will for instance:
   1. Load a national keyboard mapping
   2. Authenticate the user according to a remote server (Unix, Radius or Windows NT)
   3. Let the user choose between the available operating systems
   4. According to the operating system choosen, repartition the hard-disk and quick-format some partitions
   5. Check if an up-to-date compressed image of the selected OS is present at the end of the disk. If not, it download it using TFTP
   6. Uncompress the selected OS to the main partition
   7. If the selected OS is Linux, load a kernel and start it
   8. If the selected OS is DOS or Windows, simply let the computer boot on its fresh new hard-disk
   For DOS and Windows 3.1, we use the freely available Microsoft LanManager for DOS (search the network for the mirror nearest to you; the distribution consists of three files named disk1 to disk4) as SMB client. Microsoft LanManager supports dynamic configuration using DHCP. After logging in, the user is faced to DOS, and can start Windows 3.1 by typing the traditional win command. Note that at this point, DOS and Windows 3.1 appear to be installed locally. For Windows 95 and Windows NT, we also use Microsoft SMB client (called Client for the Microsoft Network), that supports dynamic configuration using DHCP. We reduce network load using Shared LAN Cache, a nice and powerful network-to-disk cache program.

For "safe" computers (ie. for assistants computers), once the computer has been booted once using the above described system, the boot script simply redirect the boot to the local hard-disk, without cleaning it again. This allow users to leave data on their local hard disk. But whenever the configuration gets corrupted, the user can simply choose from the boot menu in order to have a fresh installation.

3.4 Related non-commercial documentations

This configuration has been successfully reproduced at several places around the world. A few people have written some hints and tricks that complement this How-To. If you did so and that your page is not already referenced in this documentation, please send an e-mail to Marc.VuilleumierStuckelberg@cui.unige.ch. And if you experience problems while reproducing this configuration, have a look at these pages !

• http://www.br.fgov.be/RESEARCH/INFORMATICS/info/bootp.html, by Alain Empain of the Belgium National Botanic Garden. Many useful sample scripts, and a nice PERL program to automatically generate graphic menus and corresponding HTML documentation from a higher level description.
• http://www.katedral.se/system/elevsyst, by Johan Carlstedt of The Cathedral School of Uppsala, Sweden. At this day, the configuration described at this place is still based on the previous version of the remote-boot tools. However, almost everything remains applicable, given a few changes.
• http://vitoria.upf.tche.br/~fred/, in portuguese, by Frederico Goldschmidt of the Passo Fundo University, Brasil.
• http://www.etse.urv.es/~larinyo, in spanish, by Lluis Arino, of the Escola Tecnica Superio d'Enginyeria, Spain.

You can also send me your BpBatch script if you want me to include it in the sample scripts collection.