  Configuring Remote-Boot Workstations       with Linux, DOS 6.20, Win
  dows 3.1 and Windows 95
  Marc Vuilleumier Stckelberg 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 Kppen 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
  Kppen 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 Kppen 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.

