View Source: DisklessWorkstationNotes - Waikato Linux Users Group

Edit PageHistory Diff Info LikePages
See also LinuxInstallationNotes

!! General Setup

; [DHCP] : You need a [DHCP] server on your network that can issue IP leases to your workstations, and in some cases send optional information. One option is version 3 of the ISC [DHCP] daemon, called dhcp3-server under Debian Woody; the standard RedHat packages are already DHCP v3 for recent RedHat releases (8.0)
; [TFTP] : You need a [TFTP] server on your network to allow clients to download configuration, kernels, ramdisks, and so on. To get PXE working correctly, you really need the HPA version of tftpd (tftpd-hpa under Debian Woody, not sure in RedHat).
; [NFS] : If you are setting up an NFS-mounted root fs, such as with LTSP, you need an NFS server as well.

''I initially used LTSP, but ran into issues - it would boot, mount its NFS root, but couldn't set up a working /tmp directory and so nothing would start. I never bothered fixing it as I came across PXES which does what I want, and uses a ramdisk instead.'' --DanielLawson

!! PXE booting

Once you have a PXE enabled card (either via PXE on disk, or through a boot rom) and have tftp-hpa and dhcp3 installed on your server, read on.

Grab the [SysLinux|http://freshmeat.net/projects/syslinux/] package, and put the pxelinux binary (normally called something linux pxelinux.0 under your tftproot somewhere. PXELinux is just like syslinux in terms of its config files, however it places them under a directory called pxelinux.cfg *relative to the position of pxelinux.0*

For example, when I set up PXES I placed all PXES related stuff into /tftpboot/pxes/ (which has the tftp path of just /pxes/)

You also need to let dhcp know which filename to pass on for pxe booting clients. Its sufficient to put 'filename "....";' in a static lease section of your dhcp.conf: eg

   host sulpher {
    hardware ethernet 00:60:97:59:e1:d6;
    fixed-address sulpher.element.meta.net.nz;
    filename "pxes/pxelinux.0";
    vendor-encapsulated-options 01:04:00:00:00:00:ff;
  }

This associates the specified MAC address with the fixed IP address of sulpher.element.meta.net.nz, and tells it to boot "pxes/pxelinux.0".

The vendor-encapsulated-options is a string that some (but not all) PXE clients require before they boot. the given string is the minimum legal offering. More information can be found in RFC:1048 and/or RFC:1497.

In /tftpboot/pxes/pxelinux.cfg/ I have a default configuration file called 'default'. It contains
 default pxes
 prompt 1
 timeout 600
 display pxes.msg
 F1 pxes.msg

 label pxes
   kernel vmlinuz-2.4.20-4pxes.i586
   append ramdisk_size=20480 console=null initrd=pxes-0.5.1.initrd root=/dev/ram

This means it will boot the kernel vmlinuz-2.4.20-4pxes.i586 with an initial ramdisk_size of 20 MB (needed for the pxes initrd), specifies that the rootfs is mounted as /dev/ram (an initrd), and also gives it the filename of an initrd to load (pxes-0.5.1.initrd, which is also placed in /tftpboot/pxes)


From what I've seen of PXE and Etherboot booting, PXE works much better. That is to say, I've yet to get a working etherboot system running, but PXE goes just fine. PXE can start a bootloader - such as PXELinux or GRUB. Therefore it would be possible to specify a bootloader which defaults to booting off /dev/hda, but if you tell it otherwise at boottime it boots off the network

!! Other notes from OliverJones

Something I can speak with experience on here is that sometimes diskless workstations can be more trouble than they are worth.  Problems I had were:

* NFS file handles timing out causing workstations to crash (couldn't figure this one out).
* Workstations running out of RAM and crashing (swap is our friend).  Even when the only process running on the workstation is XFree86.  The memory would fill up with XFree caching pixmaps.  Putting 128MB (up from 64MB) in the workstations reduced this problem but it was still an issue.  One could attempt to create swap the over network using network block devices.

For the price of a 20GB HDD (~100$) these problems disappear.  The only issue you have to worry about now is power failure corrupting the drive.  With read only and journalling file systems this is less of a problem than it might seem.

These days you can put a >1GHz, 256MB, 20GB workstation together for ~700NZD (minus screen).  At these prices thin clients make less and less sense.  All the administrative benefits of diskless systems can be achived with NFS /home (et al), automount, LDAP, and automatic/scripted package management systems like the RedHat Network, Ximian RedCarpet Enterprise, or some homegrown system.

This is just my opinion though based on my past experience.

!! Counter notes from the WAND group

We have a grunty (dual Athlon 1800 MP) server we use for running our desktops on. Until recently, we've used HP Vectra (P2-233) as the clients, with whatever disks were in there, and had a image dd'd onto them. This was fine, in general, except the machines were slowly dying, and maintenance became an issue. Our LazySystemAdministrator wasn't lazy enough to write a decent set of automated update / modification scripts for the 12 machines we used.
However, we still saved a lot of money - the price of our server was far less than we would have spent putting decent machines at everyones desktop.

Recently, we upgraded to some nice Compaq Deskpro's (P3-550/ 128 MB ram, 10 GB disk, EEPro 100, Matrox G200's etc). We pulled the harddisks out, and setup NFSRoot linux using the 'diskless' package described elsewhere in the wiki. Maintenance is dead easy - the LazySystemAdministrator chroots to the NFSRoot path, and installs the package. If its the sort of package that requires something in /etc to be updated, then he runs a script that updates all the images at once.

Benefits? Our labs are __silent__. Really __silent__. No disk noises. The machines are in good condition, so the PSU, case and CPU fans are also dead quiet. Its great. We've also eliminated dodgy disks as a potential problem with our thin clients. Also, we got hold of 15 machines for very little - cheaper than the price spec'd above, and we know they are good quality components. The money we save on desktops we can spend on dropping a dual Opteron server in instead, or on better displays (like 17" TFTs, which we are considering) and keyboards/mice. They are easy to maintain, they do local auth via pam_ldap off our main server, so we all have local accounts as well, if we wanted to use them, and the administrative overhead has dropped immensely.


----

AddToMe : PXES, LTSP, notes on [DHCP] [TFTP] [NFS]
5 pages link to DisklessWorkstationNotes:
Last edited on Sunday, November 20, 2005 9:58:44 pm by DanielLawson
Edit PageHistory Diff Info LikePages