Tải bản đầy đủ
[Chapter 9] 9.6 Managing Distributed Servers

[Chapter 9] 9.6 Managing Distributed Servers

Tải bản đầy đủ

[Chapter 9] 9.6 Managing Distributed Servers

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

9.6.1 rdist
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.
Table 9.4: rdist Primitives
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
file:///C|/mynapster/Downloads/warez/tcpip/ch09_06.htm (2 of 4) [2001-10-15 09:18:34]

[Chapter 9] 9.6 Managing Distributed Servers

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
HOSTS = ( pecan root@cashew pistachio )
FILES = ( /usr/etc/bootpd /etc/bootptab )
${FILES} -> ${HOSTS}
install ;
notify craig@almond.nuts.com
Let's look at each line of the file:
HOSTS = ( pecan root@cashew pistachio )
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.
FILES = ( /usr/etc/bootpd /etc/bootptab )
This macro, FILES, defines the two files that will be sent.
${FILES} -> ${HOSTS}
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.
install ;
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.
notify craig@almond.nuts.com
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:

file:///C|/mynapster/Downloads/warez/tcpip/ch09_06.htm (3 of 4) [2001-10-15 09:18:34]

[Chapter 9] 9.6 Managing Distributed Servers

% rdist -f bootp.dist

Previous: 9.5 DHCP
9.5 DHCP

TCP/IP Network
Book Index

Next: 9.7 Mail Servers
9.7 Mail Servers

[ Library Home | DNS & BIND | TCP/IP | sendmail | sendmail Reference | Firewalls | Practical Security ]

file:///C|/mynapster/Downloads/warez/tcpip/ch09_06.htm (4 of 4) [2001-10-15 09:18:34]

[Chapter 9] 9.7 Mail Servers

Previous: 9.6 Managing
Distributed Servers

Chapter 9
Configuring Network Servers

Next: 9.8 Summary

9.7 Mail Servers
In this section we configure a system to act as a post office server. A post office server, or mailbox server, is
a computer that holds mail for a client computer until the client is ready to download it for the mail reader.
This service is essential to support mobile users and to support small systems that are frequently offline and
thus not able to receive mail in real time. We look at two techniques for creating a mailbox server: Post
Office Protocol (POP), which is the most popular protocol for this purpose, and Internet Message Access
Protocol (IMAP), which is growing in popularity. We start with POP.

9.7.1 POP Server
A UNIX host turns into a POP mail server when it runs a POP daemon. Check your system's documentation
to see if a POP daemon is included in the system software. If it isn't clear from the documentation, check the
inetd.conf file, or try the simple telnet test from Chapter 4. If the server responds to the telnet test, not only
is the daemon available on your system, it is installed and ready to run.
% telnet localhost 110
Trying ...
Connected to localhost.
Escape character is ']'.
+OK POP3 almond Server (Version 1.004) ready
+OK POP3 almond Server (Version 1.001) shutdown
Connection closed by foreign host.
This example is from a Linux system, which comes with POP3 ready to run. The Solaris system, on the
other hand, does not ship with POP2 or POP3. Don't worry if your system doesn't include this software.
POP3 software is available from several sites on the Internet where it is stored in both the popper17.tar and
the pop3d.tar files. I have used them both and they both work fine.
If you don't have POP3 on your system, download the source code. Extract it using the UNIX tar command.
pop3d.tar creates a directory called pop3d under the current directory, but popper17.tar does not. If you
decide to use popper, create a new directory before extracting it with tar. Edit the Makefile to configure it
for your system and do a make to compile the POP3 daemon. If it compiles without errors, install the
daemon in a system directory.
Most network daemons are started by the Internet daemon, inetd. POP3 is no exception. Start POP3 from
file:///C|/mynapster/Downloads/warez/tcpip/ch09_07.htm (1 of 3) [2001-10-15 09:18:34]

[Chapter 9] 9.7 Mail Servers

inetd by placing the following in the inetd.conf file:







This entry assumes you are using pop3d, that you placed the executable in the /etc directory, and that the
port for this daemon is identified in the /etc/services file by the name pop3. If these things aren't true, adjust
the entry accordingly.
Make sure that POP3 is actually defined in /etc/services. If it isn't, add the following line to that file:


# Post Office Version 3

Once the lines are added to the services file and the inetd.conf file, send a SIGHUP to inetd to force it to
read the new configuration, as in this example:
# ps -ef | grep inetd
root 109 1 0
Jun 09 ?
# kill -HUP 109

0:01 /usr/sbin/inetd -s

Now that POP3 is installed, rerun the test using telnet localhost pop-3. If the POP3 daemon answers, you're
in business. All users who have a valid user account on the system are now able to download mail via POP3
or read the mail directly on the server.

9.7.2 IMAP Server
Internet Message Access Protocol (IMAP) is an alternative to POP. It provides the same basic service as
POP and adds features to support mailbox synchronization. Mailbox synchronization is the ability to read
mail on a client or directly on the server while keeping the mailboxes on both systems completely up-todate. On an average POP server, the entire contents of the mailbox are moved to the client and either deleted
from the server or retained as if never read. Deletion of individual messages on the client is not reflected on
the server because all of the messages are treated as a single unit that is either deleted or retained after the
initial transfer of data to the client. IMAP provides the ability to manipulate individual messages on either
the client or the server and to have those changes reflected in the mailboxes of both systems.
IMAP is not a new protocol - it is about as old as POP3. Nor is IMAP completely standardized. There have
been four distinct versions of IMAP: IMAP, IMAP2, IMAP3, and the current version IMAP4. New RFCs
about IMAP are still being issued. There are currently more than 10. The fear that IMAP is still in flux and
that it is difficult to implement has discouraged some vendors, so it is not as widely implemented as POP.
This is changing, however. The growing importance of email as a means of communicating, even when
people are out of the office, increases the need for a mailbox that can be read and maintained from
anywhere. The number of IMAP implementations is rising. Sun sells one for Solaris, another comes with
Slackware 96 Linux in the /usr/sbin/imapd file, and IMAP source code can be obtained via anonymous FTP
from ftp.cac.washington.edu. We use the University of Washington source code to update IMAP on our
Linux system for the examples in this section.
Download /mail/imap.tar.Z from ftp.cac.washington.edu as a binary image. Uncompress and untar the file.
This creates a directory containing the source code and Makefile needed to build IMAP. [12] Read the
file:///C|/mynapster/Downloads/warez/tcpip/ch09_07.htm (2 of 3) [2001-10-15 09:18:34]