Configuring Remote-Boot Workstations with Linux, DOS 6.20, Win­ dows 3.1 and Windows 95 Marc Vuilleumier Stückelberg and Sandro Viale v1.0, August 1996 This document describes how to set up a very robust server-based con­ figuration for a cluster of PCs, allowing each client to choose at boot-time which operating system to run. The key of this configuration is the TCP/IP bootprom, which let the user choose at boot time one of several bootdisk images. The bulk of it is the configuration of a server-based core for the various operating systems. The must up-to- date version of this document, with hypertext links to downloadable software and other related materials, can be found at the address http://cuiwww.unige.ch/~mvuilleu/configsc1/config.html. Linuxdoc- SGML, DVI and postscript versions are available in the same directory. 1. Introduction The configuration described here was developped during Summer 1996 at the CUI, University of Geneva. The Computer Science Department uses a Novell Netware server, an NFS server 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 or Windows 95. One should be able to choose the desired operating system for each session. · All softwares, including operating systems, should reside on the server, in order to facilitate the initial installation and upgrades. · Clients computers should be able to run without any write-access on the server. · The client-side configuration should be reduced to the very minimum. Clients should automatically get their IP configuration parameters from the Novell server, and this information should be located in a single file, used for all operating systems. · Every computer has to be protected from virus attacks. · Users must have a login on a Novell or UNIX server to be able to use any of the computers. · Students computers should be fully cleaned up at each start. That is, the PC should always look like if it were just installed. These constraints lead us to base our configuration on the excellent TCP/IP Bootprom from Köppen EDV GmbH. This bootprom is especially interesting because it is not devoted to any specific operating system; it just emulates a floppy disk, and can easily be used for booting Linux as well as DOS or Windows 95. 1.1. The Network Our PCs are only concerned about two network protocols: IPX and IP. On the IPX side, we use a single Novell Netware 3 server for sharing software and users files for DOS and Windows. On the IP side, we use a SUN server for sharing software and users partitions for Linux, with NFS. 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. 1.2. How it Works 1. When a client PC is turned on, it first performs the traditional system checks before the TCP/IP bootprom takes the control. 2. The bootprom issues a BOOTP request in order to get its IP configuration parameters. 3. Unless the client is on the same subnet as the Novell server, the request is forwarded by a BOOTP gateway to the server itself. 4. If the Novell server knows the PC issuing the request, it will send back a BOOTP reply with informations such as the client's IP address, the default gateway, and which bootdisk image to use. Otherwise, the server will just discard the request. 5. The bootprom then downloads the bootdisk image from the Novell server using the TFTP protocol, and emulates at the BIOS level a floppy disk with this image. 6. The PC boot on this disk image, which happens to contains a single boot program (no operating system yet). 7. If the PC is a student computer, the program starts by resetting the partition table of the local harddisk and quick-formatting the DOS partition. When this is done, no more than three seconds elapsed since the computer was turned on. 8. The program then offers to the user the choice of the operating system for the session. 9. According to the choice of the user, a new bootdisk image is downloaded from the Novell server, using TFTP. 10. If the user decides to use Linux, the boot image is a slightly modified compressed kernel, with support for NFS root and caching filesystem: a. First, the IP configuration is made according to the BOOTP reply received from the Novell server. b. The kernel is then able to mount a small, read-only root filesystem, using NFS. c. A small ramdisk is set up and connected using symbolic links to the places where write access is desirable. d. The systems mounts by NFS the partitions containing all system- independant softwares. e. If a swap partition is found on the local hard disk, it is activated. f. If a linux partition is found on the local hard disk, it is mounted and prepared for caching NFS partitions. g. IP configuration is finalized, services are started, and xdm is launched. h. The user is asked for its Linux login (maintained by NIS on the SUN server). The workstation is ready. 11. If the user decides to use DOS and Windows 3.1, the boot image is just a traditional DOS boot disk, with memory managers, traditional Novell clients and FTP Inc. TCP/IP stack: a. Since the bootprom has copied itself somewhere into the RAM, the 32 Kb address space it uses can be recovered by EMM386. b. Device drives, keyboard drivers and network drivers are loaded. c. The user is prompted for its Netware login. d. The server login script loads Vshield, the virus detector. e. Since the bootprom floppydisk emulation is not any more needed, the RAM it occupies can be recovered. f. If client local files are not already present on the hard disk, they are copied from the Netware server (approximately 350 Kb for Windows 3.1 and Netscape; it takes one second). g. Local disk cache is activated. h. FTP Software TCP/IP stack is loaded, with a default configuration i. The IP settings are read from the BOOTP configuration file on the Netware server and updated directly into the IP kernel. j. The user is given the DOS prompt, with 543'000 bytes of free conventional memory. He can unload the TCP/IP kernel to get 617'000 bytes of free conventional memory. k. The user can start Windows by typing the traditional win command. 12. If the user decides to use Windows 95, the boot image is a slightly modified version of the bootdisk produced by Windows 95 server- based setup. It uses Microsoft clients for Novell Netware, and Microsoft TCP/IP stack: a. First, the Windows 95 logo is displayed on the screen (don't take that out of it, or it will suddently look very much like DOS...) b. The OS is then loaded, as well as the Netware client. c. The user is asked for its Netware login. d. If client local files are not already present on the hard disk, they are copied from the Netware server (approximately 2.5 Mb for Windows 95 and Netscape; it takes a few seconds). Long filenames are restored. e. A configuration patch is build, with the appropriate IP settings according to previous BOOTP reply. f. The patch is applied to Windows 95 Registery of Secrets using Microsoft's REGEDIT. g. Windows machine directory is set to the local hard disk. h. Windows 95 itself is started. The workstation is ready. Students computers can be turned off the hard way at any time with­ out risks, since the hard disk is reinitialized at each start. For computers with a remanent local hard disk, if the configuration gets corrupted, it is sufficient to erase the whole directory tree containing the concerned operating system in order to get a fresh installation on the next restart. 2. The Configuration How-To The BOOTP server is very easy to configure; just follow the instructions in the manual. We use rfc1048-style BOOTP replies, and long TFTP packets. The client side is also quite simple. Just plug the Bootprom into your network card, and use the appropriate program to enable it. The only trouble we had came from the fact that our network cards, namely SMC EtherEZ, unfortunately supports PnP (a.k.o. Plug-and-Punch). When you try to setup the bootprom address with the appropriate program, the card doesn't keep its settings, even if you disable PnP. Don't worry, use the old SMC Ultra configuration software, and it should work much better. If it doesn't... well, don't fight, PnP is much worse than that. Don't forget that BOOTP requests are bounded by subnets. If the client and the BOOTP server do not reside on the same subnet, you should run bootpgw on a server in the same subnet as the client. Bootpgw is available in the bootp-2.4.2 package ftp://firewall.mc.com/pub/ for many platforms. The real work starts with the server-based configuration of the various operating systems... 2.1. Setting up Linux First, you should choose which one among the many available Linux distributions for your installation. We used Linux-FT because it was the only one offering support for cached filesystems, ie. saving on the local hard-disk the data obtained from a slower filesystem, such as NFS. If you have no local hard disk, or if you are not concerned about network loading, you might choose any other one. Note that since Lasermoon does not yet plan to issue a new release of Linux-FT with the level 2.0 kernel, it should be interesting to adapt Lasermoon's filecache (which is publicly available) for RedHat distribution. Anyway, start by installing your distribution locally, so that you can work with it. 2.1.1. Building the Kernel The next step is to rebuild a kernel for your Linux operating system. Remember that this will be the only software the client computer will be given for starting Linux, so it must contains everything necessary to launch the whole operating system. More precisely, it should contains at least: · support for the client computer hardware · networking support · NFS-Root support · TCP/IP Bootprom complient startup · optionally, filecache support The first two items are part of every standard distribution for a long time. NFS-Root has been integrated as a standard option since release 1.3, but as Linux-FT uses the famous 1.2.13 kernel, we had to patch it for NFS-Root. For more information on NFS-Root (with recent kernels), have a look at the NFS-Root-Mini-Howto. The standard NFS-Root package works well if you are only interested in booting Linux, but if you want to be able to choose between several operating systems, you cannot use the standard BOOTP client. Instead, you should apply our patches to the linux kernel startup code, in order to peek the IP settings for the previously received BOOTP reply. Moreover, since the TCP/IP Bootprom conflicts with the standard Linux boot code, there are slight changes to be done. If you plan to use Linux 1.2.13, the easiest way is to get our patched kernel sources, to configure them for your needs (don't include unneeded support or the kernel will get too big) and make you kernel boot image with make bpImage. You might even try our compiled kernel. If you plan to use a more recent kernel, you should either wait until we release the 2.0 version of TCP/IP Bootprom complient startup (this should be done in the near future), or try to do it by yourself, peeking at the code for 1.2.13. We will here shortly explain what it does. First, in the traditional boot sequence, the boot sector (file bootsect.S) is loaded at 0x7c00 by the BIOS. It usually moves itself to 0x9000, and then loads the rest of the startup code (file setup.S). The trouble is that the TCP/IP Bootprom uses the upper part of the conventional memory for its own purposes, and that this area cannot be used as is by Linux. The solution is to move the boot sector and the startup code to 0x8000 instead of 0x9000, do all the setup stuff, and when the boot image is fully loaded from the ramdisk, discard the TCP/IP Bootprom data area and move the setup code back to 0x9000 so that the kernel can find its command line parameters. The setup code should also be extended to get the IP settings and NFS root parameters in the BOOTP reply, using the TCP/IP Bootprom API. Our modified version of the startup code can be found in bpbootsect.S and bpsetup.S. 2.1.2. Building the Root Filesystem The root tree is the only one that will be mounted automagically by the kernel. It should contain all devices, binaries and libraries necessary for starting the system until all filesystems are mounted, as well as all mount points. We suggest keeping the root filesystem as small as possible, but not wasting too much time in trying to reduce it. You might find usefull hints on the the content of your root filesystem by looking at the NFS-Root-Mini-Howto. We have built our root filesystem with the following goals: · using read-only NFS mount; · beeing able to run Linux without local hard disk; · beeing able to take advantage of a local hard disk for NFS caching. This lead us to the following structure (don't worry, it is explained below): · bin = /cache/bin · dev = /ramdisk/dev · etc (the usual contents of etc, except some files such as...) · mtab = /ramdisk/etc/mtab · fstab = /ramdisk/etc/fstab · ftp · lib = /cache/lib · local = /cache/local · root · sbin = /cache/sbin · tmp = /ramdisk/tmp · usr = /cache/usr · var = /ramdisk/var · direct · bin · lib · sbin · cache (mount point for local hard disk, if any) · bin = /direct/bin · lib = /direct/lib · sbin = /direct/sbin · local = /mnt/local · usr · X11R6 = /dist/usr/X11R6 · · lpd · dist (mount point for runtime CD, via NFS) · mnt (other mount points) · local (mount point for local stuff, via NFS) · ramdisk (mount point for /dev/ramdisk) · floppy (mount point for /dev/fd0) · proc (proc filesystem mount point) As you can see, it looks as a regular root filesystem, except that some entries are redirected to a ramdisk, while some other are redirected to the cache directory. Roughly, the principle of the filecache is that whenever a symbolic link from the cache subdirectory is followed, it is replaced by its target. If the target is itself a subdirectory, each entry of the subdirectory become a symbolic link to the original entry of the foreign filesystem. Now here is how the systems goes up. When the kernel has done with all initializations, it spawn the init program, which will in turn (according to inittab) start two scripts, bcheckrc for checking the system integrity (clock, hostname, root filesystem) and brc for preparing the system for use. In our case, since the root filesystem was mounted through NFS and the hostname was set by the kernel, bcheckrc only sets the clock. Then comes brc. 1. The keyboard layout is set 2. Proc filesystem is mounted, but without updating mtab since it is not yet writable 3. The sync deamon is started (update) 4. A ramdisk is set up in order to get a writable partition. For efficiency reasons, if a file /ramdisk/ramdisk.gz exists, it is supposed to be a compressed image of the ramdisk. Otherwise, it is created: ______________________________________________________________________ # # Setup a ramdisk in order to have a writable area # if [ -r /ramdisk/ramdisk.gz ]; then # # Do a quick ramdisk setup # gzip -c -d /ramdisk/ramdisk.gz | dd of=/dev/ramdisk bs=1024 > /dev/null 2>&1 else # # Enable nfs root (anon=0) write for this procedure to work ! # mke2fs -C -q -i 1024 /dev/ramdisk 720 mount -n -t ext2 /dev/ramdisk /mnt (cd /mnt; mkdir tmp etc dev var; \ cd var; mkdir log adm run spool lock tmp yp yp/binding) mknod /mnt/dev/zero c 1 5 chmod 777 /mnt/tmp /mnt/var/tmp umount /mnt mount -n -t ext2 /dev/ramdisk /ramdisk MAKEDEV-C generic MAKEDEV-C update umount /ramdisk dd if=/dev/ramdisk bs=1024 | gzip -c > /ramdisk/ramdisk.gz echo "Now disable root rw access on NFS server" /bin/sh fi ______________________________________________________________________ 5. The ramdisk is then mounted, still without trying to update mtab 6. Some writable system files are created: ______________________________________________________________________ # # Create necessary system files # cp /etc/mtab.ref /etc/mtab cp /etc/fstab.ref /etc/fstab : 2>/dev/null >/etc/utmp ln -s ../lock /var/run/locks 2>/dev/null ______________________________________________________________________ 7. Local hard disk are scanned for ext2 or swap partitions. If some are found, they are mounted at the right place. Since this code is a little bit longer, I suggest that you have a look directly at brc itself. 8. Swap is activated if available, and the system is up. 2.2. Setting up DOS 6 and Windows 3.1 The server-based configuration of DOS and Windows 3.1 is done in two steps: you should install all softwares on the server, and prepare a client boot disk image. 2.2.1. The Server Installation The server installation of DOS is most probably already done under the DOS directory of your Netware SYS: volume. In order to perform the server installation of Windows 3.1, you should create a subdirectory where you will install the files (we use SOFTWARE:\SOFTWARE\WIN3.1), and run INSTALL /A. This procedure is documented in your Windows manual. Ensure that read access is granted to the users, and map a search drive to this directory in the system login script (we use U:). In order to use this server-based installation of Windows 3.1, you should then run INSTALL /N on each client computer. Since we want a ready-to-run installation on every new computer, we will procede in a slightly different way. Run the server-based installation (INSTALL /N) on a computer that does not yet have Windows installed. Customize everything you want in the windows directory, install specific drivers, and so on. Remember that your WINDOWS\SYSTEM directory is the network directory, and that you will need write access if you have to install something on it. Be warned that many softwares are not aware of server-based installations, and that you might have to hack a bit in order to get some packages to work. When you are satisfied of your Windows configuration, copy the whole contents of your Windows directory to the server (it should be less than one megabyte big). If you need several different configurations, use separate directories. For instance, we use SOFTWARE:BOOT\WINDOWS\ASSIST31, SOFTWARE:BOOT\WINDOWS\HPVECT31 and SOFTWARE:BOOT\WINDOWS\BRAVO31 for our three different hardware configurations. 2.2.2. Making the Bootdisk Make a new bootable floppy, with the same DOS version as you have on your server. Copy your memory managers, device drivers and network drivers on it. This is what we have on our floppy: ______________________________________________________________________ CONFIG SYS (contents listed below) HIMEM SYS ANSI SYS COUNTRY SYS BPUTIL SYS (TCP/IP Bootprom utility) KEYBOARD SYS MTMCDAI SYS (CD-ROM driver) AUTOEXEC BAT (contents listed below) PTASSIST BAT (contents listed below) DOSKEY COM IPX COM KEYB COM PKT8000 COM (SMC EtherEZ packet driver) COMMAND COM BPUTIL COM (TCP/IP Bootprom utility) EMM386 EXE NETX EXE (Netware client) SETVER EXE SHARE EXE 19 fichier(s) 507'247 octets ______________________________________________________________________ Our config.sys is as follow: ______________________________________________________________________ rem Fix memory allocation for use with EMM386 DEVICE=A:\bputil.sys -f rem Note: SMC PROM at CA00-D1FF, RAM at C800-C9FF. rem The PROM space can be recovered since the ramdisk is already loaded. DEVICE=A:\HIMEM.SYS DEVICE=A:\EMM386.EXE NOEMS /Y=v:\EMM386.EXE I=B000-B7FF X=C800-C9FF I=CA00-EFFF BUFFERS=30,0 FILES=60 DOS=UMB LASTDRIVE=E FCBS=16,0 DOS=HIGH switches /f /n BREAK=OFF SHELL=COMMAND.COM /P /E:1024 COUNTRY=041,,COUNTRY.SYS DEVICEHIGH=SETVER.EXE DEVICEHIGH=ANSI.SYS DEVICEHIGH=MTMCDAI.SYS /D:CDROMIDE ______________________________________________________________________ The autoexec.bat sets DOS up: ______________________________________________________________________ @ECHO OFF CLS PROMPT $P$G SET TEMP=c:\ SET TMP=C:\ SET PTASSIST=YES SET FTPVER=3.1 SET DDUR=NON LH KEYB SF,,KEYBOARD.SYS LH DOSKEY /INSERT LH DOSKEY H=DOSKEY /HISTORY LH SHARE ptassist.bat ______________________________________________________________________ The ptassist.bat starts the network: ______________________________________________________________________ @ECHO OFF CLS LH PKT8000 0x65 0x280 0x0b 0xC800 LH IPX LH NETX CLS :loginplease F: LOGIN SC1NOV1/ if "%pctcp%"=="" goto loginplease LH MSCDEX /E /D:CDROMIDE LH H:\software\win3.1\smartdrv a- rem Remove boot RAMDISK cd \login copy a:\ptassist.bat C:\ subst a: C:\ F:\login\remboot.bat ______________________________________________________________________ The PCTCP variable is set by the system login script. If the user gives a bad login name, the variable will not be set and the user will be prompted again. Since drive A: will suddently disappear at the end of the boot, we take some precautions in order to avoid errors. The remboot.bat batch file disable the Boot ramdisk: ______________________________________________________________________ @ECHO OFF rem restore TCP-IP bootprom memory and floppy drive a: F:\login\bputil.com -r rem effectuer les copies des fichiers sur la machine en local F:\login\startwin.bat ______________________________________________________________________ Here is how Windows 3.1 is automatically installed on the client machine if necessary (in startwin.bat): ______________________________________________________________________ @echo off cls echo Please wait, preparing your computer for Windows 3.1 c: cd \ if exist c:\windows\win.com goto WindowsAlreadyHere md netscape > nul md windows > nul if "%PTASSIST%"=="YES" ncopy software:software/netscape/16bit/local.v20/netscape\*.* c:\netscape /s > nul if "%HPVECTRA%"=="YES" ncopy software:software/netscape/16bit/local.v20/netscape\*.* c:\netscape /s > nul if "%ASTBRAVO%"=="YES" ncopy software:software/netscape/16bit/v1.22/copy\*.* c:\netscape /s > nul if "%PTASSIST%"=="YES" ncopy software:boot/windows/assist31\*.* c:\windows > nul if "%HPVECTRA%"=="YES" ncopy software:boot/windows/hpvect31\*.* c:\windows > nul if "%ASTBRAVO%"=="YES" ncopy software:boot/windows/bravo31\*.* c:\windows > nul :WindowsAlreadyHere map s6:=c:\ map s12:=c:\windows ethdrv bootpact subst a: /D cls echo Some usefull commands: echo - to start Windows 3.1 ................................ WIN echo - to unload TCP/IP (and get more free memory) ......... INET UNLOAD ______________________________________________________________________ The ethdrv command loads FTP Software's TCP/IP drivers. We then use bootpact to set the machine IP address according to the contents of the BOOTPTAB file. Note that it is also possible to customize the Windows desktop. We wrote a simple program to add a group to the PROGMAN.INI file, allowing to customize the desktop for each class of users. For instance, if the user has set the SMALLTALK environment variable, startwin.bat will add the Smalltalk program group to its environment. Once your bootdisk is ready, make an image of it using TCP/IP Bootprom's BPSHELL and you are done ! 2.3. Setting up Windows 95 Basically, the configuration for Windows 95 is very similar to the previous one. However, since Windows 95 does not always work as it is supposed to, we will give very detailled instructions. If you change a single jota, be prepared to many surprises. If you get despaired, don't forget that it took us one and an half month to have our configuration working; loosing a week is not that bad... Other usefull sources of informations are: · Windows 95 Ressource Kit help file, on your CD-ROM under \Admin\Reskit\Reskit.HLP · Joe R. Doupnik's experience · Microsoft web site Never forget that at the time this document is written, when dealing about Windows 95, your worst enemy is called Plug-and-Play. Things will probably get better in the future, but they are really bad at this time. A personal hint: disable it when you can, there will always be enough of it that you won't be able to disable. 2.3.1. The Server Installation We here describes how to perform the task equivalent to the old- fashioned INSTALL /A, from Windows 3.1. On a machine runing Windows 95, start admin\nettools\netsetup\netsetup.exe 1. Click on Set path, type the location where you want to install Windows 95 stuff, using the \\server\volume\directory notation. We use \\sc1nov1\software\software\win95. 2. Click on Install, choose the Server radio button, and click OK. 3. Click on the button Don't create script since we will have to do it manually anyway. 4. When you are asked for your Product ID, don't answer your serial number, but use 950R6 instead. We found this trick in Doupnik's document; believe us, it prevents a lot of trouble during server- based setup ! 5. Netsetup will then install Windows 95 on your network drive. 6. Click the Exit button. Now open a MS-DOS window and go to the network directory where Windows 95 was installed. Use attrib to unprotect msbatch.inf and edit it (by the way, msbatch.inf is the setup script we asked Netsetup not to create) ______________________________________________________________________ H: cd \SOFTWARE\WIN95 attrib msbatch.inf -R edit msbatch.inf ______________________________________________________________________ You should make it correspond exactly to the following example. The NameAndOrg section is the only one that you should change. ______________________________________________________________________ [Setup] Express=0 InstallType=3 Verify=0 CCP=0 ProductID=950R6 ProductType=1 Uninstall=0 [Network] WorkstationSetup=1 DisplayWorkstationSetup=1 HDBoot=0 RPLSetup=0 SaveSUBoot=1 display=1 [NameAndOrg] Name="CUI" Org="University of Geneva" ______________________________________________________________________ Your server installation is now ready. You will now have to setup clients. 2.3.2. The Machine Setup We here describes how to perform the task equivalent to the old- fashioned INSTALL /N, from Windows 3.1. On one of the future client machines, boot MS-DOS with your usual DOS network clients. Boot neither from hard disk, nor from bootprom, but boot from a true floppydisk. Login to the server with at least read access to the Windows 95 directory. Go to this directory, and run setup, without any parameter. ______________________________________________________________________ H: cd \SOFTWARE\WIN95 setup ______________________________________________________________________ Wait a moment, agree to Microsoft License, and click Next to begin the setup process. 1. Choose Set up Windows to run from a Network Server, then Next 2. Choose Start Windows from a floppy disk, then Next 3. As machine directory, use C:\WIN95, then click Next 4. Setup will then copy some temporary files on your hard disk 5. Choose a Custom installation, then click Next 6. Enter your name and the name of your organization, if it was not already set properly. Click Next 7. Windows will then ask you the permission for scanning your devices. Our experience is that it always hang the computer if you let him scan the network cards (this is probably a problem with SMC cards). So, better answer No, I want to modify... and click Next. Unselect the Network section and reselect the exact name of your network adapter. Click Next 8. We don't want to get connected by Microsoft. No comment, Next 9. Choose the components you would like, then Next 10. Then comes the Network Configuration. The content of the listbox will depend of the current configuration detected by setup. We use Microsoft Client for Netware. If Monolithic NETX is listed instead, Remove it, click back then next, and Microsoft client should automagically appear. If it does not work, play with it a few minutes, until you get in the list box: · Your network adapter · IPX · Microsoft Client for Netware 11. Double-click on Client for Netware Networks and set the preferred server connection to what you want (we use SC1NOV1). 12. Double-click on IPX/SPX compatible protocol and choose the appropriate frame type (under Advanced). We use Ethernet II. 13. If you use an SMC EtherEZ, click on SMC EtherEZ and change the configtype (under Ressources) to detected. 14. Click on Add..., Protocol, Microsoft, TCP/IP. Don't take time to configure it, setup would loose your settings anyway. 15. Click Next 16. Give an identification to your computer (it does not really matter), click Next 17. Setup the type of your monitor, then click Next. If you don't find your monitor in the list, either use Standard SVGA 1024x768 if you don't want more, or try another one if you want to use a more exotic resolution. We use the Sony 17" driver, although our monitor is a Prostar 17". Setup will then install the local part of Windows 95 to your hard disk. After a moment, you will be prompted for a new floppy, which will be your Windows 95 Boot Disk. Click Finish when prompted, wait a moment, and turn your computer off. 2.3.3. Making Things Work Now edit from MS-DOS (may be on another computer) the autoexec.bat from your Windows 95 Boot Disk. As setup is not very smart, it has made a fatal error. Replace the line with setmdir with the following three lines: ______________________________________________________________________ setmdir /R:C:\WIN95 set temp=C:\TEMP set tmp=C:\TEMP ______________________________________________________________________ The first line is the essential change: it tells Windows where the Registery of Secrets can be found. Without the /R:, your client would have just hanged. The two other lines are here to avoid that installa­ tion stuff clubber your machine directory. Boot your client machine with the Windows 95 Boot Disk. Login to the Netware server, and wait while setup automatically starts. Windows 95 may complain about not receiving answers to DHCP requests; don't care about it. Login once again to the Netware server. When you are asked to enter a Windows password, clear the upper field and click OK, so that Windows will not bore you again. Setup will then do some work, and you will be prompted for you timezone. Then configure any network printer you have, and the machine will reboot once again. Boot the client machine with the Windows 95 Boot Disk. Login to the Netware server, wait until Windows 95 is up and close the welcome window. You should now setup your video adapter properly, to get the best possible resolution. We have an S3 adapter, with a good monitor, but Windows itself is not even capable getting 1024x768... Get the drivers using ftp directly from your adapter manufacturer. Since almost no setup software is aware of network-based configurations, you will probably have to copy manually system files to the Server Windows 95 System directory (in our case, H:\software\win95\system), using a MS-DOS window. Then get the control panels from the Start menu, and choose Display, Settings, Change. Under Adapter type, choose Change, Have disk, OK. Finish the installation of the adapter properly, close the window and be prepared to restart your computer once again. Boot the client machine with the Windows 95 Boot Disk. Login to the Netware server and wait until Windows 95 is up. We will now configure Microsoft TCP/IP. Note that we tried to use Onnet TCP/IP stack but we were not able to get it work with a network based installation of Windows 95. Get the control panels from the Start menu, and choose TCP/IP. Choose Specify an IP address, enter your IP address and subnet mask. Under Gateway, set your default gateway. Under DNS, enable DNS, enter a name for your host, your domain name, some DNS servers and domain search list. Click OK when you are done, and close the network control panel. TCP/IP should be set, except that the DNS will not work. We will now have to fix yet another bug of Windows 95 Server-based setup. From the Start menu, choose Run... and type REGEDIT. This will allow you to edit the Windows 95 Registery. Open the branch HKEY_LOCAL_MACHINE, System, CurrentControlSet, Services, VxD, MSTCP. In all subfields of this branch, replace the string %WINDIR% by your Server Windows 95 System directory. In our case, we changed HelperDIIName and ProviderPath to H:\software\win95\system\wsock32.dll. Close regedit. Your DNS resolver will now have a chance to work next time you boot Windows 95. Customize your desktop as you want. You can install additional software, but don't pull on the evil's tail ! For instance, don't try to install Microsoft Office at first; you will find more informations on it below. 2.3.4. Saving the Configuration to the Server When you are happy with your setup, reboot your computer with your Windows 95 Boot Disk but press the F8 key at startup. A boot menu will appear; choose Command prompt only. When prompted, login to the server with write access, and wait until you get a nice DOS prompt. Now we would like to save all usefull material to a directory on the server, in order to be able to restore it later. There are two problems: 1. There are not only hidden files, but also hidden directories that attrib is not able to unprotect 2. There are long filenames, and we don't want to have them on our Novell server. As nothing needs to be hidden, the easiest way to get rid of the first problem is to run a small program that will recursively unhide all files starting from current directory. Once all files are visible, do some cleanup. Go to the C:\WIN95 directory and get rid of: · the SUBOOT directory, which contains the same material as your boot floppy · the SYSBACKUP directory, which contains previous version of your configuration · the .SWP file, which will be generated automatically · all .BAK, .TXT and .DA0 files, which are not needed · the .PWL file, which contains your Netware password (slightly encrypted) Now create a new directory somewhere on the server to store your configuration. We use H:\SOFTWARE\WIN95\PTASSIST. Create a WIN95 subdirectory inside, and copy the full content of your C:\WIN95 to this subdirectory, using xcopy for instance. The best way we found for saving long filenames was to use the DOSLFNBK program, which does essentially the same as Microsoft LFNBK except that it works under DOS. That is, you can restore your long filenames even if you don't have Windows 95 running. We run it form within our H:\SOFTWARE\WIN95\DOSLFNBK subdirectory, where all longfilenames will be saved: doslfnbk c:\ /f original /v /d original This will save all long filenames to file ORIGINAL.LFN and write a log to the file ORIGINAL.LOG, just in case. If you are going to use sev­ eral different configurations, rename these files to a more descrip­ tive name. 2.3.5. Finalizing the Boot Disk You are now ready to prepare you final boot disk image. Change your autoexec.bat so that it looks like this: ______________________________________________________________________ @echo off mode con codepage prepare=((850) ega.cpi) mode con codepage select=850 keyb sf,,keyboard.sys snapshot /S /M:100 net start NWRedir net use * /d cls net use F: \\SC1NOV1\SYS net use H: \\SC1NOV1\SOFTWARE PATH=H:\SOFTWARE\WIN95\;H:\SOFTWARE\WIN95\COMMAND set comspec=h:\software\win95\command.com set PTASSIST=YES f:\login\start95 ______________________________________________________________________ We added an additional parameter to snapshot so that it reserves less memory for nwteork drivers, because DOSLFNBK needs a lot of memory to restore big trees. We also added an environment variable PTASSIST that tell the continuation script start95.bat which configuration to use. This script is listed here: ______________________________________________________________________ @echo off cls echo Please wait, preparing your computer for Windows 95 c: if exist c:\win95\win.com goto norestore cd h:\software\win95 if "%PTASSIST%"=="" goto noptassist xcopy h:ptassist\*.* c:\ /s /e > nul rem --- Next line should be run on a writable dir. C: will do fine echo y | lock c: > nul rem --- Have enough memory for this (350 Kb !). May use SNAPSHOT /S /M:100 h:doslfnbk\doslfnbk c:\ /r /f h:doslfnbk\ptassist > nul unlock c: h:reg\bootpreg h:reg\ptassist.reg c:\win95\patch.reg :noptassist cd \win95 regedit /L:system.dat /R:user.dat patch.reg rem --- Don't forget this, or Win95 will shut down the computer ! cd h:\ :norestore cd \ rem --- Disable BootProm f:\login\bputil -r setmdir /R:C:\WIN95 set temp=c:\temp set tmp=c:\temp ______________________________________________________________________ This script does basically the same as startwin.bat does for Windows 3.1. Files are restored from the server, and then long filenames. The next step is the customization of the IP settings. Since all IP param­ eters are stored in the Registery, the easiest way to customize them is to make a small text file with the appropriate values and to import it into the registery using Microsoft REGEDIT in MS-DOS mode. Theo­ retically, this text file could simply be created using the BPUTIL utility from the TCP/IP Bootprom distribution. Unfortunately, PnP is among us, and thus it is not sufficient to set the IP parameters. When Windows 95 starts up, it first discards all informations in the Registery that do not precisely match current hardware. In particular, it discards all information about your network card if the description the Registery does not correspond to the same ethernet (MAC) address. It then scans all possible types of network cards to find another one, and this will most probably hang your computer. Very smart. That means, we also have to patch the description of the network card. We wrote a small program, BOOTPREG, for doing all changes at once. Note that you will need to ask Dirk Köppen EDV for their development kit in order to compile this program. This program will then translate all tags in the form BOOTPREG:tagname: to the corresponding information, either from the BOOTP reply or from the hardware description. Here is our registery patch file: ______________________________________________________________________ REGEDIT4 [HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Class\NetTrans\0001] "DriverDesc"="TCP/IP" "IPAddress"="BOOTPREG:IP:" "IPMask"="BOOTPREG:NETMASK:" "InfPath"="NETTRANS.INF" "DevLoader"="*ndis" "DeviceVxDs"="vtdi.386,vip.386,vtcp.386,vdhcp.386,vnbt.386" "DefaultGateway"="BOOTPREG:T129:" [HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\VNETSUP] "ComputerName"="BOOTPREG:MACHINE:" "Workgroup"="University" "Comment"="CUI" [HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\MSTCP] "LMHostFile"="C:\\WIN95\\lmhosts" "NodeType"="1" "EnableDNS"="1" "HostName"="BOOTPREG:MACHINE:" "Domain"="unige.ch" "SearchList"="unige.ch" "NameServer"="129.194.4.6,129.194.4.32,129.194.8.7" "Lanabase"="0" [HKEY_LOCAL_MACHINE\System\CurrentControlSet\control\ComputerName\ComputerName] "ComputerName"="BOOTPREG:MACHINE:" [HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Arbitrators\AddrArb] "0000"="00000000-000D1FFF,000E0000-000FFFFF,80000000-81FFFFFF" [HKEY_LOCAL_MACHINE\Enum\ISAPNP\SMC8416\BOOTPREG:MACID:C0] "HardwareID"="*SMC8416,ISAPNP\\SMC8416" "HWRevision"="1.0.10" "DeviceDesc"="SMC EtherEZ (8416)" "Class"="Net" "Driver"="Net\\0000" "CompatibleIDs"="*SMC8416" "Mfg"="SMC" "ConfigFlags"=hex:10,00,00,00 [HKEY_LOCAL_MACHINE\Enum\ISAPNP\SMC8416\BOOTPREG:MACID:C0\LogConfig] "0000"=hex:00,04,00,00,00,20,00,00,10,00,00,00,04,00,00,00,00,00,00,00,a8,0e,\ 00,00,20,00,00,00,02,00,00,00,01,00,0c,00,00,00,00,00,00,00,00,00,e0,ff,20,\ 00,40,02,ff,03,00,00,04,03,2c,00,00,00,01,00,00,00,01,00,14,00,00,00,00,00,\ 00,00,00,00,00,00,00,00,00,e0,ff,ff,00,20,00,00,00,00,0c,00,ff,ff,0f,00,00,\ 00,00,00,2c,00,00,00,01,80,00,00,01,00,14,00,00,00,00,00,00,00,00,00,00,00,\ 00,00,00,e0,ff,ff,00,80,00,00,00,00,0c,00,ff,5f,10,00,00,00,00,00,00,00,00,\ 00 [HKEY_LOCAL_MACHINE\Enum\ISAPNP\SMC8416\BOOTPREG:MACID:C0\Bindings] "NWLINK\\0000"="" "MSTCP\\0000"="" [HKEY_LOCAL_MACHINE\Enum\ISAPNP\SMC8416\BOOTPREG:MACID:C1] "HardwareID"="*SMC8416,ISAPNP\\SMC8416" "HWRevision"="1.0.10" "DeviceDesc"="SMC EtherEZ (8416)" "Class"="Net" "Driver"="Net\\0000" "CompatibleIDs"="*SMC8416" "Mfg"="SMC" "ConfigFlags"=hex:10,00,00,00 [HKEY_LOCAL_MACHINE\Enum\ISAPNP\SMC8416\BOOTPREG:MACID:C1\LogConfig] "0000"=hex:00,04,00,00,00,20,00,00,10,00,00,00,04,00,00,00,00,00,00,00,a8,0e,\ 00,00,20,00,00,00,02,00,00,00,01,00,0c,00,00,00,00,00,00,00,00,00,e0,ff,20,\ 00,40,02,ff,03,00,00,04,03,2c,00,00,00,01,00,00,00,01,00,14,00,00,00,00,00,\ 00,00,00,00,00,00,00,00,00,e0,ff,ff,00,20,00,00,00,00,0c,00,ff,ff,0f,00,00,\ 00,00,00,2c,00,00,00,01,80,00,00,01,00,14,00,00,00,00,00,00,00,00,00,00,00,\ 00,00,00,e0,ff,ff,00,80,00,00,00,00,0c,00,ff,5f,10,00,00,00,00,00,00,00,00,\ 00 [HKEY_LOCAL_MACHINE\Enum\ISAPNP\SMC8416\BOOTPREG:MACID:C1\Bindings] "NWLINK\\0000"="" "MSTCP\\0000"="" [HKEY_LOCAL_MACHINE\TempKey\System\CurrentControlSet\Services\VxD\VNETSUP] "ComputerName"="BOOTPREG:MACHINE:" "Workgroup"="University" "Comment"="CUI" [HKEY_LOCAL_MACHINE\TempKey\System\CurrentControlSet\Control\ComputerName\ComputerName] "ComputerName"="BOOTPREG:MACHINE:" ______________________________________________________________________ As you can see, the network card is described twice. This is because depending on the way it has be configured, it will answer slightly differently to the PnP scan, once with C0 and once with C1. You probably won't be able to use this file directly, but you will have to custom it to your own network card. Remember that if the most insignificant thing changes in the hardware configuration, Windows 95 will detect it and discard your device. For instance, you may need to do your configuration with the Bootprom enabled (and abort the BOOTP process with space bar) because the LogConfig field changes when you enable the Bootprom. Things are much worse if your computer support PnP: all adapters (SVGA, network, Soundblaster, Mouse...) have to be plugged in the same slot for all clients, or you will get a PnP scan and all settings for the corresponding devices will be lost. By the way, PnP mouse detection does not work with our Logitech mouse... This wast the last (but not least) step. Now, your Windows 95 Boot Disk is ready. Make an image of it using BPSHELL, and pray ! 2.3.6. Installing Additional Software If you plan to add additional software, start a fresh machine using your previous configuration, add the software, and save your configuration as for the first time (XCOPY, then DOSLFNBK). If you plan to install MS-Office for Windows 95, you will probably want to use the server-based installation. It works not so bad, but you will have to care about two problems. 1. Before running the client installation, you have to fix a small bug. Open a MS-DOS window, and unprotect the vredir.vxd file using attrib, or the setup will fail: attrib H:\software\win95\system\vredir.vxd -R 2. After the installation is done, clients will be able to boot from floppy disk, but not anymore from Bootprom, because MS-Office setup has put a lot of mess into the registery. The only solution we have found is to copy the hidden registery files (SYSTEM.DAT and USER.DAT on your local hard disk) to another computer running Windows 95 locally, to start this computer in command-line only mode (using F8 on boot), and to use REGEDIT to get a text export of the Registery. Do that before and after installing MS-Office, and build a file containing all differences between the two. Theoretically, you should then be able to import this difference file into the registory without MS-Office to get a registery that works with MS-Office. Unfortunately, this import will probably fail because the registery is getting too big for REGEDIT. Split the difference file into two parts, and import each part separately. If one of the part fails, split it again into two parts, and repeat the operation until everything is imported (the last part we imported contained just a single line !). When you are done, you will have a registery that contains every necessary informations for MS-Office but that will be much, much smaller than the one created by the setup. And it will then work with the bootprom. If you plan to install Netscape, you will notice that no network installation is available (may be next release will have it). You can still do it manually, by installing it locally, copying all binaries to a network directory and changing all paths in the Registery (using REGEDIT in Windows 95 mode) to point to the network drive. 3. Discussion We here discuss some issues related to our configuration. 3.1. Bootproms vs Harddisks Bootproms exist for quite a long time, but they are usually used for diskless computers only. In our opinion, bootproms are even more interesting for computers which have a local harddisk, since they allow to take profit of both sides: · A bootprom 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. 3.2. Which Bootprom ? Several bootproms are available for PCs. We had several reason for choosing the TCP/IP Bootprom from Köppen EDV GmbH: · It is based on the BOOTP protocol, which is publicly defined by RFCs. The definition states that when a BOOTP server receives a request from a client that he doesn't know, the server will not answer. This avoids interferences between multiple servers, as you might sadly experience with the MSD boot server. Moreover, since IP broadcasts are confined to the local subnet, they produce less noise than their IPX counterpart. · It is not bound to a specific operating system. · Technical informations and API informations are available on request. · The boot process can be parametrized on many ways. Specifically, it allowed us to forestall floppy boot on old-fashioned AST computers, which BIOS did not include this feature. · It allows for optimal configurations (for DOS memory management, for instance) · Tools are provided for building and maintaining boot menus.