 |  |
| |
Large networks have multiple servers. As noted earlier, the servers are often distributed around the network with a server on every subnet. This improves network efficiency, but it conflicts with the goal of central configuration control. The more servers you have, 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 present difficulties when used in this way. FTP and TFTP are interactive protocols, and 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 in 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 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 while 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. The central server can then 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 dhcpd.conf from the master server to a remote server named arthropod.wrotethebook.com is:
# rcp /etc/dhcpd.conf arthropod.wrotethebook.com:/etc/dhcpd.conf
For every remote server that the file is sent to, add a line like this one 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 file 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. acros 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.[107]
[107]For more details, see the rdist manpage.
|
Primitive |
Function |
|---|---|
|
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 dhcpd and the latest dhcpd.conf configuration file to the remote boot servers horseshoe, arthropod, and limulus:
HOSTS = ( horseshoe root@limulus arthropod )
FILES = ( /usr/sbin/dhcpd /etc/dhcpd.conf )
${FILES} -> ${HOSTS}
install ;
notify [email protected]Let'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 limulus. It tells rdist to log in as root on limulus to perform the update. On horseshoe and arthropod, 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/sbin/dhcpd and /etc/dhcpd.conf, and HOSTS is a macro that contains the hostnames horseshoe, limulus, and arthropod. 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 [email protected].
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 filename can be specified on the rdist command line using the -f option. For example, the Distfile shown above could be saved under the name dhcp.dist and invoked with the following command:
% rdist -f dhcp.dist
|  | |
| 9.5. DHCP |  | 9.7. Post Office Servers |
Copyright © 2002 O'Reilly & Associates. All rights reserved.