Linux Remote-Boot mini-HOWTO: Configuring Remote-Boot Workstations with Linux, DOS, Windows 95/98 and Windows NT: Special TFTP Servers

Next Previous Contents

## 6. Special TFTP Servers

As the only network support available in the TCP/IP BootPROM is TFTP, there is a special interest in enhancing TFTP servers for providing new capabilities.

## 6.1 Incom Enhanced TFTP Server

InCom GmbH distributes with the TCP/IP BootPROM an enhanced TFTP server that can send packets of up to 1408 bytes instead of the standard 512 bytes. This is a great enhancement that you should use. This server is available on the TCP/IP Bootprom Utility disk for Solaris, Windows and as Netware NLM.

## 6.2 Linux Enhanced TFTP Server

We built a modified version of Linux TFTP server that acts as InCom enhanced TFTP server. Basically, we simply changed the packet size from 512 to 1408 bytes and the port from 69 to 59. It is available from `http://cuiwww.unige.ch/info/pc/remote-boot/soft/etdtpd.tar.gz`.

## 6.3 The Security Gateway

We wrote a special TFTP server that serves as security gateway for authenticating users. This server runs under Linux or Solaris, and can authenticate users according to a Unix password database (NIS and shadow passwords are supported), a Windows NT (or Samba) server or a Radius server. It is available from `http://cuiwww.unige.ch/info/pc/remote-boot/soft/stdtpd.tar.gz`, with source and precompiled binaries. The precompiled binaries do not include NT password encryption as we cannot distribute `libdes` but compilation is straightforward.

In order to use the security gateway, you just have to setup a trivial security domains configuration file that describes to which authentication server each logical security domains maps (the `Unix` domain implicitely maps to the server Unix password database). This is a sample configuration file:

> `

>     #
>     # STFTPD configuration file
>     #
>     # This file specify the server of the "security domains". Two types of
>     # authentication servers are supported : radius or winnt (winnt includes
>     # NT Server and Samba)
>     #
>     # Format of radius servers
>     # radius        <domain>        <serveraddress>         <secret>
>     #
>     # secret is the secret word as specified in your /etc/raddb/clients file
>     #
>     # Format of SMB servers
>     # winnt         <domain>        <serveraddress>         <netbiosname>
>     #
>     # netbiosname is the NETBIOS name of your server
>     #
>     # Examples
>     radius         sec-dom-rad     radiusserver    testing123
>     winnt          sec-dom-nt1     192.168.1.1     NTSERVER1
>     winnt          sec-dom-smb     samba           SAMBA1

> `

Note that if you are using Samba, you must set `security = user`.

You can also provide to the security server a file containing a list of users which are not allowed to log on (for which the check will fail anyways).

## 6.4 The Broadcast TFTP Server

We wrote a special TFTP server that implements a home-made Broadcast variant of TFTP. Using this server, we were able to download images to 25 clients on a heavily loaded 10 Mb ethernet network at 6 Mb/s (it is more efficient than the regular TFTP because it does not need to acknowledge each packets). This server runs under Linux or Solaris. It is available from `http://cuiwww.unige.ch/info/pc/remote-boot/soft/btdtpd.tar.gz`, with source and precompiled binaries.

As the TCP/IP bootprom does not support this protocol, our solution consist in booting a tiny ramdisk-based linux system using the tools described in this document, and running the Linux version of MrBatch which has built-in support for Broadcast TFTP. A simple batch file can the download all files to the cache in a few minutes, simultaneously on all client computers. You do not need to install Linux yourself to use this package, except if you have exotic hardware and cannot directly use the kernel provided in the package.

The process works as follow. First, you startup the broadcast server manually, giving the number of expected client computers as argument (remember, this procedure is not to be used every day but only when you changed an image and want to ensure it is immediately uploaded to all your client computers). Then, you turn on all client computers, which will run the following BpBatch script:

> `

>     #
>     # This batch is run by bpbatch to launch a mini-linux using an initial
>     # ramdisk, which will then run mrbatch under linux.
>     #
>     # The broadcast TFTP protocol only works with the Linux implementation of
>     # mrbatch, because of the lack of broadcast support in the bootprom itself.
>     #
>     # 1. Setup a tiny partition, to let a lot of space for the cache
>     setpartitions "BIGDOS:50"
>     # 2. Clean the MBR
>     clean 0
>     # 3. Run a Linux Kernel with initrd (Initial Ramdisk) supprt, and use
>     #    bcastrd.gz as the initial ramdisk (will be mounted root and then
>     #    executed via /linuxrc). See initrd.txt for more details about
>     #    initial ramdisks. You don't have to specify a root device (second
>     #    parameter is null) to the kernel, it will use the initial ramdisk.
>     linuxboot "linux.krn" "" "bcastrd.gz"
>     # 4. The initial ramdisk will run dhcpcd to setup networking using DHCP.
>     #    It will then run mrbatch -w bcastlx

> `

The initial ramdisk contains:

- `dhcpcd`, a DHCP client used to setup networking
- `mrbatch`
- `linuxrc`, a little wrapper automatically started by initrd and that starts `dhcpcd` then `mrbatch`.
- `usr/lib/terminfo/l/linux`, used by MrBatch
- `dev/*`, devices needed to run Linux and mrbatch

All programs are statically linked and stripped, to avoid `libc.so` which is really huge. The resulting ramdisk is Gzipped and takes less than 300 KB. The kernel itself takes 450 KB (with many network cards and initrd support). When Linux is up and running, MrBatch is called with the following script (that you should edit for your needs):

> `

>     # This file is executed when mrbatch is launched by the initial ramdisk
>     # bcastrd.gz
>     # It's main purpose is to "broacast copy" files to the cache
>     #
>     # 1. Be verbose
>     showlog
>     # 2. Don't want a "press a key"
>     set pauselog="OFF"
>     # 3. Set partitions at their final values.
>     #    Important: Since you will copy files into the cache to be used in future
>     #    boot, you need to specify the same partitions as in the future boots.
>     setpartitions "BIGDOS:1024"
>     # 4. Clean the CACHE partition
>     clean -1
>     # 5. And the copy files into the cache, using the Broadcast TFTP protocol
>     #    (port 99)
>     #
>     # You can use the script "as is", but you surely need to modify the following
>     # line ! In our example, we download the file mblinux.imz, which is the image
>     # file for our installation of Linux.
>     copy "$BOOTP-Server-IP@99:mblinux.imz" "{:-1}mblinux.imz"

> `

When the transfer is done, you can simply turn off all client computers and change their initial boot script to your favorite menu.

Next Previous Contents