View source for Remote-booting diskless Unix clients from eComStation and OS/2 Warp Server

''Original Work by [[Micho Durdevich]]''

==Introduction==
In this note we shall outline the setup for diskless Linux and FreeBSD machines, that remote boot from OS/2 Warp server or eComStation, via DHCP/PXE and NFS. We shall first focus our attention on Linux DHCP/PXE clients, the procedure for FreeBSD systems is conceptually similar (and will be presented in an extended version of this article).

The setup for remote booting Linux from OS/2 is similar to remote booting Linux from UNIX, and the latter is very well documented in various articles. See for example [1] for remote booting of (mainly HDD-equipped) Linux, DOS and Windows machines from Linux, [3] for interesting Linux-only stuff, or [5] for FreeBSD considerations. Therefore, here we shall mainly pay attention on the OS/2-specific things, and some more advanced topics.

==eComStation Boot Server Setup==
At the OS/2 server side, the following daemons should be configured and running:
*Dynamic Host Configuration Protocol - '''DHCPSD'''
*Binary Image Negotiation Layer - '''BINLSD'''
*Trivial File Transfer Protocol - '''TFTPD'''
*Network FIle System - '''NFSD'''.

The first three daemons are necessary in order to enable the proper DHCP/PXE boot. Their configuration is discussed in more detail, within our article on remote-booting OS/2.

The fourth daemon is Linux-specific. Indeed, it provides the mount points for Linux clients. It is unrelated with DHCP/PXE stuff. The following files are critical for proper functioning of NFS in OS/2:
 nfs300.ifs, nfsd.exe, portmap.exe, rpc32dll.dll, rpcdll.dll, rpcdll32.dll

The file EXPORTS in \MPTN\ETC contains the information about the NFS shares that are exported by the OS/2 system. In general, each line of this file fixes a NFS share and gives the corresponding access privileges.

For example, to provide a NFS access for booting a single Linux client, we would start with a simple:
 E:\linux -alias suse7 -rw

==Setting up the PXE Command Processor==
We strongly recommend using BPBATCH command processor (the package can be downloaded for free from www.bpbatch.org), as a front-end for booting various operating systems from OS/2. It can operate in both interactive (command-line), or batch (script) modes. Among its many high-end features, there is a possibility to design nice pre-boot menu screens, enabling users to choose which operating system to boot at the start-up.

Here is a sample pre-boot menu script (bpbatch.bpb), allowing us to choose between remote-booted Linux and OS/2, also including a possibility to boot locally Windows and OS/2 from appropriate partitions (assuming the client would be equipped with the appropriate local hdd, of course!).
<pre>
set CacheNever="ON"
TextAttr white blue
Clear
Clear blue "\333" 3,8,15,72
At  4,20 Print "Welcome to eComStation-Managed Clients!"
At  5,20 Print "Preboot eXecution Environment Boot Menu"
At 10,20 Print "1:Diskless eComStation"
At 11,20 Print "2:Diskless Linux"
At 12,20 Print "3:Diskless Windows (Int13 Hooking)"
At 13,20 Print "4:Local HDD-Windows Partition"
At 14,20 Print "5:Local HDD-OS/2 Warp MCP2"

TextAttr yellow black
At 21,15 Print "To select a boot option, press the corresponding #(number)!"
TextAttr lightred black
At 24, 1 Print "UAME2 System Ver 02.10.2002/ Using BPBATCH as my FrontEnd..."

:loop
beep
GetKey BKey

If "$BKey" Match-Expr "1" Goto eComStation
If "$BKey" Match-Expr "2" Goto Linux
If "$BKey" Match-Expr "3" Goto Windows
If "$BKey" Match-Expr "4" Goto WinHDD
If "$BKey" Match-Expr "5" Goto OS2HDD

Goto loop

:eComStation
tftpboot "dhcpboot/ecsboot.com"

:Linux
include "dhcpboot/bpbatch.linux"

:Windows
tftpboot "dhcpboot/rmhook.i13"

:WinHDD
hdboot 0:1

:OS2HDD
hdboot 0:2
</pre>
Anyway, a good test to see if the above-mentioned 3 DHCP/PXE daemons work fine, is to get BPBATCH loaded and operational on the client side. There is a little point to move further if DHCP/PXE subsystem is not configured properly.

==Compiling the Appropriate Linux Kernel==
We should start with a (standard, HDD install) Linux system containing all the necessary tools to build a custom kernel. I strongly recommend using SuSE distribution (I did all my experiments with SuSE Linux Pro 7.2). See [2] for more information on Linux kernel compilation.

In preparing the kernel for Linux clients, we should pay attention to the following important points:
*Network File System V3 support precompiled;
*Network File System as root enabled;
*DEVFS support enabled;
*The appropriate processor type should be selected.
After compiling the kernel, it should be copied to the appropriate directory on the eComStation boot server, so that BPBATCH can find it, and load it (via TFTP).

A sample bpbatch command line syntax for initiating Linux boot is as follows:
 linuxboot "dhcpboot/bzImage3" "rw root=/dev/nfs nfsroot=192.168.1.1:suse7
 ip=192.168.1.6:192.168.1.1:192.168.1.1:255.255.255.0:bluebird.mx.moon"
In the previous example of the boot menu screen, this is also the contents of the file bpbatch.linux. Here, bzImage3 is the custom Linux kernel and "suse7" is the name of the principal NFS-share on the eComStation server.

After setting up BPBATCH and compiling the kernel, it is a good idea to check if it would start to boot Linux (obviously, it would fail to boot the client properly at this point, but at least we would be able to see if there is something deeply wrong with the kernel).

==Adjusting Clients==
We can build the client operating system tree, by directly copying to eComStation server, from the appropriate standard HDD-equipped Linux machine (login as root), and then editing the configuration files, when applicable.

In particular, to make DEVFS fully operational, it is necessary to execute DEVFSD during the client initialization phase:
 /sbin/DEVFSD /DEV
For example, this line can be added to the client main initialization script (of course, install DEVFSD so that the client can mount /DEV properly, in case the auxiliary HDD-equipped machine is not using DEVFS).

It is recommendable to start with a very simple Linux client, and have it booting fine from OS/2. Then gradually increment the complexity of the system. For example, we can choose a slow but safe path:
#Single client, text mode single user;
#Single client, text mode multi-user;
#Single client, graphical multi-user mode;
#Multiple clients, everything installed.
It is very interesting to observe that NFS daemon for OS/2 supports ''user-level privileges'' of the mounted file system. This is achieved by storing such attributes in a very special file: IBMNFSFH.DB.

This file "lives" in the directory \MPTN\ETC. It is basically a linear database containing an entry for every "unix-attribute-enhanced" file on NFS-mounted volumes. 
Every entry has the form:
 {16-bytes for Unix Attributes}{512-bytes for Full Filename}
In other words, each entry occupies 528 bytes. Having in mind that a typical Linux tree can contain many thousands of files, we see that the file IBMNFSFH.DB can easily get very large! The number 512 probably comes from DBCS considerations (HPFS/JFS filenames are limited to 256 characters).

When creating the Linux client tree on the eComStation boot server, it is crucial to copy the files via NFS, as we already mentioned, so that OS/2 can keep track of attributes of the corresponding files. Alternatively, we can use another copying method and then binary-edit IBMNFSFH.DB :)

In author's opinion, it was not a very good idea to design the NFS service for OS/2 in the way described:
*Too much control within the single IBMNFSFH.DB, a dangerous thing!
*Performance impact, in searching a huge database to figure out attributes of a given file.
It would be much better to have UNIX attributes simply stored in ''standard extended attributes'' of the corresponding files. Hopefully, one day we will have a more elaborated incarnation of NFS for OS/2...

For maximal client performance, it is strongly recommended to use ''a JFS volume on a fast SCSI disk'' to store Linux files.

Another (technical) limitation is that the NFS daemon of OS/2 does not support all possible UNIX attributes, so it is necessary to remove any extraordinary attributes (within Linux for example, using CHMOD) from files that we have to store on the OS/2 boot server, or avoid copying such objects at all. The most notorious example of attributes not at all allowed on OS/2 systems are ''device objects'', however they are not files, really. This is precisely the reason why we have to include DEVFS component in the kernel (and it is much better to use it anyway, from the conceptual viewpoint). Another attributes that should be avoided are ''S-attributes''. 
On the other hand, all standard user/group privileges (rwx), including file links (l), work fine in OS/2. Such file links are simply re-interpreted as text-files containing full-path real names of the object they point to!

==References==
#''Linux Remote Boot mini-HOWTO'', by Vuilleumier Stuckelberg, David Clerc (2000)
#''The Linux Kernel HOWTO'', by Brian Ward (2001).
#''Diskless Linux Kiosks'', by Jamie Zawinski (DNA Lounge: Source Code).
#''Configuring the FreeBSD Kernel'', by Jim Mock and Jake Hamby (Chapter 8 of the ''FreeBSD Handbook'').
#''FreeBSD Diskless Clients'', by Nathan Boeger (2000).

[[Category:Networking Articles]]