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
We developped the current configuration with the following aims:
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.
These constraints lead us to base our configuration on bootprom
tools. We first developped new tools for the excellent
Now that a standard for preboot execution environments as finally emerged,
we ported the tools so that it now also works for any PXE-compliant
bootprom. PXE boot roms, also called LanDesk Service Agent, are now
distributed with almost all on-board network adapter.
For more info on PXE and Intel Wired for Management standard
in general, read from http://www.intel.com/managedpc.
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
A local harddisk make the configuration more efficient, since
it can reduce the network trafic through caching, and allows
for efficient swap.
Today, we have the pleasure to see that all computer manufacturers have
come to the same point and provide boot roms as part of new computer
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.
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.
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.
The bootprom issues a BOOTP/DHCP request in order to get its IP
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.
In case of a PXE boot ROM, there might be some more exchanges between
the client and the server to determine installation parameters.
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
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).
The batch interpreter look in the BOOTP/DHCP reply for command-line
options, and in particular for the name of the batch to execute.
According to the instructions in the batch file, it will for
Load a national keyboard mapping
Authenticate the user according to a remote server
(Unix, Radius or Windows NT)
Let the user choose between the available operating systems
According to the operating system choosen, repartition
the hard-disk and quick-format some partitions
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
Uncompress the selected OS to the main partition
If the selected OS is Linux, load a kernel and start it
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.
Students computers can be turned off the hard way at any time
without risks, since the hard disk is reinitialized at each start.
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.
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 !
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.