This chapter explains how you can manage boot configurations centrally using diskless workstations. It explores the reasons why you might want to use diskless workstations, as well as looking at some of the drawbacks to their use. After some background on boot PROMs and how they work, it describes in detail how to set up diskless workstations in a single- or multi-server environment.
Diskless workstations are client workstations that boot from a file server rather than from a local disk. The "disk" in "diskless" really refers to the boot disk. So-called diskless workstatifig frequently have floppy disk drives and sometimes have hard disks, but they don't boot from them. Instead, their boot configuration and startup files are stored on a server and accessed over the network. Diskless workstations generally boot up more quickly than workstations booted from floppies but not quite as quickly as workstations booted from a hard disk.
This bootup behavior is achieved using a boot PROM (programmable read only memory), an optional chip that plfig into a special socket on a network adapter. The boot PROM takes control of the workstation boot process and allows a special container file on the server (a boot image) to act like a phantom boot floppy disk. The effect is quite convincingóif the workstation has a floppy drive, its drive activity LED lights up and its spindle spins as it reads from a disk that does not exist!
Once the bootup process has been completed, the boot PROM retires gracefully and the workstation behaves as if it had been booted from a floppy disk.
It is worth noting at this point that there are two basic types of boot PROM: the older Novell Remote Boot PROMs and the more recent (since 1992) Enhanced Remote Boot PROMs. The former type are variously referred to as IPX PROMs, traditional PROMs, or Novell PROMs. The latter are referred to as RPL PROMs (RPL stands for remote program load), enhanced PROMs, IBM RPL PROMs, or FIND-FOUND PROMs. Both types carry out a similar function but in quite different ways. The differences in behavior are explained in context throughout relevant sections of this chapter.
This is an overview of the sequence of events which occurs when a diskless workstation boots from a file server:
The server that the workstation is connected to after loading the workstation shell need not be the same server from which it received its boot image.
Boot PROMs can be a powerful management asset to many network managers, but they are not always appropriate. This section looks at the pros and cons.
Diskless workstations are particularly suited to environments where large numbers of similarly configured PCs are used, or where users do not maintain the software on their own machine. Booting workstations from a file server has three major advantages over using floppy or local hard disks as boot media:
The next three sections examine these advantages.
The simple task of upgrading a driver can be a logistical nightmare if that driver is used by a large number of client workstations. If the driver is stored on the hard disk of each client, you need to visit each workstation before making the change. If your users have their own boot floppy disks which they use to connect to the network, you are faced with the task of recalling and updating all boot floppy disks that are in circulation.
All startup files for diskless workstations are stored in a boot image file on the server, so you can manage them from any client that has access to that server. This gives you the luxury of being able to reconfigure the most remote workstation on the network without having to physically visit it.
A number of workstations might have the same type of network adapter and load the same version of DOS, same network drivers, and same TSRs. Since all files required to boot a diskless workstation are stored on the file server, you can avoid maintaining duplicate sets of files by having all such workstations use the same boot image file. If the workstations need a new driver, you only need to update the boot image.
Using diskless workstations spares you the management overhead of all those local disks. Whether they're hard disk or floppy, conventional boot disks are prone to a range of disasters:
By storing the boot material in a safe, central place you can make good use of the security features of your network to protect your users from themselves and others.
Diskless workstations are "read-only" in another sense: if a diskless workstation has no floppy drive, it cannot be used to download confidential data or to pirate software from your server. Likewise, it cannot be used to upload pirated software, viruses, or other undesirable material.
Diskless workstations are not for everyone. Some reasons for sticking with more conventional boot media are
Your users might prefer to manage the configuration of their own workstations. They might want the ability to experiment, or might not want to call you every time a minor amendment to CONfig.SYS is required.
If so, you can consider installing both boot PROM and a hard disk. Users then would have the option at startup time of booting from the server (your configuration) or from the hard disk (their own). A choice of boot options can provide users the best of both worlds.
If you decide to go this route you should negotiate with users beforehand to ensure that you agree on where the responsibilities of each party begin and end. If you maintain the boot image but users consider you responsible when they mess up their own hard disk, you might find yourself with a doubled maintenance burden.
Boot PROMs cost money, but remember that the additional cost of a boot PROM in each workstation must be set against the cost of providing a hard disk or boot floppy disks to all users. You should also factor in the cost of the administrative overhead of updating local boot disks (either hard disk or floppy).
If the server is down, diskless workstations will not boot. Of course, if applications are stored on the server, then users wouldn't be able to do anything even if they could boot up!
In practice, with boot image files stored on multiple servers, this usually is not a problem.
If your client workstations use a wide variety of network adapters, then you may need to have several boot image files. Each can take up as much as 700K of disk space on the server. Besides reducing the amount of available free space on the server, a large number of boot image files can have implications for your backup system.
Adding an additional boot server does not affect the amount of disk space required on any one server, of course, as each server needs to hold its own copy of each boot image. Bear in mind, though, that the total amount of disk space used by all servers for storing boot images increases proportionately with the number of boot servers.
Diskless workstations also deliver your server a performance hit. The scale of the effect on performance depends on the number of diskless workstations, the number of servers supplying the boot images, and the frequency with which the workstations are booted. For example, in a student laboratory environment where a large number of workstations are booted regularly, the server has to send the boot image out on the network quite frequently. If the machines are all booted more or less on the hour, as is often the case, there may be intermittent but serious performance degradation on the server as dozens of machines clamor for boot images at the same time. In contrast, a small number of diskless workstations booted once or twice a day would have no noticeable impact on server performance.
Adding an additional boot server should give a proportionate decrease in the boot image load on each server. The total server resources given over to delivering boot images to the clients might increase slightly, however, as each server has to cache its own copy of the boot images.
There may also be a degradation in performance on the network between the server and the remote-booting clients. Those boot files need to travel to each client each time it boots, so frequent reboots can generate a lot of traffic that would not occur in the case of locally booted machines. The preceding comments about server performance overhead apply equally here: Large numbers of remote booting clients rebooted simultaneously at regular intervals are likely to cause problems, while an occasional reboot will pass unnoticed.
If you manage the boot configurations of a very small number of clients, or if your users are capable of configuring their own workstations, then it may be easier to deal with boot floppies or bootable hard disks than to set up boot image files.
In summary, you need to consider whether the advantages of central boot management are worth the overhead. Boot PROMs cost money and there is a disk space overhead on the file server. On the other hand, boot PROMs can save a lot of time and tedium in configuration maintenance for yfigand your users.
This section deals with planning and purchasing issues, and describes how to set up a workstation to boot from a server.
:
This process is closely linked to the workstation adapter installation and configuration. Refer to chapter 6, "The Workstation Platform," for detailed information on this topic.
The smaller the number of boot images you have to manage, the better. Each boot image can support only one MLID (ODI network driver), so it makes sense to stick with the same network adapter model as much as possible when buying new machines or upgrading existing ones.
That's not always practical of course, but you should at least bear in mind when buying adapters that every new model you install on your network means another boot image file to maintain. As a minimum concern, make sure your servers have sufficient disk space to store all the necessary boot images and that your backup system can cope with the volume.
Make sure when ordering that you specify which type of PROM you require, the older IPX or the more modern RPL. Unless you have a particular reason for wanting IPX PROMs, specify RPL.
If you're ordering a set of adapters and PROMs that you intend to manage as a set, using a single boot image, your order should clearly specify the make and model of the adapter and PROM. Two different models might not work with the same drivers or settings. Watch out also for motherboard differences that may prevent you from using the same interrupt or RAM address on all machines in your setóthe boot image can only hold one copy of NET.CFG.
Finally, beware of buying into discontinued lines. You might not be able to find matching adapters or PROMs in the future, and if you have to replace any hardware, you might be forced to set up a whole new boot image, possibly for a single workstation out of dozens.
***
If you are installing diskless workstations for use in an unattended environment, consider buying adapters with a hardware jumper that can be set to disable software setup. This prevents users from innocently or maliciously reconfiguring the adapter to prevent it from booting.
***
It is advisable to follow the manufacturer's instructions when installing a boot PROM. It is not uncommon for PROMs to arrive without any documentation, however, so follow these general guidelines if you have nothing else to go on:
Once the boot PROM has been physically inserted, it must be configured for use. The boot PROM must be activated and configured to use a specific RAM area.
The procedure for enabling the boot PROM is different for every adapter model. Older adapter models such as the Novell NE1000 and NE2000 use physical jumper blocks. Remote reset jumper settings for Novell adapters are given in the Novell Ethernet Supplement shipped with all copies of NetWare.
More recent adapters that are partially or totally software configurable can be configured for remote boot by specifying a RAM address for the PROM using the adapter's setup utility. Even if you cannot obtain a copy of the adapter documentation, it is vital that you get a copy of the setup/configuration utility for the particular make and model of adapter that you are using.
Don't rely too much on claims of compatibility: "NE2000 compatible" adapters may be fully software compatible with the NE2000 but may have a completely different physical layout, a different number of jumpers, or a software setup utility that was lost before the adapter reached you.
Boot PROM installation time is a good time to record the information you will need to configure and manage the diskless workstation. That's because most of the information concerns the adapter you have in your hands while installing the boot PROM.
Whatever data you decide to gather, record the information systematically. Use a database package to keep track of the information if you're dealing with many diskless workstations.
The data required is
The network number is required for creating the BOOTCONF.SYS file. You can find it on the BIND IPX line in the server's AUTOEXEC.NCF file.
The Ethernet address might be printed on the adapter, but if not, you should be able to determine it using the adapter's setup/diagnostic utility. Record the full, 12-digit Ethernet address in hexadecimal form. Separate pairs of digits with colons for clarity (00:00:E8:C2:57:6E) is easier to read than a string of digits (0000E8C2576E) and provides you less chance to accidentally drop a digit.
One way to find an RPL PROM's Ethernet address is to boot up the workstation that it is installed in, without connecting the workstation to the network. The Ethernet address will be displayed along with the adapter configuration details while the PROM waits in vain for an RPL server to respond.
***
If all other means fail, you can see the address of an adapter with an IPX boot PROM using the TRACK ON command at a server console. See details in the later instructions in the "Type of Boot PROM (IPX or RPL)" section.
***
The adapter model and configuration information should be at hand now since you've just used it to configure the adapter to use its boot PROM. Record the make, model, connector type, IRQ, I/O port, and RAM address.
Make sure you know which type of boot PROM you have just installed! This information is vital when preparing the boot image and the server. The RPL PROMs date from about 1992 onward and often are clearly labeled as RPL PROMs. Token-ring adapters always use RPL PROMs.
If you're still not sure whether the PROM is RPL or IPX, try the following:
Figure 28.1 This is a typical server TRACK screen.
Take the time to write down enough information to help someone else locate this particular workstation. If there are bad packets coming from 00:00:E8:C2:57:6E and your data only tells you that the workstation with that adapter is one of 20 workstations in room 120, you have quite a bit of work to do to find the faulty machine. It's much more useful if your data tells you that it is "third PC on left, back row, room 120."
Even the most detailed descriptions of physical location are of limited use if someone moves the workstations around. Take note of the workstation model and serial number so you can be sure that you have a correct match of Ethernet address and workstation.
The name and number of a contact person can save a lot of time, especially if the diskless workstation is very remote. If you just want to know if PC X is booting up as usual, you can call someone who is close to it and can check quickly, thereby saving yourself a long trip.
This section explains how to prepare a boot image file for a DOS workstation.
Before you begin, decide which version of DOS the diskless workstation is using. Note that all the DOS external commands have to be stored on the server for access by the diskless workstation. Since DOS versions don't mix very well (for example, DOS 6's XCOPY won't run on a machine booted using DOS 5), each server needs to keep a separate copy of each version of DOS used by any diskless workstations that may connect. It makes sense, therefore, to keep the number of DOS versions to a minimum.
Check that you have enough DOS licenses to cover all diskless workstations! If you intend to use more than one DOS version, check that you have enough licenses for each version. DOS upgrades are not free.
You need the following to prepare the boot image file:
***
A laptop computer with PCMCIA network adapter, a range of transceivers, all the necessary network drivers, and your favorite diagnostic utilities is particularly useful when you're setting up and testing remote booting workstations.
***
Finally, if the diskless workstation has an IPX boot PROM you need a copy of RPLODI.COM. This is because IPX boot PROMs were designed to work with older, dedicated IPX drivers, rather than ODI drivers. They communicate with the server using dedicated IPX code, which is fine as long as the adapter loads a dedicated IPX driver from the boot image. If an ODI driver is loaded instead, the ODI code interferes with the boot PROM's IPX code, meaning that the PROM can read no more of the boot image. The error message
appears on-screen and the workstation hangs. RPLODI.COM fixes this problem by looking after the hand-over from the PROM's IPX code to the boot image's MLID.
RPLODI.COM is needed only for IPX boot PROMs, not for RPL boot PROMs.
***
You occasionally might have to replace an IPX PROM with an RPL PROM. If the workstation's boot image still loads RPLODI.COM, your users will see an error message and hear an irritating beep when RPLODI.COM discovers that the workstation on which it is being run has not been booted using an IPX PROM. If the boot image is not still used by IPX PROM workstations, simply remove the RPLODI.COM load line from the boot image's AUTOEXEC.BAT. If, however, there are still IPX workstations which use the boot image, you don't have to create a whole new boot image for this single workstation. Edit the AUTOEXEC.BAT to redirect RPLODI.COM's output to NUL, with
RPLODI > NUL
This stops RPLODI.COM from beeping and displaying its error message on-screen. RPLODI.COM continues to do its job for IPX PROMs but quietly ignores RPL PROMs.
***
Use the following sections to prepare the master boot floppy that the boot image will be built from.
Boot a PC that uses whatever version of DOS you want the diskless workstation to use.
Format a floppy disk using the /S option (DOS) or choosing Disk,
Make System Disk in Windows File Manager. The floppy disk then contains
a boot sector, two hidden system files, and COMMAND.COM. This disk is to
be your master boot disk, so be careful with it. Label it clearly with
the identity of the diskless machine, the date created, the DOS version
used, and the type of Ethernet adapter.
Copy all other required files to the master boot disk. Remember that you need to include all files used when booting, up to the point where the adapter's driver is loaded.
In particular, make sure you have the following:
***
EMM386.EXE "remembers" the path with which it was loaded so that it can reload at a later stage. If it is loaded during a remote boot, the path is A:\. This can cause problems when, for example, a remote booted workstation tries to load Windowsóit looks for EMM386.EXE on drive A but the file's not there any more. To avoid errors, use the /Y switch to specify the full path to a copy of EMM386.EXE after logon. For example, you might use
DEVICE=EMM386.EXE /NOEMS /Y=F:\WINDOWS\EMM386.EXE /X=D000-D800
***
If your copy of DOSGEN is version 1.2 or later, then you can store some of these files in subdirectories. If it's older, leave everything in the root directory of drive A because older versions of DOSGEN don't support subdirectories.
If this is the only boot image you will have on the server, copy AUTOEXEC.BAT to the SYS:LOGIN directory. See the later "Multiple Boot Images" section if you expect to have more than one boot image.
Any programs run from AUTOEXEC.BAT after the point where the workstation shell is loaded should also be copied to SYS:LOGIN. This might include mouse drivers, menu programs, and so on.
The boot PROM shuts down once the workstation shell is loaded during remote boot. Its job is doneóthe PC has found a boot device, loaded an operating system and network drivers, and connected to a server. At this pointówhen NETX.EXE or VLM.EXE loadsóthe diskless workstation switches from reading a batch file in the boot image to reading a batch file of the same name in the SYS:LOGIN directory of the file server.
It does this by keeping track of its position in the batch file as it processes the boot image. This position is recorded as a byte offset amount from the start of the batch file. When control is handed over to the SYS:LOGIN batch file, processing begins at the byte offset position.
As long as the contents of the two batch files are identical, the use of the byte offset ensures a smooth transition from boot image to logon area. If the copies are not identical, the byte offset might point to the wrong location in the second batch file and strange results might occur. Consider these two batch files:
Boot image copy of AUTOEXEC.BAT
lsl
smc8000
ipxodi
netx
mouse
SYS:LOGIN copy of AUTOEXEC.BAT:
lsl
ne2000
ipxodi
netx
mouse
The only difference is that the first contains smc8000 where the second contains ne2000óthe latter is one character shorter. The byte offset calculated for the first file is therefore too great for the second file, which will start processing after the m in mouse; the first command executed will be ouse, probably resulting in an error.
That's what can happen with a one-character offset difference. If one file contains entire lines that the other file does not contain, the likelihood of error is much greater. The second batch file might try to load network drivers that are already in memory or that clash with software already in memory. That the workstation might hang is a possibility.
The byte offset mechanism can give rise to difficulties with multiple boot images. Each boot image insists on using its own byte offset when passing control to SYS:LOGIN. If the workstation shell has been loaded from AUTOEXEC.BAT, this can mean different byte offsets being used on the same AUTOEXEC.BAT fileóafter all, there can only be one copy of this in any one directory.
There are various tricks that allow you to work around this to some extent, such as renaming all MLIDs so that they are exactly the same length. These tricks are based on the fact that, strictly speaking, the files need not have identical content as long as the byte offset after loading the workstation shell ends up at the correct value. Trying to maintain files this way, though, is bound to cause problems.
There is an easier approachódon't load the workstation shell from AUTOEXEC.BAT. Instead, rename the AUTOEXEC.BAT for each workstation using a name matching the boot image name. Then create a dummy AUTOEXEC.BAT that calls this surrogate AUTOEXEC.BAT. As long as each surrogate is uniquely named, you can maintain a copy of each in SYS:LOGIN. Then you just need to make sure that the surrogate batch file in SYS:LOGIN is an exact copy of the surrogate in the corresponding boot image.
For example, given two batch files named NE2$DOS.SYS and SMC$DOS.SYS:
1. Rename AUTOEXEC.BAT on the NE2000 master boot floppy to NE2AUTO.BAT.
2. Create a new AUTOEXEC.BAT on the NE2000 master boot floppy consisting of one line:
NE2AUTO
1. Copy NE2AUTO.BAT to SYS:LOGIN.
2. Rename AUTOEXEC.BAT on the SMC master boot floppy to SMCAUTO.BAT.
3. Create a new AUTOEXEC.BAT on the SMC master boot floppy consisting of one line:
SMCAUTO
1. Copy SMCAUTO.BAT to SYS:LOGIN.
You then can maintain the two boot images and their surrogate AUTOEXEC files independently from one another. The AUTOEXEC.BAT files in the boot images remain thereóno AUTOEXEC.BAT is required in SYS:LOGIN unless it is used by another boot image.
***
Adopt this procedure even if you are creating only one boot image. It takes little or no effort, and greatly simplifies the process of adding more boot images later if that becomes necessary.
***
Test the boot disk now by using it to boot the target workstation. Don't skip this step! You need to test the exact set of files on the diskóthat CONFIG.SYS, those particular NET.CFG entries, the versions of the network driversóon the workstation or workstations that will actually use the boot image. Don't assume that because a boot floppy disk works properly on one machine, it will work on another. Even if both have the same type of Ethernet adapter, you might have difficulties with differences between model revisions or clashes with other adapters that were not present in the first workstation.
If you have loaded RPLODI.COM, expect an error message when you boot the diskless workstation using the master boot floppy. RPLODI.COM looks for a stamp left in memory by the boot PROM's IPX code. As you're booting from a floppy disk, the boot PROM code is not present, so RPLODI.COM beeps and displays an error message:
ï FATAL: BootROM Stamp not found.
This message should appear only when the workstation boots from the master boot disk, not when it boots from the file server.
This procedure copies the contents of the master boot disk to a boot image file on the server.
The default name for a DOS boot image file is NET$DOS.SYS. You need a separate boot image for each boot configurationógenerally speaking, one boot image for each adapter modelóso choose an appropriate name for each boot image. Names such as ACC$DOS.SYS, SMC$DOS.SYS are better than NET1$DOS.SYS and NET2$DOS.SYS. (The xxx$DOS.SYS naming convention is not essential but it makes the function of these files obvious.) The section later named "BOOTCONF.SYS" explains how to make each workstation pick up the correct boot image.
DOSGEN is a NetWare utility that reads the contents of your master boot floppy and transfers them to the special container file which is a boot image. It reads the floppy's boot sector and File Allocation Table, as well as the files you copied onto the floppy.
The syntax for DOSGEN is
[path]DOSGEN drive: [imagefile]
where path specifies the directory path to DOSGEN, drive is the drive with the master boot floppy, and imagefile specifies the image file to be created.
The default drive is A: and the default image file name is NET$DOS.SYS.
You usually need to map a drive letter to SYS:SYSTEM to pick up DOSGEN and another to SYS:LOGIN so that you can specify the destination for the boot image. Figure 28.2 illustrates a typical sequence of commands issued when using DOSGEN.
Figure 28.2 This is a typical use of DOSGEN.
If you have version 1.2 or later of DOSGEN, the directory structure of your master boot floppy is copied to the boot image along with any files in subdirectories. Earlier versions of DOSGEN complain about subdirectories on the master boot disk by beeping and displaying an error message (...Not supported) beside the name of the subdirectory.
IPX boot PROMs need a little help to work with DOS version 5 or later. This is because DOS 5's COMMAND.COM is much bigger than COMMAND.COM in earlier versions of DOS. Here's the sequence of events without RPLFIX:
The syntax for RPLFIX.COM is
RPLFIX imagefile
where imagefile is the name of the boot image file to be patched, including the path if the file is not in the current directory.
RPLFIX should report that the image file has been successfully modified. For example,
C:\> G:RPLFIX F:SMC$DOS.SYS
NetWare Boot Disk Image Patch Program v1.03 (930630)
(c) Copyright 1991, 1993 by Novell, Inc. All rights reserved.
This program fixes Boot disk image files for:
MS-DOS 5.xx, 6.xx, and DR-DOS 6.xx
Boot disk image file has been modified
RPLFIX needs to be run only once on a given boot image file. If you run RPLFIX on an image that has already been RPLFIXed, RPLFIX tells you so and won't modify the image again.
If you run DOSGEN again to regenerate the boot image file for any reason, you should run RPLFIX on the new image.
RPLFIX.COM is only for DOS version 5.0 or later, and only for IPX boot PROMs. RPL PROM code is not overwritten by COMMAND.COM as it loads, so RPL PROMs do not require this fix.
Finally, make sure the boot image file is properly accessible by the diskless workstations. It must be
Flagged as shareable so that more than one workstation at a time can boot from it. If a workstation hangs while it is booting or is turned off before it has finished booting, the boot image file will still be held open by the workstation's connection, and no other workstations will be able to boot until the connection has been dropped. The NetWare FLAG command can make it shareable:
FLAG F:SMC$DOS.SYS S
For the same reason, you should flag as shareable any of these files which are in SYS:LOGIN: BOOTCONF.SYS, AUTOEXEC.BAT, and any batch files called by the boot image's AUTOEXEC.BAT in a situation with multiple boot images.
