UUCP (UNIX to UNIX CoPy) was developed to provide a simple dialup networking protocol for UNIX systems. It is most often used today as an e-mail transfer system, allowing non-networked machines to transfer e-mail easily over a modem connection. You also can use it for USENET news and access to similar services that do not require a dedicated connection. UUCP is a two-machine connection between your Linux machine and another machine running UUCP. You cannot use UUCP as a remote system access system (like FTP or Telnet), nor can you use it as a standard login because the protocols do not support this type of interactive behavior. Chapter 24 "Security," looked briefly at some of the security problems inherent with UUCP. You should read that section of the chapter when setting up your UUCP system if you are susceptible to unauthorized access.
Linux can run any of several different versions of UUCP, most of which are compatible with each other to a reasonable extent except when it comes to configuration and installation procedures. Many Linux versions offer you a choice between the Taylor UUCP version and the HDB (HoneyDanBer) UUCP. You can use whichever single version came with your Linux software, or, if you have both, you can choose between the two (or use both versions as the mood strikes you).
Many Linux users prefer the Taylor UUCP implementation. Users who have worked on other UNIX systems prefer HDB because it is more recent and a little more logical in its file handling and configuration. If you have a choice, you should probably use HDB. This chapter looks at both of these versions. (Although even more UUCP versions exist, they are seldom used under Linux.) The first part of the chapter deals with configuring UUCP, and the rest of the chapter explains how to use it.
Most of the configuration required for UUCP takes place in the /usr/lib/uucp directory. UUCP uses several files, most of which need direct administrator modification to be set up properly. Although the configuration process can seem complex to someone who has never done it before, only a few files need changing, and each file has only one or two entries.
Because the configuration processes for Taylor UUCP and HDB UUCP are completely different, this section looks at them separately. You don't have to worry about which version of UUCP is being run at the remote end of the connection, however, because both versions can talk to each other (at least that's usually the case) as long as the configuration files are set up properly.
Some versions of Linux have semi-automated UUCP configuration scripts. These scripts are more common with HDB UUCP than Taylor UUCP, but a few helpful scripts are available for the latter. If you have one of these scripts, use it, but do check the files manually afterwards.
In the follwing examples of configuration processes, the host machine's name is merlin, and it is being connected through UUCP to another Linux system called arthur. As you go through the process, take care to enter the information in the same format as the examples, but don't mix Taylor and HDB UUCP information.
The following list contains the filenames and the primary purposes of the configuration files for the Taylor UUCP system:
| /usr/lib/uucp/config | This file defines the local machine name. |
| /usr/lib/uucp/sys | This file defines the remote systems and how to call them. |
| /usr/lib/uucp/port | This file describes each port for calling out and its parameters. |
| /usr/lib/uucp/dial | This file describes the dialers for calling out. |
| /usr/lib/uucp/dialcodes | This file contains expansions for symbolic dialcodes, but it is rarely used when a straight-out telephone connection exists. |
| /usr/lib/uucp/call | This file contains the login name and password for remote systems, but it is rarely used now. |
| /usr/lib/uucp/passwd | This file contains the login names and passwords used when remote systems connect to your local machine. This file is used only when uucico is password checking instead of using the login process. |
To make the configuration process easier, this section proceeds with a sample configuration. You need only modify the entries to suit your own names, telephone numbers, device files, and so on. You can then repeat the process for as many systems as you want to connect to.
The first file you need to modify holds your system name and other general parameters. The file /usr/lib/uucp/config needs a single line entry for your system name, such as this one:
hostname merlin
The keyword hostname must be first on the line, followed by whitespace (spaces or tabs)and your machine name. The information in this file may have been completed when you installed Linux, but you should check the contents to make sure. If your system's name isn't set correctly, the connection to the remote system won't work properly.
To use UUCP, you must have a system name. For compatibility with most versions of UUCP, keep the name to seven characters or less. Ideally, the UUCP name is the same name you assigned to your host during configuration. The name doesn't have to follow a convention (like the system name used by TCP/IP for Internet access), but if you use other network protocols, keep a consistent name. If you have a domain name (for TCP/IP access), use the first component of the machine's full TCP/IP name as the UUCP name. For example, if your full domain name is merlin.wizards.com, use the UUCP name merlin.
You also need to provide information about the remote system you want to connect to. The /usr/lib/uucp/sys file holds all the information about remote systems. This file usually has a few sample entries in it that you can copy or modify. Don't leave comment marks (pound or hash marks) in the first column or the entries will be ignored. A /usr/lib/uucp/sys entry for the remote machine arthur looks like the following:
# system: arthur (Bill Smallwood's Linux system) system arthur time Any phone 555-1212 port com1 speed 9600 chat login: merlin password: secret1
The first line in the preceding extract is a comment line. Most system administrators like to put a comment line in to identify each system. The next lines identify the different aspects of the remote system, including its name (arthur), times at which it can be called (Any in this case, meaning no restrictions), the telephone number (including any area code or special digits that have to be dialed), the serial port to be used for the connection (in this case, com1), the speed at which to connect (9600 baud), and the chat script or login process. In this case, the chat script tells UUCP to wait until it sees the string login:, and then send merlin. Then UUCP waits for the prompt password: and sends secret1.
Most login scripts require a login and password, and you must place these items in the configuration file because UUCP doesn't allow interactive sessions. This requirement can be a bit of a problem because it allows other users on your system to see the login password for the remote machine. But because only UUCP can use this password, this problem is not a major concern. Also, you can set the file permissions on the UUCP configuration files to prevent any system users (other than root) looking into the file.
Not all remote sites need a password for entry through UUCP. For example, some public archives let you log in and retrieve files using the uucp login with no password. Other sites use readily available passwords, such as uucp.
The port name used in the /usr/lib/uucp/sys entry does not have to match a device name on the Linux system because the file /usr/lib/uucp/port is used to match the entry to a physical device. This file requires an entry similar to the following for a 9600 baud modem:
# com1 device port port com1 type modem device /dev/cua0 speed 9600 dialer Hayes
In the /usr/lib/uucp/port file, the name of the port used in the /usr/lib/uucp/sys file is identified on the first line. The type of connection to be used (usually modem) is on the next. The Linux device that corresponds to the port name is specified as a device driver (for many Linux systems this driver can be /dev/modem, which is linked to the serial port device driver).
The modem connection speed comes next, and it shows the maximum speed of the modem. Finally, the name of a dialer is entered. This parameter is a throwback to the days when modems couldn't dial themselves and used another device (called a dialer) to make the connection. The dialer entry in the /usr/lib/uucp/port file is then matched to an entry in the file /usr/lib/uucp/dial, which tells the modem how to dial the phone. Here's a sample entry:
# Hayes modem dialer Hayes chat "" ATZ OK ATDT\T CONNECT
This entry shows the script that the system uses to communicate to the Hayes modem. In this case, the \T in the command line is replaced with the telephone number to be called. Some Linux system combine the /usr/lib/uucp/port and /usr/lib/uucp/dial files into a single entry in the /usr/lib/uucp/sys file that names the modem file directly.
The remote end of the connection (in this case, the system arthur) must have corresponding entries for merlin. The files are similar with only name, telephone number, and (possibly) device name and chat script changed. Until both ends are configured properly, you can't get a connection between the two machines. Some Linux systems with Taylor UUCP have a utility called uuchk that verifies the syntax in the UUCP configuration files and prints out summary information. If you don't have the uuchk utility, you can download it from many FTP and BBS sites.
By default, Taylor UUCP allows a remote system to execute only a limited number of commands when it logs into your system. Typically, the remote is only allowed to execute rmail and rnews to transfer mail and news respectively. If you want to allow extra programs to be executed, add a line to the /usr/lib/uucp/sys file that includes all the commands the remote system can execute. For example, the entry
system chatton .... commands rmail rnews rstmp rdataupdate
specifies that the system chatton can execute any of the four commands given after the commands keyword. Note that all four commands must be in the usual search path used by the UUCP utilities (actually by uuxqt).
If you intend to transfer files between two machines, you must also modify the configuration files. When a remote system sends a file to your machine, the files usually should be stored in the directory /usr/spool/uucppublic (some systems use /var/spool/uucppublic) as a safety precaution. You don't want to allow a remote system to write files anywhere on your filesystem, or it could overwrite critical system files. The convention for most UUCP systems is to always use /usr/spool/uucppublic as the transfer directory.
You can specify transfer and receive directories in the /usr/lib/uucp/sys file. For example, the following entry for the remote system chatton has been modified to include specific directories for file transfers:
system chatton ... local-send ~/send local-receive ~/receive
In this configuration, the users on your local machine can send any file that is in the /send directory under the UUCP directory (~/send, which means that any file to be sent to a remote system must be transferred there first), and any file incoming from a remote system is stored in the receive directory under the UUCP directory. If you want to allow transfers from a user's home directory, you can specify the /usr directory as a starting point. Multiple entries are separated by spaces, so the entry
local-send ~/send /usr
allows transfers from the /send directory under the UUCP directory or from any directory under /usr.
The preceding two lines deal only with file transfers requested or sent from your machine. If you want to enable requests for transfers from the remote machine, you need to add two more lines:
remote-send /usr/lib/uucppublic remote-request /usr/lib/uucppublic
These lines force the remote machine to request files and send them only to the /usr/lib/uucppublic directory. Again, you can offer several choices if you want, as long as they are separated by spaces.
Finally, UUCP allows machines to forward data through other machines, a process called hopping. In other words, if you want to send mail to the system warlock but can only get there through the system wizard, you have to instruct UUCP that your local system can get to warlock through wizard by adding a forward command to the /usr/lib/uucp/sys file:
system wizard ... forward warlock
You should then add an entry for the warlock system that tells UUCP that any mail for you will be coming back through wizard:
system warlock ... forward-to merlin
The forward-to command ensures that any files returned by warlock are passed to merlin, the local host machine. Otherwise, UUCP would discard these files for not being routable. By default, Taylor UUCP does not allow forwarding, and most system administrators should think carefully about allowing it as the potential for abuse is high.
HDB UUCP is a more recent version of UUCP and its configuration files are different from Taylor UUCP. In many ways, the HDB configuration is easier than the Taylor UUCP configuration, although neither is difficult once you know the basic process. Instead of setting the name of the local system in the UUCP configuration files, you use the hostname command (see Chapter 17, "System Names and Access Permissions").
The names of the remote systems are stored in the file /usr/lib/uucp/Systems (some older versions used the name /usr/lib/uucp/L.sys). Each remote system that will be connected to the local system has a single line. The format of each line is
sitename schedule device_type speed phone login_script
where sitename is the name of the remote machine, schedule is when the machine can be connected to the local system, device_type is the type of device used to call the remote system, speed is the speed (or range of speeds) that you can use to connect to the remote system, phone is the telephone number of the remote system, and login_script is the script used when a connection is made (like the chat script in Taylor UUCP). For example, to call the remote system arthur, the /usr/lib/uucp/Systems file has a line like the following:
arthur Any ACU 9600 555-1212 login: uucp password: secret1
The Any entry in the schedule field tells UUCP that it can call at any time. The ACU entry in the device_type field tells UUCP to use the ACU (automatic calling unit) defined in the /usr/lib/uucp/Devices file.
The /usr/lib/uucp/Devices file (or /usr/lib/uucp/L-devices file in some older versions) contains information about the devices (usually modems) that you can use to call the remote systems. The Devices file follows this syntax
devicetype ttyline dialerline speed dialer [token Dialer ...]
where devicetype is the name of the device (which should match the device name in the /usr/lib/uucp/Systems file), ttyline is the device driver to be used for the connecting port (usually a serial line, such as /dev/tty2a or /dev/modem), dialerline is an obsolete field left as a hyphen, speed is the speed range of the device, and dialer is the name of the file that tells UUCP how to use the device. A sample line for a Hayes 9600 baud modem used to connect on the second serial port of the system might have an entry in the /usr/lib/uucp/Devices file like the following:
ACU tty2A - 9600 dialHA96
This entry identifies the ACU entry as a 9600 baud connection through /dev/tty2A (the /dev portion of the name is not needed with HDB UUCP), and it uses a program called dialHA96 to handle the setup and dialing of the modem. Most popular modems usually have programs available that set the modem configuration parameters automatically, leaving Linux out of that process. If a program is not available to handle the modem, you can use an entry in the file /usr/lib/uucp/Dialers. The format of the Dialers entries is
dialer translation expect send ...
where dialer is the name of the dialer (matching the Devices file), translation is the translation table to use for the phone number (converting characters where needed to pauses, beeps, and so on), and the expect and send entries are the chat script to set up the modem. A sample line in the Dialers file looks like the following:
hayes1200 =,-, "" AT\r\c OK\r \EATDT\T\r\c CONNECT
This entry is for a Hayes 1200 Smartmodem, identified by the name hayes1200, with translations for the = and - characters, followed by the AT commands used to set up the modem. These entries are usually supplied in the Dialers file for most popular modems.
Permissions for file transfers are a little more convoluted with HDB UUCP than Taylor UUCP, as HDB UUCP adds many features for special handling. This section gives you the fundamentals you need to set up properly. For more detailed information, consult a specialty book on UUCP; the subject can easily consume 100 pages by itself!
The file /usr/lib/uucp/Permissions handles permissions for remote system access and file transfers. The general format of the entries in this file is
MACHINE=remotename LOGNAME=uucp \ COMMANDS=rmail:rnews:uucp \ READ=/usr/spool/uucppublic:/usr/tmp \ WRITE=/usr/spool/uucppublic:/usr/tmp \ SENDFILES=yes REQUEST=no
where MACHINE identifies the remote machine's name, LOGNAME is the name the users of the remote machine use to log in (or you use to log in to their system), COMMANDS are the commands they can execute on your local system, READ is the list of directories from which they can read files, WRITE is the list of directories where they can write files, SENDFILES means that they can send files (yes or no), and REQUEST means that they can request files from your system (yes or no). Notice the slashes at the end of the first four lines. These slashes are a typical UUCP convention to indicate that this code is a single long line broken up for readability.
A complete entry for the remote system wizard shows that it is allowed to both send and receive files, but only from the /usr/spool/uucppublic directory, and it can only execute mail and uucp commands (the later transfers files):
MACHINE=wizard LOGNAME=uucp1 \ COMMANDS=rmail: uucp \ READ=/usr/spool/uucppublic: \ WRITE=/usr/spool/uucppublic: \ SENDFILES=yes REQUEST=yes
To prevent the remote system from sending files, change SENDFILES to no. To prevent the remote system from requesting files, change REQUEST to no.
When UUCP connects to a remote machine, it follows a particular series of steps. You can better understand the configuration files UUCP uses and the processes that are involved by following through a typical session. UUCP uses uucico (UUCP Call In/Call Out) to handle the process of connecting and sending information. You can start a UUCP connection with the uucico command followed by the remote system name:
uucico -s arthur
When uucico starts, it examines the /usr/lib/uucp/sys file (Taylor UUCP) or the /usr/lib/uucp/Systems file (HDB UUCP) to see whether the remote system name exists there. When it finds the proper remote system name, uucico reads the rest of the entries for that system, including the port to be used. From there, uucico uses /usr/lib/uucp/port and /usr/lib/uucp/dial (Taylor UUCP) or /usr/lib/uucp/Devices and /usr/lib/uucp/Dialers (HDB UUCP) to start the modem connection (assuming it is a modem used to establish the session, of course). When the modem is in use, uucico creates a lock on it so that no other application can use it (the lock is a file starting with LCK.. and followed by the device name, such as LCK..cua0).
After the chat scripts for setting up and dialing the modem have been executed and the remote system is connected, uucico uses the chat script in the /usr/lib/uucp/sys file or the /usr/lib/uucp/Systems file to log in to the remote system. After the the local system is logged into the remote system, the remote machine starts up its copy of uucico, and the two uucico processes establish handshaking. After the handshaking has been established, uucico goes ahead and handles any transfers that are queued. When finished with the session, the local machine checks that the remote has nothing further to send, and then breaks the connection. Finally, uucico terminates.
If your two machines are directly connected(no modems involved in the connection), through a serial port for example, you can use UUCP as a simple network protocol for file transfer. The only changes to the configuration files mentioned earlier are in the port specification. Instead of using a modem device, you specify a direct connection. For example, in the /usr/lib/uucp/sys file (Taylor UUCP), you would have an entry like the following:
port direct1
A matching entry in the /usr/lib/uucp/port file would look like the following:
port direct1 type direct speed 38400 device /dev/cua1
These entries specify the the port that uses the direct connection and the speed of the connection. The entries in the HDB UUCP version are similar, using the /usr/lib/uucp/Systems and /usr/lib/uucp/Devices files.
The login scripts that form part of the /usr/lib/uucp/sys or /usr/lib/uucp/Systems file can be the most difficult part of a UUCP connection to get correct. If the machine you are logging into is a typical UNIX system, you usually only have to worry about the login and password prompts. Other systems may require some special handling to gain access. For this reason, the login script is worth a quick look.
Generally, the layout of the login script is in a pattern-action pair, with the pattern coming from the remote machine and the action from the local machine. The simple login scripts shown earlier serve as an example:
login: merlin password: secret1
In this case, the local system waits until it sees the string login: coming from the remote system, sends merlin, waits for password:, and then sends secret1. You can simplify the script a little by cutting out extra letters from the remote system, because all you really need are the last couple of characters and the colon. You could write the script as follows:
gin: merlin word: secret1
This type of script has a good use. If the remote system sends Login: instead of login:, the shortened script works and the longer script doesn't.
One useful feature of the uucicio login script is its capability to wait for the remote machine to reset itself (or start a getty process, more likely). To implement this feature, you use a hyphen and the word BREAK in the script to tell uucico to send a break sequence if the remote site doesn't respond in a timely manner. Look at the following sample script:
ogin:-BREAK-ogin: merlin sword: secret1
In this case, if the remote machine doesn't respond with a ogin: prompt after a short period of time, the local machine sends a break sequence and waits for the prompt again.
You can use a few special characters in the login script. The most important ones for most UUCP purposes are the following:
| \c | Suppress sending carriage return (send only) |
| \d | Delay one second (send only) |
| \p | Pause for a fraction of a second (send only) |
| \t | Send a tab (send and receive) |
| \r | Send a carriage return (send and receive) |
| \s | Send a space (send and receive) |
| \n | Send a newline (send and receive) |
| \\ | Send a backslash (send and receive) |
Sometimes you need to use one or more of the characters to get the remote machine to respond to a modem login. For example, the script
\n\r\p ogin: merlin word: secret1
sends a carriage return-line feed pair before starting to match characters. This action is usually enough to get the remote machine to start a getty on the port.
Both Taylor and HDB UUCP versions let you specify a time to call the remote systems. Although the previous examples show Any (meaning the system can be called at any time, day or night), you may want to restrict calls to certain times or to certain days of the week. The reason for limiting calls may be at your end (costs, for example) or at the remote (limited access times during the day, for example).
To specify particular days of the week to allow calls, use a two-character abbreviation of the day (Mo, Tu, We, Th, Fr, Sa, Su), Wk for weekdays (Monday through Friday), Any (for any time), or Never (for not allowed to connect). You can use any combination of the days. The times for connecting are specified as a range in 24-hour format when a time span is required. If no time is given, the systems assume that anytime during the day is allowed.
Dates and times are run together without spaces; commas separate subsequent entries. Examples of restricted access times are as follows:
Wk1800-0730 MoWeFi Wk2300-2400, SaSu
The first example allows connection only on weekdays between 6:00 PM and 7:30 AM. The second example allows connection any time on Monday, Wednesday, and Friday. The last example allows connections only between 11:00 PM and midnight on weekdays and any time on weekends. You can build up any time and date specifications you want. These guidelines apply to both Taylor and HDB UUCP versions.
The permissions of the UUCP configuration files must be properly set to enable UUCP to function properly, as well as to provide better security for the system. The files should all be owned by uucp, and uucp should be the group on most systems that have that group in the /etc/group file. You can set the ownerships either by making all the file changes explained previously while logged in as uucp or by setting the changes as root and then issuing the commands
chown uucp * chgrp uucp *
when you are in the /usr/lib/uucp directory. As a security precaution, set a strong password for the uucp login if one exists on your system. Some versions of Linux do not supply a password by default, leaving the system wide open for anyone who can type uucp at the login prompt!
Set the file permissions very tightly, preferably to read-write-execute only for the owner (uucp). Blank the group and other permissions— a read access can give valuable login information, as well as passwords, to someone. When UUCP logs into a remote system, it requires a password and login. The /usr/lib/uucp/sys and /usr/lib/uucp/Systems files contain this information. To protect them from unauthorized snooping, set file ownerships and permissions as mentioned.
If you have several systems connecting into yours, they can all use the same uucp login and password, or you can assign new logins and passwords as you need them. All you need to do is create a new /etc/passwd entry for each login (with a different login name from uucp, such as uucp1, uucp_arthur, and so on) and a unique password. The remote system can then use that login to access your system. When you create the new UUCP user in the /etc/passwd directory, force the user to use uucico only to prevent access to other areas of your system. For example, the following uucp1 login forces uucico as the startup command:
uucp1::100:1:UUCP Login for Arthur:/usr/spool/uucppublic:/usr/lib/uucp/uucico
The home directory is set to the uucppublic directory, and uucico is the only startup program that can be run. Using different logins for remote machines also allows you to grant different access permissions for each system, preventing unwanted access.
Carefully control the commands that remote systems can execute on your local machine through the permissions fields of the local access file. Monitor these fields carefully to prevent abuse and unauthorized access. In a similar manner, if you are allowing forwarding of files through your system, control who is allowed to forward files and where the files are forwarded to.
Most important of all is to ensure that whoever accesses your system on a regular basis is someone you want to have access. If you leave your system wide open for anyone to enter, you are inviting disaster. Carefully watch logins, and make sure file permissions and ownerships are properly set at all times.
Once you have configured UUCP, you can use it to transfer files and e-mail. In order to use UUCP, you have to know the addressing syntax, which is different from the Internet addressing syntax. The UUCP address syntax is
machine!target
where machine is the remote machine name and target is the name of the user or file that you are trying to get to. For example, to send mail to the user yvonne on machine arthur, you would use the mail command with a username destination:
mail arthur!yvonne
UUCP lets you move through several machines to get to a target. This feature can help save money on telephone bills or make a much wider network available to you from a small number of connections. Suppose you want to send mail to a user called bill on a system called warlock, which isn't in your configuration files but can be connected to through arthur. If you have permission to send mail through the system arthur (called a hop), you can send the mail with this command:
mail arthur!warlock!bill
When UUCP decodes this address, it reads the first system name (arthur) and sends it to that system. The UUCP processes on arthur then examine the rest of the address and realize that the mail is to be sent on to warlock. If you have permission to forward through arthur, UUCP on arthur sends the mail through to warlock for you. You can have many hops in an address, as long as each system you are connecting to allows the pass-through and can connect to the next machine on the list. For example, the address
arthur!warlock!chatton!vader!alex
sends data through arthur, warlock, chatton, and vader in order, and then to the user alex. You must specify the addresses in the proper hop order or the address will fail. This multihop addressing can be very useful if a number of friends have local connections to other machines, allowing you to easily set up a complex network. The hard part is usually tracking the names of the systems involved.
The exclamation mark in the address is called a bang, so the preceding address is spoken or written as "arthur-bang-warlock-bang-chatton-bang-vader-bang-alex." Shells like the C shell use the exclamation mark to recall previous commands, so you must escape the bang character with a slash to prevent the shell's interpretation. Addresses then become arthur\/!chatton\!yvonne. This looks funny, but you get used to it.
Depending on how you have your UUCP system set, it may call out to the other systems in an address whenever something is submitted to it, or if callout times are limited, the data may be spooled until a call is allowed. You have already seen how to set callout times in the /usr/lib/uucp/sys and /usr/lib/uucp/Systems files.
A quick caution about relying on UUCP for delivery of information. If the systems that are being used are not set to call immediately when something is queued, your data can take a long time to get to its destination. For example, if one of the hops in your address only calls the next machine in the address once a day, you may have a 24-hour delay in delivery. This delay can be exacerbated by each machine in the network.
Also, don't rely on the contents of your data sent through UUCP to be kept confidential. Once your data is on a remote system, any user with access privileges to the queue could snoop into your data. Ideally, the file permissions will prevent anyone but the superuser accessing the data, but not all systems keep tight security. If you must send sensitive data, encrypt it and let the recipient know the decryption key through another format (not in a mail message).
UUCP deals with all transfers as jobs, a term you'll encounter often when working with UUCP and its documentation. A job is a command that is to be executed on the remote system, a file that is to be transferred to or from the remote system, or any other task that you want performed between the two systems.
Because most utilities, like mail packages, understand the UUCP addresses, you don't have to worry about e-mail not reaching the proper destination. You usually don't have to make any changes at all to applications running under Linux to get them to understand the UUCP address format. In the last section, you saw how you can use the mail package with UUCP addresses.
You can use any of the usual mail command options to modify the behavior of the package. For example, to send the contents of the file data_1 to yvonne on system chatton through the system arthur and tag the mail with a subject heading, issue the command:
mail -s "Data file" arthur!chatton!yvonne < data_1
Most mail packages available for Linux, including X-based mailers, work perfectly well with UUCP addresses as well as the more common Internet addresses, but you may want to check before adopting a new mail package.
UUCP's most common use is to transfer files from one machine to another. To transfer files using UUCP, you use the uucp command. The syntax of this command is as follows:
uucp [options] source destination
The options supported by uucp vary a little depending on the version and type of UUCP implementation, but most versions support the following useful options:
The default behaviors are usually sufficient for most users, although you may want the mail options when you need confirmation of an action.
Both source and destination are the names of files or directories as appropriate, much like the cp command. However, when you are dealing with a remote system for the source or destination, you need to format the file or directory in valid UUCP address format. For example, to send the data_1 file from your local machine's current directory to the directory /usr/spool/uucppublic on the machine arthur, use the command:
uucp data_1 arthur!/usr/spool/uucppublic
Notice that the remote machine name was prepended to the full target directory name. In most cases, when transferring files to remote systems, you should use the uucppublic directories as you likely will not have permission to transfer files anywhere else in the filesystem. Once the file is on the remote system in the /usr/spool/uucppublic directory, it is up to the remote system's users to find the file and copy it to its intended destination directory.
If you want to send the same file to the user bill on the remote machine, store it in a subdirectory called /usr/spool/uucppublic/bill, and send mail to both yourself and bill when the copy is completed, issue the command:
uucp -m -nbill data_1 arthur!/usr/spool/uucppublic/bill/
To copy a file from a remote machine to yours, you need to specify the location of the remote machine. Remember you must have access to the directory that the files reside in (as well as read permission on the file) or have the sender copy them to uucppublic. The command
uucp chatton!/usr/tmp/bigfile /usr/tparker/
transfers the bigfile file from the directory /usr/tmp on the machine chatton to your /usr/tparker directory.
UUCP allows you to use wildcards, although you must escape them in quotation marks to prevent the shell misinterpreting them. For example, to copy all the files starting with chap on the remote machine warlock's /usr/bill/book directory (assuming you have permissions) to your own /usr/bigbook directory, issue the command:
uucp "warlock!/usr/bill/book/chap*" /usr/bigbook/
You can specify hops in the machine transfers by adding the extra machine names to the command. This task requires permissions to be set on all the machines that the hop will pass through and is seldom done. You can transfer files from one remote system to another by specifying their names on the command line, as in the following example:
uucp arthur!/usr/lib/uucppublic/bigfile warlock!/usr/lib/uucppublic/
This command sends the file from the arthur system to the warlock system. In most cases, the users on either of the two remote systems would issue the commands, relieving some of the file permission problems.
You can check on the status of transfers that are scheduled but haven't taken place yet by using the uustat command. When you issue the uustat command, all the UUCP transfers that are queued are listed. The format of the list is
jobID system user date command size
where jobID is the identification number of the UUCP job, system is the name of the system to transfer to (the first system in an address when multiple hops are taking place), user is the username who queued the job, date is when the job was queued, command is the exact command to be executed, and size is the size of the transfer in bytes.
If you issue the command as a user (not superuser), only your jobs are listed. The superuser lists all jobs that are queued. If you are logged in as a regular user and want to see all jobs, use the -a option:
uustat -a
To cancel a queued job, use the -k option of the uustat command along with the jobID. For example, to cancel jobID 17, issue the command:
uustat -k 17
You can only cancel your own jobs, unless you are logged in as superuser, in which case you can cancel any jobs.
UUCP is quite easy to set up as long as you follow the rules. Once the configuration files are properly set, UUCP can transfer e-mail, news, and files to other systems. Using UUCP to transfer mail and files is as easy as using the usual mail and cp commands. Although UUCP is less popular nowadays because of the LAN craze, it does provide a simple, very low cost network for those who need to connect only a couple of machines. It's also great for connecting your machine to your friends' machines, allowing e-mail back and forth, and making your Linux system seem like a well-connected workstation.
