home *** CD-ROM | disk | FTP | other *** search
/ BURKS 2 / BURKS_AUG97.ISO / BURKS / LINUX / HOWTO / mini / remboot.txt < prev    next >
Text File  |  1997-07-07  |  63KB  |  1,420 lines
  1.   Linux Remote-Boot mini-HOWTO:      Configuring Remote-Boot Worksta¡
  2.   tions    with Red-Hat Linux, DOS, Windows 3.1 and Windows 95
  3.   Marc Vuilleumier Stⁿckelberg, Sandro Viale and David Clerc
  4.   v2.3, April 1997
  5.  
  6.   This document describes how to set up a very robust server-based con¡
  7.   figuration for a cluster of PCs, allowing each client to choose at
  8.   boot-time which operating system to run. The key of this configuration
  9.   is the TCP/IP bootprom, which let the user choose at boot time one of
  10.   several boot images. The most up-to-date version of this document,
  11.   with hypertext links to downloadable software and other related mate¡
  12.   rials, can be found at the address
  13.   http://cuiwww.unige.ch/~mvuilleu/configsc1/config.html.  Linuxdoc-
  14.   SGML, DVI and postscript versions are available in the same directory.
  15.   You can also find some slides written in French at
  16.   http://cuiwww.unige.ch/~nicolas/PCintegre.html.
  17.  
  18.   1.  What has changed since last major version ?
  19.  
  20.   ╖  The Linux server-based configuration and documentation have been
  21.      completely redesigned. It is now based on RedHat Linux 4.1, updated
  22.      to the 2.0.30 kernel. Linux system setup and maintenance has been
  23.      much simplified.
  24.  
  25.   ╖  The Dos and Windows configurations have been completely redesigned,
  26.      using a "hard-disk based" approach. This makes the configuration
  27.      MUCH easier, fasten the boot process, reduces the network load, and
  28.      even allows for a server-based setup of Windows NT station
  29.      (although this is not described in this document).
  30.  
  31.   ╖  We now use a DHCP server, with standard DHCP/BOOTP extensions (RFC
  32.      2132).
  33.  
  34.   ╖  This configuration now works also with Samba, the free SMB server,
  35.      instead of a Novell server. In fact, we are now on the point of
  36.      throwing away of our Novell server...
  37.  
  38.   2.  Introduction
  39.  
  40.   The configuration described here was developped since Summer 1996 at
  41.   the CUI, University of Geneva. The Computer Science Department uses
  42.   several servers (both Unix and Novell), and a number of PCs, which
  43.   fall into two classes:
  44.  
  45.   ╖  computers devoted to students
  46.  
  47.   ╖  computers devoted to research and teaching assistants
  48.  
  49.      We developped the current configuration with the following aims:
  50.  
  51.   ╖  Every computer should be able to run under Linux, DOS, Windows 3.1
  52.      or Windows 95. One should be able to choose the desired operating
  53.      system for each session.
  54.  
  55.   ╖  All softwares, including operating systems, should reside on the
  56.      server, in order to facilitate the installations and upgrades.
  57.  
  58.   ╖  Clients computers should be able to run without any write-access on
  59.      the server (for security reasons), except their home directory.
  60.  
  61.   ╖  Client-side configuration should be reduced to its very minimum.
  62.      Clients should automatically get their IP configuration parameters
  63.      from the server, and this information should be located in a single
  64.      file, used for all operating systems.
  65.  
  66.   ╖  Since almost every computer now has a hard-disk, clients should be
  67.      able to take profit of it for reducing network load and as
  68.      temporary storage space for the user.
  69.  
  70.   ╖  Users must have a login to be able to use any of the computers.
  71.  
  72.   ╖  The login should be the same for all operating system and should
  73.      let the user access its unique home directory, common to all
  74.      operating systems.
  75.  
  76.   ╖  Students computers should be fully cleaned up at each start. That
  77.      is, the PC should always look like if it were just installed.
  78.  
  79.   ╖  Every computer has to be protected from virus attacks.
  80.  
  81.      These constraints lead us to base our configuration on the
  82.      excellent TCP/IP Bootprom from K÷ppen EDV GmbH.  This bootprom is
  83.      especially interesting because it is not devoted to any specific
  84.      operating system; it just emulates a floppy disk, and can easily be
  85.      used for booting Linux as well as DOS or Windows 95.  Moreover, the
  86.      bootdisk image can be replaced by a home-made program, that let us
  87.      perform several initializations before the operating system itself
  88.      starts.
  89.  
  90.   2.1.  The Network
  91.  
  92.   The University of Geneva owns a class B domain, subdivided into
  93.   several subnets. The CUI uses four subnets, among them one is
  94.   dedicated to students.
  95.  
  96.   Originally, our PCs were concerned about two network protocols: IPX
  97.   and IP.  On the IPX side, we used a single Novell Netware 3 server for
  98.   sharing software and users files for DOS and Windows. On the IP side,
  99.   we used a SUN server for sharing software and users partitions for
  100.   Linux, with NFS.
  101.  
  102.   In our latest configuration, we do not any more use IPX. There is a
  103.   single Unix server (which could be Linux as well as a SUN), sharing
  104.   software and user files using NFS for Linux clients and using SMB
  105.   (NetBIOS) over TCP/IP for Dos and Windows clients.
  106.  
  107.   2.2.  How it Works
  108.  
  109.   1. When a client PC is turned on, it first performs the traditional
  110.      system checks before the TCP/IP bootprom takes the control.
  111.  
  112.   2. The bootprom issues a BOOTP/DHCP request in order to get its IP
  113.      configuration parameters.
  114.  
  115.   3. If the server knows the PC issuing the request, it will send back a
  116.      BOOTP/DHCP reply with informations such as the client's IP address,
  117.      the default gateway, and which bootdisk image to use.  Otherwise,
  118.      the server will just discard the request.
  119.  
  120.   4. The bootprom then downloads the bootdisk image from the server
  121.      using the TFTP protocol, and emulates at the BIOS level a floppy
  122.      disk with this image.
  123.  
  124.   5. The PC boot on this disk image, which happens to contains a single
  125.      boot program (no operating system yet).
  126.  
  127.   6. If the PC is a student computer, the program starts by downloading
  128.      by TFTP a small text file containing the expected hard-disk
  129.      configuration for the computer. According to this file, the
  130.      partition table is rebuilt and DOS partitions are quick-formatted.
  131.      When all this is done, no more than three seconds have elapsed
  132.      since the computer was turned on.
  133.  
  134.   7. The program then offers to the user the choice of the operating
  135.      system for the session.
  136.  
  137.   8. According to the choice of the user, a new bootdisk image is
  138.      downloaded from the server, using TFTP.
  139.  
  140.   9. If the user decides to use Linux, the boot image is a a kernel
  141.      loader plus a compressed kernel, with support for NFS root and
  142.      caching filesystem:
  143.  
  144.      a. First, the IP configuration is made according to the BOOTP/DHCP
  145.         reply received from the Novell server.
  146.  
  147.      b. The kernel is then able to mount a read-only root filesystem,
  148.         using NFS.
  149.  
  150.      c. A small ramdisk is set up and mounted to the places where write
  151.         access is desirable.
  152.  
  153.      d. If a swap partition is found on the local hard disk, it is
  154.         prepared and activated.
  155.  
  156.      e. If a linux partition is found on the local hard disk, it is
  157.         mounted and prepared for caching NFS partitions.
  158.  
  159.      f. IP configuration is finalized, services are started, and xdm is
  160.         launched.
  161.  
  162.      g. The user is asked for its login. The workstation is ready.
  163.  
  164.   10.
  165.      If the user decides to use DOS or Windows, the boot image is a
  166.      program that handle compressed images of FAT16 partitions.  Images
  167.      are downloaded using TFTP, and stored for further use at the very
  168.      end of the hard-disk, above any used partition.  More precisely,
  169.      the program works in the following way:
  170.  
  171.      a. The program download a checksum file (512 bytes) that validates
  172.         the boot image of the choosen operating system
  173.  
  174.      b. If the wanted image is not present at the end of the disk, or if
  175.         the checksum does not match (because the image has been
  176.         corrupted or because a new release has been installed on the
  177.         server), the full image is transferred using TFTP.
  178.  
  179.      c. The operating system image is decompressed into the first FAT16
  180.         partition, at the approximate speed of one second per used
  181.         megabyte.
  182.  
  183.      d. The program jump into the boot sector of the selected OS, which
  184.         is now completely present on the local hard-disk.
  185.  
  186.      For DOS and Windows 3.1, we use the freely available Microsoft Lan¡
  187.      Manager for DOS (s