Библиотека сайта rus-linux.net
|Purchase||Copyright © 2002 Paul Sheer. Click here for copying permissions.||Home|
Next: 35. The LINUX File Up: rute Previous: 33. Sending Faxes   Contents
- 34.1 Command-Line Operation
- 34.2 Configuration
- 34.3 Modem Dial
tty/UUCP Lock Files
- 34.5 Debugging
- 34.6 Using
- 34.7 Scheduling Dialouts
uucp is a command to copy a file from one UNIX system to another.
uux executes a command on another UNIX system, even if that
command is receiving data through stdin on the local system.
extremely useful for automating many kinds of distributed functions,
like mail and news.
uux commands both come as part of the
uucp (Unix-to-Unix Copy) package.
uucp may sound ridiculous considering the availability of modern
rsh, or even FTP transfers
(which accomplish the same thing), but
uucp has features that
these do not, making it an essential, albeit antiquated, utility. For
uucp never executes jobs immediately. It will, for
example, queue a file copy for later processing and then dial the
remote machine during the night to complete the operation.
uucp predates the Internet: It was originally
used to implement a mail system, using only modems and
telephone lines. It hence has sophisticated protocols for ensuring that
your file/command really does get there, with the
maximum possible fault tolerance and the minimum of
retransmission. This is why it should always be used for
automated tasks wherever there are unreliable (i.e., modem)
uucp version that comes with most LINUX
distributions is called Taylor UUCP after its author.
Especially important is that when a
uucp operation is interrupted
by a line break, the connection time is not wasted:
not have discarded any partially transmitted data. This means that no
matter how slow or error prone the connection, progress is always made.
Compare this to an SMTP or POP3/IMAP
connection: Any line break halfway
through a large mail message will necessitate that the entire operation to be
restarted from scratch.
To copy a file from one machine to another, simply enter
You can also run commands on the remote system, like
rmail on the remote system
feeding some text to the
rmail program. Note how you should quote
! character to prevent it from being interpreted by the shell.
(These commands will almost always fail with
permission denied by remote.
The error will come in a mail message to the user
that ran the command.)
uucp comes with comprehensive documentation
in HTML format
/usr/share/...) on RedHat, and
info format on Debian and RedHat. Here, I sketch
a basic and typical configuration.
uucp package has a long history of revisions, beginning with
the first modem-based mail networks. The latest GNU editions that
come with LINUX distributions have a configuration file format that
will probably differ from that which old
uucp hands are used to.
Dialup networks today typically use
combination with normal PPP dialup, probably not using
dial-in facilities at all. For example, if you are deploying a number of remote
hosts that are using modems, these hosts should always use
upload and retrieve mail, rather than POP3/IMAP or straight
SMTP, because of the retransmission problem discussed above.
In other words,
uucp is really working as an ordinary TCP service,
albeit with far more fault tolerance.
uucp into a TCP server, place it into
/etc/inetd.conf as follows
being also very careful to limit the hosts that can connect
by using the techniques discussed in Chapter 29.
xinetd, create a file
uucp configuration files are stored under
Now we configure a client machine,
machine1.cranzgot.co.za, to send mail through
server1.cranzgot.co.za is running the
uucp has an antiquated authentication
mechanism that uses its own
list of users and passwords completely distinct from those of ordinary UNIX
accounts. We must first add a common ``user'' and password to both machines
for authentication purposes. For
machine1.cranzgot.co.za, we can add to
/etc/uucp/call the line
uucp to use the login
whenever trying to speak to
server1.cranzgot.co.za we can add to the file
/etc/uucp/passwd the line,
Note that the
server1 was chosen for the
server1.cranzgot.co.za for convenience.
however, have nothing to do with domain names.
Next, we need to tell
uucp about the intentions of
machine1. Any machine that you might connect to or from
must be listed in the
Our entry looks like
and can have as many entries as we like. The only things
server1 has to know about
machine1 are the user and password
and the preferred protocol. The
*'s mean to look up the user and
password in the
/etc/uucp/passwd file, and
means to use a simple non-error, correcting protocol (as appropriate for
use over TCP). The
commands option takes a space-separated list
of permitted commands--for security reasons, commands not in
this list cannot be executed. (This is why I stated above that commands
will almost always fail with
permission denied by remote--they
are usually not listed under
/etc/uucp/sys file on
machine1 will contain:
time any specifies which times of the day
uucp may make calls
server1. The default is
time Never. [See the
documentation under Time Strings for more info.] The option
means that we are using a modem named
TCP to execute the dialout. All
modems are defined in the file
/etc/uucp/port. We can add our modem entry
/etc/uucp/port as follows,
which clearly is not really a modem at all.
Finally, we can queue a mail transfer job with
and copy a file with
/var/spool/uucppublic/ is the only directory
you are allowed access to by default. You should probably keep it this
way for security.
Although we have queued a job for processing, nothing will transfer until
uucico (which stands for Unix-to-Unix
copy in copy out) is run. The idea is that both
machine1 may have queued a number of jobs; then when
uucico is running on both machines and talking to each other,
all jobs on both machines are processed in turn, regardless of which
machine initiated the connection.
uucico is run from a
crond script every hour.
(Even having run
uucico, nothing will transfer if the time
of day does not come within the ranges specified under
Here we can run
tail -f /var/log/uucp/Log
uucico manually as follows:
The higher the debug level, the more verbose output you will
see in the
Log file. This will
--forceably dial the
server1 regardless of when it last dialed
(usually there are constraints on calling soon after a failed call:
--force overrides this).
If your mail server on
server1 is configured correctly, it
should now have queued the message on the remote side.
If you are really going to use
uucp the old-fashioned way,
you can use
uucp calls on
by adding the following to your
And then add the line
to the file
/etc/mgetty/login.config for Debian). You will then also
have to add a UNIX account
pAsSwOrD123. This approach works is because
uucico have the same login prompt
and password prompt, but
/etc/uucp/passwd to authenticate. Also, for
a modem connection,
protocol t is error prone:
change it to
which has small packet sizes
and error correction.
Note that the above configuration also supports faxes, logins, voice, and PPP
(see Section 41.4) on the same modem, because
mgetty only starts
uucico if the user name is
To dial out from
machine1, you first need to add a
modem device (besides
TCP) to your
ACU is antiquated terminology
and stands for Automatic Calling Unit (i.e., a
modem). We have to specify the usual types of things for serial ports,
like the device (
/dev/ttyS0 for a modem on COM1) and speed of
the serial line. We also must specify a means to initialize the modem:
dialer mymodem option. A file
then contain an entry for our type of modem matching ``
as follows: [This example
assumes that an initialization string
sufficient. See Section 3.5.]
More about modems and dialing is covered with
With the modem properly specified, we can change our
entry in the
sys file to
uux commands should now work over dialup.
I hinted about lock files in Section 33.2. A more detailed explanation follows.
You will have noticed by now that several services use serial devices, and many of them can use the same device at different times. This creates a possible conflict should two services wish to use the same device at the same time. For instance, what if someone wants to send a fax, while another person is dialing in?
The solution is the UUCP lock file. This is a file created by a process
/var/lock/ of the
LCK..device that indicates
the serial port is being used by that process. For instance, when running
sendfax through a modem connected on
/dev/ttyS0, a file
/var/lock/LCK..ttyS0 suddenly appears.
This is because
sendfax, along with all other
programs, obeys the UUCP lock file convention. The contents
of this file actually contain the process ID of the program using the
serial device, so it is easy to check whether the lock file is bogus. A lock
file of such a dead process is called a stale lock file and
can be removed manually.
uucp implementations rarely run smoothly the first time.
Fortunately, you have available a variety of verbose debugging options.
--debug option to specify the level of debug output. You
should examine the files
/var/log/uucp/Stats to get an idea
about what is going on in the background. Also important
is the spool directory
/var/spool/uucp/. You can
the debugging level with
--debug level where level
is in the range of
11. You can also use
--debug chat to only see modem communication details. A full description
of other options follows [Credits to the
- Output debugging messages for abnormal situations, such as recoverable errors.
- Output debugging messages for chat scripts.
- Output debugging messages for the initial handshake.
- protocol Output debugging messages for the UUCP session protocol.
- Output debugging messages for the individual link protocols.
- Output debugging messages for actions on the communication port.
- Output debugging messages while reading the configuration files.
- Output debugging messages for actions in the spool directory.
- Output debugging messages whenever another program is executed.
- List all incoming data in the debugging file.
- List all outgoing data in the debugging file.
- All of the above.
machine1 we would like
exim to spool all mail through
uucp requires a pipe transport (
discussed in Section 30.3.2).
merely sends mail through stdin of the
uux command and then forgets
uux is then responsible for executing
server1. The complete
exim.conf file is simply as follows.
exim must however be running
as a full-blown mail server to properly route the mail elsewhere. Of
rmail is the sender; hence, it appears to
exim that the mail is coming from the local machine. This means
that no extra configuration is required to support mail coming
Note that you can add further domains to your
so that your dialouts occur directly to the recipient's machine.
You can then add further entries to your
file as follows:
exim.conf file on
server1 must also have a
router to get mail back to
machine1. The router will look like this:
This router sends all mail matching our dial-in hosts through the
uucp transport while all other mail (destined for the Internet)
falls through to the
Above, we used
uucico only manually.
uucico does not operate
as a daemon process on its own and must be invoked by
All systems that use
uucp have a
or a script under
machine1 might contain:
uucico to loop through
all pending jobs and call any machines for which jobs are queued. It
does this every hour. The second line queues a null command three times
daily for the machine
server1. This will force
dial out to
server1 at least three times a day on the appearance
of real work to be done. The point of this to pick up any jobs coming
the other way. This process is known as creating a poll file.
Clearly, you can use
uucp over a TCP link initiated by
pppd. If a dial link is running in demand mode, a
call will trigger a dialout and make a straight TCP connection through
to the remote host. A common situation occurs when a number of satellite
systems are dialing an ISP that has no
To service the satellite machines, a separate
uucp server is
deployed that has no modems of its own. The server will have a permanent
Internet connection and listen on TCP for
Next: 35. The LINUX File Up: rute Previous: 33. Sending Faxes   Contents