 | Chapter 9 Configuring Network Servers |  |
| Chapter 9 Configuring Network Servers | |
Large networks have multiple servers. As noted earlier, the servers are often distributed around the network with a server on every subnet. This improves booting efficiency, but it conflicts with the goal of central configuration control. The more servers, the more dispersed the control, and the more likely that a configuration error will occur. Implementing distributed servers requires a technique for maintaining central control and coordinating configuration information among the servers. TCP/IP offers several techniques for doing this.
Any file transfer protocol can be used to move configuration data, or any other kind of data, from a central system to a group of distributed systems. Either FTP or TFTP will work, but both of these protocols present difficulties when used in this way. FTP and TFTP are interactive protocols; both require multiple commands to retrieve a file, making them difficult to script. Additionally, FTP requires password authentication before it grants access to a file and most security experts frown on storing passwords inside of scripts. For these reasons we don't concentrate on using these protocols to distribute the configuration file. Besides, if you know how to use FTP (and you should!), you know how to use it to send a configuration file.
Another possibility is to use Network File System (NFS) to distribute the information. NFS allows files on the server to be used by clients as if they are local files. It is a powerful tool, but it does have limitations when used to distribute configuration information to boot servers. The same power outage that affects the distributed servers can cause the central server to crash. The distributed servers and their clients can be delayed in booting waiting for the central server to come back online. Sharing a single copy of the configuration file conflicts with the effort to distribute boot services because it puts too much reliance on the central server.
One way to avoid this problem is for the distributed servers to periodically copy the configuration file from the mounted filesystem to a local disk. This is very simple to script, but it creates the possibility that the servers will be "out of sync" at certain times - the distributed servers copy the configuration file on a periodic schedule without knowing if, in the interim, the master file has been updated. Of course, it is possible for all of the remote servers to export filesystems that the central server mounts. It is then possible for the central server to copy the configuration file directly to the remote filesystems whenever the master file is updated. However, there are easier ways to do this.
The UNIX r-commands rcp and rdist provide the most popular methods for distributing the configuration file.
Remote copy (rcp) is simply a file transfer protocol. It has two advantages over FTP for this particular application: it is easy to script and it does not require a password. rcp is easy to script because only a single line is needed to complete a transfer. An example of transferring the file bootptab from the master server to a remote server named pistachio.nuts.com is:
# rcp /etc/bootptab pistachio.nuts.com:/etc/bootptab
For every remote server that the file is sent to, add a line like the one shown above to the procedure that updates the master configuration file.
rcp is only one choice for distributing the central configuration file. rdist, while a little harder to use, is often a better choice because it has several features that make it particularly well suited for this application.
The Remote File Distribution Program (rdist) is designed to maintain identical copies of files on multiple hosts. A single rdist command can distribute several different files to many different hosts. It does this by following the instructions stored in an rdist configuration files called a Distfile.
The function of a Distfile is similar to that of the Makefile used by the make command, and it has a similar syntax and structure. Now, don't panic! It's not that bad. The initial configuration of an rdist command is more difficult than the straightforward syntax of an rcp command, but the rdist command provides much more control and is much easier to maintain in the long run.
A Distfile is composed of macros and primitives. Macros can be assigned a single value or a list of values. If a list of values is used, the list is enclosed in parentheses, e.g., macro = ( value value ). Once assigned a value, the macro is referenced using the syntax ${macro}, where macro is the name of the macro. The other components of a Distfile, the primitives, are explained in Table 9.4 [11]
[11] For more details, see the rdist manpage.
| Primitive | Description |
|---|---|
| install | Recursively updates files and directories. |
| notify address | Sends error/status mail messages to address. |
| except file | Omits file from the update. |
| except_pat pattern | Omits filenames that match the pattern. |
| special "command" | Executes command after each file update. |
The simplest way to understand how the primitives and macros are combined to make a functioning Distfile is to look at a sample. The following configuration file distributes the current version of bootpd and the latest bootptab configuration file to the remote boot servers pecan, pistachio, and cashew:
HOSTS = ( pecan root@cashew pistachio )
FILES = ( /usr/etc/bootpd /etc/bootptab )
${FILES} -> ${HOSTS}
install ;
notify craig@almond.nuts.comLet's look at each line of the file:
This line defines HOSTS, a macro that contains the hostname of each of the remote servers. Notice the entry for cashew. It tells rdist to login as root on cashew to perform the update. On pecan and pistachio, rdist will run under the same username it has on the local host.
This macro, FILES, defines the two files that will be sent.
The -> symbol has a special meaning to rdist. It tells rdist to copy the files named at the left of the symbol to the hosts named at the right. In this case FILES is a macro that contains the file names /usr/etc/bootpd and /etc/bootptab, and HOSTS is a macro that contains the hostnames pecan, cashew, and pistachio. Therefore this command tells rdist to copy two files to three different hosts. Any primitives that follow apply to this file-to-host mapping.
The install primitive explicitly tells rdist to copy the specified files to the specified hosts if the corresponding file is out-of-date on the remote host. A file is considered "out-of-date" if the creation date or the size is not the same as the master file. The semicolon at the end of this line indicates that another primitive follows.
Status and error messages are to be mailed to craig@almond.nuts.com.
Additional files and hosts can be easily added to this file. In the long run most people find rdist the simplest way to distribute multiple files to multiple hosts.
One final note: the configuration file does not have to be called Distfile. Any file name can be specified on the rdist command line using the -f option. For example, the Distfile shown above could be saved under the name bootp.dist and invoked with the following command:
% rdist -f bootp.dist
|  | |
| 9.5 DHCP |  | 9.7 Mail Servers |