Managing NFS and NIS, 2nd Edition - Mike Eisler [99]
The server has no specific knowledge of the architecture of the client issuing a RARP or tftp request. It also needs a mechanism for determining if it can boot the client, using only its IP address — the first piece of information the client can discern. The server's /tftpboot directory contains boot blocks for each architecture of client support, and a set of symbolic links that point to these boot blocks:
[wahoo]% ls -l /tftpboot
total 282
lrwxrwxrwx 1 root root 26 Feb 17 12:43 828D0E09 -> inetboot.sun4u.Solaris_2.7
lrwxrwxrwx 1 root root 26 Feb 17 12:43 828D0E09.SUN4U -> inetboot.sun4u.Solaris_2.7
lrwxrwxrwx 1 root root 26 Apr 27 18:14 828D0E0A -> inetboot.sun4u.Solaris_2.7
lrwxrwxrwx 1 root root 26 Apr 27 18:14 828D0E0A.SUN4U -> inetboot.sun4u.Solaris_2.7
-rw-r--r-- 1 root root 129632 Feb 17 12:21 inetboot.sun4u.Solaris_2.7
lrwxrwxrwx 1 root root 1 Feb 17 12:17 tftpboot -> .
The link names are the IP addresses of the clients in hexadecimal. The first client link — 828D0E09 — corresponds to IP address 130.141.14.9:
828D0E09
Insert dots to put in IP address format:
82.8D.0E.09
Convert back to decimal:
130.141.14.9
Two links exist for each client — one with the IP address in hexadecimal, and one with the IP address and the machine architecture. The second link is used by some versions of tftpboot that specify their architecture when asking for a boot block. It doesn't hurt to have both, as long as they point to the correct boot block for the client.
The previous section stated that a server delays its response to a RARP request if it doesn't think it's the best candidate to boot the requesting client. The server makes this determination by matching the client IP address to a link in /tftpboot. If the link exists, the server is the best candidate to boot the client; if the link is missing, the server delays its response to allow another server to reply first.
The client gets its boot block via tftp, sending its request to the server that answered its RARP request. When the inetd daemon on the server receives the tftp request, it starts an in.tftpd daemon that locates the right boot file by following the symbolic link representing the client's IP address. The tftpd daemon downloads the boot file to the client. In some implementations, when the client gets a valid boot file, it reports the address of its boot server:
Booting from tftp server at 130.141.14.2 = 828D0E02
It's possible that the first host to reply to the client's RARP request can't boot it — it may have had valid ethers and hosts map entries for the machine but not a boot file. If the first server chosen by the diskless client does not answer the tftp request, the client broadcasts this same request. If no server responds, the machine complains that it cannot find a tftp server.
The tftpd daemon should be run in secure mode using the -s option. This is usually the default configuration in its /etc/inetd.conf entry:
tftp dgram udp wait root /usr/sbin/in.tftpd in.tftpd -s /tftpboot
The argument after the -s is the directory that tftp uses as its root — it does a chdir( ) into this directory and then a chroot( ) to make it the root of the filesystem visible to the tftp process. This measure prevents tftp from being used to take any file other than a boot block in tftpboot.
The last directory entry in /tftpboot is a symbolic link to itself, using the current directory entry (.) instead of its full pathname. This symbolic link is used for compatibility with older systems that passed a full pathname to tftp, such as /tftpboot/C009C801.SUN4U. Following the symbolic link effectively removes the /tftpboot component and allows a secure tftp to find the request file in its root directory. Do not remove this symbolic link, or older diskless clients will not be able to download their boot files.
Booting a kernel
Once the boot file is loaded, the diskless client jumps out of its PROM monitor and into the boot code. To do anything useful, boot needs a root and swap filesystem, preferably with a bootable kernel on