The server has to provide at least the following services:
In the following sections we'll explain in more detail these services and their configuration.
The Diskless Client needs an IP address in order to access the server. This address is assigned to it by the initial bootp broadcast call made by the ethernet's eprom at start up.
The majority of the bootroms use the more simple bootp protocol to make this first call for information. Therefore, we will explain here in detail the setup of a dhcp server that responds to the bootp calls of the clients.
The dhcp protocol is an enhancement of the older bootp protocol. Both are designed to assign configuration parameters and IP data to clients. Dhcpd (the dhcp daemon) is the responsible of handling bootp and dhcp calls from the outside.
In the first step of the startup process of a diskless client this service provides the client with the necessary information to build up a conversation at higher level and to interact at the IP level with the server.
In order to configure the dhcp daemon, from now on called dhcpd, by default the /etc/dhcpd.conf file is used.
Here we have an example of a /etc/dhcpd.conf:
# -- General options used by default
option domain-name "dalton.org";
option root-path "/tftpboot/%s"
filename "vmlinuz"
#-- Declaration of a subnet of diskless clients
subnet 192.168.1.0 net-mask 255.255.255.224
{range dynamic-bootp 192.168.1.2 192.168.1.30;
}
host joe
{
hardware ethernet 00:80:c8:fa:90:49;
fixed-address 192.168.1.3;
filename "bwHercules.kernel"
}
host avarell
{
hardware ethernet 00:78:c9:44:ba:fa;
fixed-address 192.168.1.4;
filename "voodo.kernel";
}
host William
{
hardware ethernet 00:89:d4:82:da:eb;
fixed-address 192.168.1.5
}
This /etc/dhcpd.conf file configures three clients, joe, avarell and william, in order to work in the domain dalton.org.
The host assigns a name and a IP address to every client based on its MAC address (Media Access Control)
The MAC number is stored in the ethernet's card eprom. The manufacturer presets it with a unique number for every card, so it usually doesn't have to be changed. It shows up during the boot process, when the card is detected. To get it, you can boot from a floppy disk with a kernel configured to autodetect the ethernet card, or you can start a diskless bootup process and use a tool like tcpdump to show the broadcast call transmitted from the client. This call includes the card's MAC address.
If the client has not a registered internet address, it has to be assigned an IP address from a private address range, like 192.168.1.1 to 192.168.254.254. Other possible ranges may be found in the IP-Subnet-working HOWTO.
The host declaration in /etc/dhcpd.conf may include other parameters like the kernel image to use or the root directory assigned to the client. The client Avarell, for example, has a graphic card with a voodo-chip, therefore we assign a specially compiled kernel to this machine.
The client Joe has an old Hercules card so we assign another kernel with features for this old B/W card compiled in.
Finally, William has a standard graphic chip and starts up with the default kernel vmlinuz.
Usually, the dhcpd service is started up by a script in /etc/rc.d/* at the server initialization process.
The kernel has to be configured to include the following options, in order to run the dhcpd daemon:
As the name indicates TFTP is a protocol to transport files in a simple way. A diskless client uses this protocol at startup time to get the kernel from the server. The idea behind tftp is to offer a simple file transfer protocol to be used in small sized resource environments, as there are, for example, EPROM's, avoiding logins and state oriented connections.
The client has in this moment of the process the following information:
Due to the security risk that implies the use of the first option and the limited service that we need to provide from tftp we will use the second alternative. We will allow the clients to access only the directories where the kernel images and the rest of the client's directories are located. This is normally /tftpboot. The option
filename "vmlinuz"in the file dhcpd.conf refers to the kernel image that has to be found in a directory accessible for the client. Normally this is /tftpboot/.
TFTP is managed by the inetd daemon.
To make it work we have to add a line like the following one in /etc/inetd.conf:
tftp dgram udp wait nobody /usr/sbin/tcpd in.tftpd -s /tftpboot
/usr/src/linux/Documentation/nfsroot.txt by Gero Kuhlman and Martin Mares
The file dhcpd.conf defines the directory in the server that must be mounted as the root filesystem in the client with the root-path option. The line
option root-path "/tftpboot/%s"indicates that the
root of every client is /tftpboot/<client's IP address>.
This is the default configuration. In the case of the client avarell this means that its root filesystem will be the directory /tftpboot/192.168.1.4 in the server.
The NFS services of a normal linux distribution use the following three daemons:
The RPC (Remote Procedure Call) protocol forms part of the ISO-reference-model of network communication protocols. It lies between the application protocols, as for example NFS, and the transport protocols as TCP and UDP.
The rpc daemon executes procedures in a transparent way in a remote server.
The different rpc services are identified by numbers that are independent of the port numbers used by the TCP and UDP protocols. There is no fixed mapping convention between TCP/UDP ports and rpc numbers.
For this reason the rpc.portmapper has to be active in every server that offers RPC services. The portmapper is the only rpc service that has a unique and fixed IP port number. It is 111 and may be found in your /etc/services. His duty is to resolve the incoming calls of other rpc clients and to assign them an IP port number. Every starting rpc service communicates to the portmapper the IP port number it is using and what rpc program number it has.
The mountd daemon has to maintain the mounted file-systems on the server. It's main information source is the file /etc/exports. The rpc.mount daemon verifies with the help of this file the incoming mount petitions of the clients and if the directory-structure that the client wants to mount is included in /etc/exports the daemon mounts the required filesystem.
It's the responsibility of the NFS daemon to manage all incoming read/write calls from the clients to the directories remotely mounted and to send an answer that is transparent to the client's commands as ls, cp or rm.
The services of the NFS protocol use the UDP transport protocol (User Datagram Protocol. This protocol doesn't support transmission states as TCP and doesn't control if the packages sent are received, or the order in which they are received. The UDP protocol is much leaner than his brother in ISO level TCP. This makes it much faster and a temporarily broken connection is easily recovered.
The NFS protocol allows the same file and directory operations as a locally mounted filesystem.
NFS has been implemented in several platforms, as for example: UNIX/LINUX, VAX/VMS, MVS and still DOS systems may use it. All these platforms may interchange files using NFS. That means that NFS doesn't inform about the origin of the files it is working with.
To implement these features the so called virtual nodes and the VFS (Virtual File System) are used. These specifications define the interfaces used to communicate among different platforms. The VFS client assures that all the NFS operations act as if they were handling local files in the local directory structure.
The main configuration file used to manage the rpc.portmapper is the /etc/rpc file. In this file the names of the rpc daemons are mapped to numbers that are translated by the rpc.portmapper to IP ports. The information necessary for this translation is found in the /etc/services file.
The rpc.portmap daemon also allows or denies access to the system services based on the identity of the client requesting the service, using the information in the etc/hosts.deny and /etc/hosts.allow files.
To control the access to the NFS server from hosts in the dalton.org domain you would use something like the following two files:
ALL: .dalton.org
ALL EXCEPT bootps, bootpc :ALL
/etc/hosts.deny, we deny access to all services except bootp and dhcp, and from any host. The bootps and dhcp services have to be open on a Netclient-Server because the clients at the first step still do not have a IP-adress and do not belong to any network.
In the other file, /etc/hosts.allow, we allow access to any service from any machine in the dalton.org domain. Be sure that you type the preceding dot when specifying the dalton domain in the line
ALL: .dalton.orgRead the man pages host_access and hosts_options for detailed information.
The main configuration file of the mountd daemon is /etc/exports. In this file we tell which directories can be remotely exported and mounted, which clients can do it and what kind of access is allowed.
# The / directories of the ThinClients /tftpboot/192.168.1.2/ 192.168.1.2 (rw, no_root_squash) /tftpboot/192.168.1.3/ 192.168.1.3(rw, no_root_squash) /tftpboot/192.168.1.4/ 192.168.1.4 (rw, no_root_squash) # common directories with only read access /tftpboot/bin/ 192.168.1.0/255.255.255.0(ro, no_root_squash) /tftpboot/sbin/ 192.168.1.0/255.255.255.0(ro, no_root_squash) /tftpboot/lib/ 192.168.1.0/255.255.255.0(ro, no_root_squash) /tftpboot/usr/ 192.168.1.0/255.255.255.0(ro, no_root_squash) /tftpboot/opt/ 192.168.1.0/255.255.255.0(ro, no_root_squash) /cdrom/ 192.168.1.0/255.255.255.0(ro, no_root_squash)In this example we have a private directory for everyone of the three clients, with read/write access. These directories contain unique subdirectories
/tmp, /var, /dev, /etc, /root, and /home for every client. The other directories will be shared by all clients and they will have read only access. Other client directory structures, as listed in
Clients file system creation
, need another /etc/exports file.
The other important file for the rpc.mountd daemon is /etc/rmtab. It lists the local directories that have been mounted in remote stations, and is similar to the /etc/mtab file that works with the local mount-processes.
Every remote mount point creates a line as the following one:
joe.dalton.org:/tftpboot/192.168.1.2
When the client joe disconnects he first has to umount his /directory. That eliminates the above line in /etc/rmtab and gives the directory free.
rpc.nfsd handles the files and directories previously mounted by the rpc.mountd daemon. The most important decision in its configuration is the way to start it up.
The NFS daemons may be started up by the inetd daemon when a request is received, or they may be permanently active, listening for requests.
For a dedicated NFS server it is OK to have the rpc daemons always active.
If you decide for testing or other reasons to manage on a RED-HAT system the start up of the rpc daemons from inetd you should have a line like the following one in the /etc/inetd.conf file:
mountd/1 dgram rpc/udp wait root /usr/sbin/tcpd /usr/sbin/rpc.mountdTo have the daemon active all the time in a SuSE(6.4) system you need a file
/etc/rc.d/nfsserver. If you're working with a debian system you should have a /etc/rc3.d/S25nfs-server file to start the service in the third run-level this file is a symbolic link to the real configuration file and decides only if or if not to start the service in a ginven runlevel and what priority the service gets.
I'm working with the 2.2.14 kernel. As of kernel version 2.4.xx there is implemented the version 3 of the NFS-protocol that is said to bring a serious speed gain. To configure the 2.2.xx kernel for a NFS server you have to activate the following options:
TCP/IP Networking (CONFIG_INET = Y)
IP Masquerading (CONFIG_IP_MASQUERADE = Y) If we want the clients to be able to access the Internet through the server we must activate Masquerading.
Firewall (CONFIG_FIREWALL = Y)
Firewall (CONFIG_IP_FIREWALL = Y) You need the firewall at least to get the masquerading working
Rarp server support (CONFIG_INET_RARP = N) We'll use dhcpd to transport the start up information to the clients.
NFS server support (CONFIG_NFSD = Y)
/tftpboot or other directories to be exported to the clients we must set the following option:
Emulate Sun NFS daemon (CONFIG_NFSD_SUN =Y)
It's recommendable not to put the NFS server support as a module in the server.
There are different possibilities to generate a directory system for the Root-NFS-Clients.
This possibility is the easiest one. It requires a considerable amount of disk space and implies a separated maintenance of the configuration files for every client.
It's possible to share entire directory branches that use a lot of disk space but contain the same data for every computer, like: /usr, /bin, /lib, /opt or /sbin. Following this approach the disk space needed in the server is far less than in the first alternative and, in fact, simplifies the administration requirements.
It's also possible to share the directories /var, /etc and /home.
In this option you share the root of the server and all it's subdirectories with the clients. This is the option that less space requires but at the same time it's the most insecure and slow one. It's impossible to separate the often used files of the clients in different hard disks. A good documentation taking this approach can be found in "Root over nfs clients & server HOWTO" by Hans de Goede in
http://www.linuxdoc.org/HOWTO/Diskless-root-NFS-HOWTO.html
In this HowTo I'm gonna explain the second option, being the most flexible and less conflictive one in means of configuration and security.
To generate a client's filesystem we have two possibilities:
/tftpboot./tftpboot.
A great part of the directories may be shared in read only mode. They are:
Starting up, Linux needs to access some libraries included in this directory before mounting the filesystems listed in /etc/fstab. These libraries have to be copied directly into /tftpboot/<client's IP address>/lib.
As far as I know the following libraries are affected:
ld*libc.*libncurses*libhistory*libreadline*libdl*For this directory it's enough to create an empty directory called /tftpboot/<client's IP address>/usr that will be used by the clients as a mount point for the real /usr directory, which is maintained in the server's directory /tftpboot/usr.
Before you can mount the directories listed in /etc/fstab the client has to run some programs usually located in the /bin directory, as they are:
mount and umountbash and the link sh pointing to itrmlscploginhostname and the link domainname pointing to itThis directory is used by distributions like Red-Hat, SusE, ... to substitute part of /usr/local/ and a mix of the usual application directories for programs they classify as optional. It can be completely shared.
In the decision of which directories we want to share among some or all clients we have to be aware of the following:
The speed of read/write operations to disk are key factors if we want to gain speed for our clients. The more clients are trying to read/write to the same disk the slower the response speed they will get. If we distribute the directories in several disks with parallel access we may gain considerable speed.
One Gigabyte of EIDE hard disk space may currentlly (june 2001) cost around 3,3 Euros and for one GB of NW3 SCSI we have to pay 12 Euros. That means for this small amount of money we can gain considerable speed assigning less users to one /tftpboot/usr, /tftpboot/bin, and /tftpboot/sbin directory.
There are some directories that can't be or shouldn't be shared because they are used to save unique data for every client.
Part of this directory may be shared. Creating a directory /tftpboot/var/ you may share for example the directory /tftpboot/var/lib/. If you do it this way you have to create the directory /tftpboot/<client's IP address>/var/lib
and in the client's fstab (in /tftpboot/<client's IP address>etc/) you have to put a line like:
192.168.1.1:/tftpboot/var/lib /var/lib nfs roand in the server's file
/etc/exports must be a line like:
/tftpboot/var/lib 192.168.1.0/255.255.255.0(ro, no_root_squash). This way you can leave empty the directory
/tftpboot/var/lib/
You can't treat this way the following directories:var/log/, var/run, var/spool and var/lock because the clients need write access to them and there is machine specific information stored into.
The main part of the etc files may be shared. You only have to exclude the following ones: inittab, fstab, resolv.conf, hosts and rc.d/ . If you work with a etc directory per client you should think about the use of NIS.
The dev directory can be managed in three ways:
/tftpboot/<client's IP address>/dev/ for every client. It's the easiest and most secure solution, but it's also the slowest one. Here the /dev directory is treated like the rest of the directories.dev directory in ramdisk. This option saves space in disk and network traffic because the directory is in the client's ram. In /usr/src/linux/Documentation/ramdisk.txt by Paul Gortmaker you will find a well written and clear documentation about the use and creation of ramdisks./proc. This option is treated in "Root over nfs clients & server HOWTO" by Hans de Goede
http://www.linuxdoc.org/HOWTO/Diskless-root-NFS-HOWTO.html.The clients also need write permissions to this directory. You may use a common /tftpboot/tmp/ directory for all clients, you may create a /tftpboot/<client's IP address>/tmp for every client or you can place the /tmpdirectory of every client into it's ramdisk. The options are going from slower to faster and your choice may depend of the amount of available disk space and RAM.
There are different ways to create the basic directory structure of a client. The first one consists in installing a new linux system in a partition of the server. Here you easily select the packages you want to be available to the clients, using your preferred distribution's installing tool. You may also use the server's directories as origin for the client's file structure. To copy the files use the cp command with the -a option.
#:/cp -a ./* /tftpboot/
/etc/exports.