Web based School
- 43 — UUCP Administration
43 — UUCP Administration
By James C. Armstrong, Jr.
Long before the days of Networking, TCP/IP, NFS, and the like, there was still the need for UNIX machines to communicate with each other, to pass data, and to transfer files. Modern networks make this task easy, but if your machine is not attached to
one of these networks, or if there is no direct network connection between your machine's network and the target machine's network, then there must be a technique for this communication. The package that handles these transfers is UUCP.
UUCP was originally written by Mike Lesk at Bell Labs in the mid-1970s, to facilitate communication between the growing network of UNIX machines. It has been modified several times since then, with the most fundamental changes occurring in 1983, when
UUCP was rewritten by Peter Honeyman, David A. Nowitz, and Brian E. Redman. This is the standard UUCP distributed with System V Release 4, and sometimes goes by the moniker HoneyDanBer. It is this version of UUCP that this chapter covers.
What Is UUCP?
UUCP is the package of commands that allows a user to transfer data from one machine to another across a serial port, usually via a modem. Probably the most common uses of UUCP are the transfer of network e-mail and netnews, as described in Chapter 41,
"Mail Administration", and Chapter 42 "News Administration". In both cases, the underlying UUCP commands are hidden from the regular user.
Transferring Files
The most likely contact a regular UNIX user has with UUCP is the command uucp. This is just an expansion of the cp command, with a special format to indicate the transfer to a new machine. The target machine and path are illustrated with an exclamation
point. Assume that I have a file named data on a local machine named duke. I want to transfer that file to my home directory, /usr/james, on a machine named unc. This is the command I'd use:
uucp data unc!/usr/james/data
I do not need to specify the machine I am on, so I indicate just the current file. I then indicate that I want to send the file to the machine unc, with the file name there as /usr/james/data. This is an example of pushing a file to a new machine via
uucp.
Files may also be pulled from machines. Suppose I have successfully copied data to unc, and now I need a copy back. I can do this with this command:
uucp unc!/usr/james/data .
In this case, the source file is on the unc machine, and I pull over a copy. If unc has the correct permissions, I can pull the needed file over to my machine and place it in my current directory.
Files can be transferred from one remote machine to another. In the first example, if I were on machine ncsu when I wanted to transfer a file from duke to unc, I could do it with this command:
uucp duke!/usr/james/data unc!/usr/james/data 2
The syntax of the command says "Go to machine duke and find the file /usr/james/data, then send it to machine unc to the destination /usr/james/data 2." Finally, if I want to send the file from duke to wake, but wake only has a link with unc,
I can specify a path like this:
uucp duke!/usr/james/data unc!wake!/usr/james/data
If the permissions at unc allow the transfer, the file is first sent to unc, then sent from unc to wake.
Running Remote Commands
UUCP also provides a command that allows the user to run commands remotely. The uux command enables a user to request that a remote machine run a command. It will accept redirection of standard input and output, and options can be used to indicate that
the redirection should apply to the remote command's execution. For example, this command will return the output of the date command as run on unc:
uux unc!date
uux is normally hidden from the user, but it is the backbone for mail and news transfer. On my machine, I transfer news to a remote machine by piping the article into the command uux - -r -gd netcomsv!rnews. While this may look complicated, all it
really says is that the standard input of this command will be fed to the remote machine netcomsv, and there the command rnews will be run. The -r option says to queue the request, and -gd sets a system priority on the request. Both options could easily be
omitted.
The command for transferring mail is even simpler. When my mailer gets the request to send mail to a remote system, it executes uux - -r netcomsv!rmail. This is simplicity itself—it just pipes the mail message to rmail on netcomsv.
Under It All
Beneath all the UUCP commands is the uucico command. This is the process that implements the actual communication between UNIX machines. Most users will never need to use this command, and its use by administrators is also rare.
uucico examines a series of data files to make its connection. These files include information such as which tty is used as a port, what modem commands are needed to use the attached modem, what is the phone number of the remote system, and what is the
login protocol. Attached to both the modem commands and the login commands are what is called a "chat script." These chat scripts are the essence of UUCP communications.
Chat Scripts
Chat scripts are simply pairs of expect/send sequences. When all the criteria are met for communications, the uucico process waits on the port until it sees the next expect sequence. After that sequence is seen, the next send sequence is sent down the
line. If the expect sequence is not seen in a certain period of time, a time-out occurs, and a different send sequence can be sent. If all expect/send sequences are completed, the connection starts to transfer data. If the send sequences are exhausted and
no connection is made, the command fails.
The following is an example of a chat script for logging in to a machine:
"" \n in:—in: mylogin word: mypassword
Interpreted, this means that I first expect nothing and send a carriage return. When I see the sequence in: I send the sequence mylogin. If I don't see in:, then I wait for a time-out and send a new carriage return and continue to look for in:. Once I
send mylogin, I wait for word:. Once I see that, I send mypassword and expect to start the data transfer.
The — in the expect sequence indicates that I might get a time-out and I might need to send more data. Any character sequence can be between the two dashes, and these are sent, along with a carriage return, and then a time-out occurs. Any number of
these time-out sequences can occur in an expect pattern. If a line is known to be slow to acknowledge the connection, one may see the sequence in:—in:—in:—in:, which means to try four times to get the login: prompt before timing out. Some
experimentation may be necessary to determine the exact chat script to connect to a machine. This is described in the section "Setting Up UUCP."
Connection Files
The first task of uucico is to determine the target machine for the connection. When it determines the machine name, it examines the Systems file. This includes the system name, the connect times, devices, and speeds, the connection address, and the
chat script to make the connection. This is not enough to make the connection.
Given the device type and speed, uucico must next examine the Devices file. This provides a list of devices and speeds, and associates them with actual ports and dialers to connect with those ports.
The dialers to connect to the port need to be looked up in the Dialers file, where a specific dialer can be associated with a chat script. That chat script should set up the modem in the proper format, and then dial the address provided by the Systems
file. Sometimes, this address may need further expanding. The Dialcodes file provides some expansion for the address.
Addresses need not be telephone numbers. UUCP is capable of handling telephone calls via modems, as well as connections via local area networks such as Starlan, and even direct connections between machines. Each one requires different devices and dialer
chat scripts to make the connection.
Setting Up UUCP
UUCP requires two sites willing to set up a connection. In the early days of UNIX, this was simply a matter of calling local UNIX sites and asking if they would be willing to transfer data for you. In those days, often the answer was yes, and you'd set
up a link. With the development of the Internet, these connections are becoming less frequent, and many main sites no longer even use UUCP.
For my home machine, I sought a service provider. The local provider with a decent reputation was Netcom, based in the San Francisco Bay area. Netcom offers a UUCP service for a reasonable amount each month, including registering a domain name for
Internet addressing. Netcom is not the only provider, but it's local for me.
When you've found a partner for exchanging UUCP, you'll need to determine how the connections will be made. There are three options: Your site could make all the calls to the provider's site (this is fairly standard with paid service providers), your
site could receive calls only from the remote site, or the calls could go both ways. This results in two different administrative tasks for UUCP: setting up your system to receive calls and setting up your system to place calls.
Receiving UUCP Calls
Since UUCP accesses a system in the same way as a user—by logging in—you'll need to set up your system to allow UUCP to log in. One of your serial ports will need a modem attached. One action you'll need to take is to establish an account for
UUCP to use. You'll need to use your administrative tools to edit the /etc/passwd file. You'll need root permissions to create the account. Some UNIX systems come with a default entry, nuucp, for UUCP connections. I prefer to set up a different account for
each machine, prefixing the machine name with a U. That way I know just by using the who command who is logging in to transfer data at what times.
The /etc/passwd entry should have the same owner and group as your uucp account. This way, the remote site will be able to write correctly to the designated files; UUCP does not run in any privileged mode—it is just another user on the system. You
should also make the home directory /var/spool/uucppublic. This directory is a standard UNIX directory, designated for file transfers. It should be owned by uucp, it should be of group uucp, and it should have permissions set to 777. That way, any user
desiring to transfer files can write to the directory.
The unique aspect of the /etc/passwd entry is the default shell. Most users will have something like /bin/sh, /bin/csh, or some other command shell. Your UUCP entry should have /usr/lib/uucp/uucico, which is the command for data transfer. This means
that when your UUCP successfully logs in, it will immediately start to transfer files.
You will also need to set a password for the UUCP account. To do this, you need to be root. Run the passwd command on the account and enter a password. After you have done this, you can notify the other site of its UUCP account and password.
This is not all that's needed to set up the connection, however. You'll need to run the command that gives the UNIX prompt, /etc/getty. This command is kept in the file /etc/inittab. You'll need to include an entry that looks like this:
ucp:23:respawn:/etc/getty ttya 9600
Each field is separated by colons, so this has four fields. The first is a unique identifier in the inittab and can be anything. The second field specifies run states, the third is an action, and the fourth is a command. This file is monitored by the
init daemon. The respawn action indicates that when a command is finished, a new getty command should be run. The run states indicate that the command should be run only in multiuser mode.
getty is the standard UNIX command for providing a login prompt. The two arguments indicate which port is used and the expected speed. Here the modem is on ttya and is 9600 baud. Your port and numbers may be different. For more details on the inittab
and getty, see the section "Boot States."
There is a problem with getty: It can only receive calls. If you intend for your modem to have two-way traffic, you'll need to use the uugetty command. This command will know not to put up a login prompt when you are using the port to make outgoing
calls. To use it, replace /etc/getty with /usr/lib/uucp/uugetty -r. The -r option tells uugetty not to put up a login prompt until it gets a character, which is usually a carriage return.
Permissions also need to be set, restricting what the calling system can do to your system. These will be covered later in the chapter, but for starters, consider restricting read and write access to /var/spool/uucppublic, and allow only the execution
of rmail, and if you want netnews, rnews.
Initiating UUCP Calls
Initiating UUCP connections is a proactive job. The simplest way to set up a system to make UUCP calls is for the administrator to modify a single file, the Systems file. This file contains the specific information needed to contact a remote system.
Each line is a separate entry, and each line must have six entries. The first entry on a line is the remote system's name. UUCP expects the first seven letters to be unique, so the system names newyorkcity and newyorkstate would be considered the same.
Each system can have any number of entries—they are tried in the order found in the file, until one is successful.
The second field is a schedule field. Normally, the word Any will be here, meaning that the connection can be made at any time. Never means don't call; this entry is usually made when a system is polled; this means that a remote system will call to get
what it wants. The schedule field Wk means weekdays only. A schedule field can be quite complicated. The schedule field can have an unlimited number of comma-separated schedule descriptions. Each description has a day code, an optional time code, and an
option grade code. The day codes are easy to understand—Su, Mo, Tu, We, Th, Fr, and Sa. Any number and combination can be present. So if you only want to call a site on Fridays, Saturdays, and Sundays, you'd have FrSaSu as the schedule field. The
start time can be after the end time, which would seem to include midnight, but that is not true. Instead, it means from midnight on the specified days to the end time, and the start time to midnight on the same day. So Wk1900-0700 means any weekday before
7 AM or after 7 PM.
Finally, the grade is a restriction on priority of transfers. By limiting the grade, only transfers of that grade or higher are made during that time. The grade is identified by a slash followed by a number or letter.
A full schedule specification may look like this:
SaSu,Wk0900-1700/C,Wk1700-0900
This means that transfers may occur at any time on Saturdays and Sundays, between 9 AM and 5 PM weekdays, only items grade C and above, and any time between 5 PM and 9 AM. This effectively says it's possible to transfer anything at any time except
during work hours, when you move only priority material.
Finally, if a comma and number follow the schedule, this sets a minimum retry time. UUCP will make retry attempts based on its own internal formula, but that formula can be overridden in the schedule field.
The third field is the device field. This field is a lot simpler than the schedule field. It consists of a pointer to a device type. The devices are kept in the file Devices, usually in the same directory as Systems. UUCP will look up the device name in
the Devices file and use the first free device found. The only option is that protocols may be specified after the device, preceded by a comma. Supported protocols include UUCP's g protocol for communication on a telephone line, as well as an x and an e
protocol for devices that support those protocols.
The fourth field is the speed, or baud rate, of the connection. This is usually your modem's top speed, but different values may be present for different numbers, and different speeds also apply for direct connections.
The fifth field is the connection number. Usually it is a telephone number, but for UUCP connections over direct lines or for data switches, it is a connection address or path. For telephone numbers, it is the sequence of numbers needed to dial the
remote modem. Note that an optional alphanumeric string can precede the phone number (this will be interpreted in the Dialcodes file).
The last field is the chat script. These are a sequence of text patterns that are expect/send pairs. The uucp command will read the data coming in from the remote site and attempt to match the expected text with the incoming text. When a match is found,
the send text is transmitted with a new line, and a new expect pattern is found, until the entire chat script is completed. If successfully completed, the UUCP process starts; otherwise, an error is recorded and the connection is terminated.
Chat scripts can be filled with special character escapes. Table 43.1 shows Chat script escape sequences.
Escape Sequence |
Meaning |
|
"" |
Expect a null string |
|
EOT |
End of transmission |
|
BREAK |
Cause a break signal |
|
\b |
Backspace |
|
\c |
Suppress a new line at the end of the send string |
|
\d |
Delay for one second |
|
\K |
Insert a Break |
|
\n |
Send a new line |
|
\N |
Send a null |
|
\p |
Pause for a fraction of a second |
|
\r |
Carriage return |
|
\s |
Send a space |
|
\t |
Send a tab |
|
\\ |
Send a backslash |
|
\xxx |
Send the ASCII character with the octal value xxx |
A complete sample of Systems file entries is included here. Note that the sensitive data is changed, but reflects accurately my Systems file on sagarmatha.com:
machine1 Any ACU 9600 9899685 in:—in: uduke word: mypass mach Never ACU 9600 9895690 in:—in: jca tyler Any ACU 9600 5565935 "" \K\d\r :—: mygate "" \d\d >-\r->\
mylog > rlogin\styler in:—in: uduke word: Strange1
I have three machines registered. All are within my local area code. I have set the machine to never call mach. Instead, I use that as an entry for the cu command. Also note that both machine1 and tyler have given me the UUCP account name uduke.
The machine tyler is an interesting case. I have to go through a switch to reach that machine. The first expect says that I don't expect anything, so the machine immediately sends the control characters \K\d\r. This means send a break, wait a second,
and send a carriage return. UUCP then expects a colon, and to access this switch, I enter mygate. I then need to wait two seconds, with \d\d, to get the > character. I send mylog. I expect another >, and I send rlogin tyler. Here, I begin a more
recognizable login session.
Currently, the Internet has fully qualified domains, which separate our machines and networks. These domains are registered to prevent conflicts. My home machine is registered in the domain sagarmatha.com, but its UUCP name is duke. Because my service provider does not connect to Duke University or anyone else by this name, there is no name conflict.
Interestingly, this is not the hostname. My UUCP machine at home has a hostname of krzyzewski, after Duke University's head basketball coach. Other machines at home have names of assistant coaches, amaker, gaudet, and brey. Because of the seven-character restriction on the UUCP name, I opted for duke, rather than abbreviating the hostname.
Testing the Connection
Once the Systems file is complete, you have to test the entry to see if the connection is actually being made, and if not, you need to figure out what is wrong. For this you use the command Uutry.
Uutry is a shell script that calls uucico with a debugging flag set, and then performs a tail on the output. You can press the Delete key any time to terminate Uutry. The default debug level is 5, but this can be changed with the -x option.
The example in Listing 43.2 shows what happens when the password is incorrect.
$ /usr/lib/uucp/Uutry machine1
/usr/lib/uucp/uucico -r1 -smachine1 -x5 >/tmp/machine1 2>&1&
tmp=/tmp/machine1
mchFind called (machine1)
conn(machine1)
Device Type ACU wanted
mlock ttya succeeded
processdev: calling setdevcfg(uucico, ACU)
gdial(tb9600) called
expect: ("")
got it
sendthem (????????)
expect: (OK)
AT^M^M^JOKgot it
sendthem (DELAY
????????PAUSE
????????PAUSE
????????PAUSE
<NO CR>????????)
expect: (OK^M)
^M^JAAATE1V1X1Q0S2=255S12=255S50=6S58=2S68=2S7=80^M^M^JOK^Mgot it
sendthem (ECHO CHECK ON
<NO CR>?????????????????????????)
expect: (CONNECT 9600)
^M^JCONNECT 9600got it
getto ret 6
expect: (in:)
^M^Jsendthem (????????)
expect: (in:)
^M^Jmachine1 login:got it
sendthem (????????)
expect: (word:)
uduke^M^JPassword:got it
sendthem (????????)
LOGIN FAILED - failed
exit code 101
Conversation Complete: Status FAILED
You can only see what is echoed back to you—your commands that are not echoed, such as your password, are not visible. By correcting the password in the Systems file and rerunning Uutry, you get the output in Listing 43.2.
$ /usr/lib/uucp/Uutry machine1
mchFind called (machine1)
conn(machine1)
Device Type ACU wanted
mlock ttya succeeded
processdev: calling setdevcfg(uucico, ACU)
gdial(tb9600) called
expect: ("")
got it
sendthem (????????)
expect: (OK)
AT^M^M^JOKgot it
sendthem (DELAY
????????PAUSE
????????PAUSE
????????PAUSE
<NO CR>????????)
expect: (OK^M)
^M^JAAATE1V1X1Q0S2=255S12=255S50=6S58=2S68=2S7=80^M^M^JOK^Mgot it
sendthem (ECHO CHECK ON
<NO CR>?????????????????????????)
expect: (CONNECT 9600)
^M^JCONNECT 9600got it
getto ret 6
expect: (in:)
^M^J^M^Jmachine1 login:got it
sendthem (????????)
expect: (word:)
uduke^M^JPassword:got it
sendthem (????????)
Login Successful: System=machine1
msg-ROK
Rmtname machine1, Role MASTER, Ifn - 6, Loginuser - james
rmesg - 'P' got Pgetxf
wmesg 'U'g
Proto started g
*** TOP *** - role=1, setline - X
Request: duke!D.dukeb2ee40e —> machine1!D.dukeb2ee40e (james)
wrktype - S
wmesg 'S' D.dukeb2ee40e D.dukeb2ee40e james - D.dukeb2ee40e 0666 james
rmesg - 'S' got SY
PROCESS: msg - SY
SNDFILE:
-> 835 / 0.972 secs, 859 bytes/sec
rmesg - 'C' got CY
PROCESS: msg - CY
RQSTCMPT:
mailopt 0, statfopt 0
Another debugging tool is cu. This command also uses the UUCP files to try to connect to the remote machine, but when you are connected to the remote machine, cu terminates and you must complete the login yourself. This is very useful for debugging
telephone numbers and Dialer scripts. Also, by using cu to connect to the modem itself, you can alter the modem parameters that may have been set incorrectly.
Another debugging tool is uucico. By calling uucico with the option -x and a single number, you will get output showing the steps for the UUCP call. This, however, cannot be interrupted, so you should use it sparingly.
More on Chat Scripts
Chat scripts are the heart of UUCP communication. The concept of a chat script is phenomenally simple—read a port until you match a string, then send a response. It is found in two UUCP-related files, the Systems file and the Dialers file. The
concept is rather portable, although it could have supported regular expressions for pattern matching.
Any number of expect/send pairs could be present. When attempting to navigate UUCP through a network of data switches to reach a destination, you may need a large number of pairs before you reach the login prompt.
The longer the chat script, the greater the chance that an error may occur. Normally, an error in the chat will result in the call failing; however, there are some error correction techniques. The uucico command will take a time-out after 30 seconds if
an expected pattern is not seen. At that time, an alternate send sequence can be issued, and a new pattern expected. This alternate send is enclosed in dashes, with the new expect pattern following the second dash. There can be no spaces in this pattern,
or UUCP will see it as a new member of an expect/send pair.
Often, this is seen with the login prompt and looks like this:
in:—in:
This pattern means, wait for in:, and if it is not found, send a carriage return and wait again for in:. (Remember that each send pattern is followed by a carriage return, even if it is an alternate send.)
Another frequent alternate sequence is \K. Sometimes, when calling a modem that operates at multiple speeds, sending a break down the line will allow the modem to change its speed to match yours. When you see a sequence like this:
in:-\K-in:—in:-\K-in:
there are four separate instances of an expected login prompt. If not found the first time, send a break, then a carriage return, then another break. Although this may look excessive, it is sometimes necessary.
Administering the Files
Besides the files already mentioned, there are six important UUCP files that need regular administration. They are the Devices, Dialers, Dialcodes, Permissions, Sysfiles, and Poll files. Each has its own format and usage.
Devices
The Devices file is just a list of the devices found on the system, with an identification of their use. The purpose of this file is to tie the device specification in the Systems file to a physical device with a known means of access. Each entry in the
Devices file is a single line long, must start in the first column, and has five fields. The file permits comments, identified by the # character in the first column. It ignores lines with no entry in that column.
The first field is the device type. It must match exactly the device specified in the Systems file. Devices will be tried in order down the file until one is found to be available. This way, a system with multiple modems can have one entry in the
Systems file. Some devices have standard identifiers. An ACU is an "automated call unit," better known as a modem. direct signifies that the link to the device is a direct link.
The second field is the data port. This is the filename of the special file in the /dev directory that matches the physical device, and will be the port through which the data communication is made.
The third field is the dialer port. This is a bit of an anachronism, but in the past, some modems required a separate dialer device to make the phone call. This was the special file that pointed to the dialer for that modem. If the modem is capable of
dialing, this field is marked with a dash.
The fourth field is the speed of the device. This is also used for matching the Systems file. That way a site can indicate multiple speeds for connections through multiple devices.
The last field is the dialer token pairs. This specifies a specific dialer pattern, found in the Dialers file, and any arguments passed thereto. Normally, only a single pair (or single entry, if it gets no arguments) is found; however, if the system
needs to go through a switch to reach the modem, a chat script may be expected.
My Devices file is rather small, and it looks like this:
ACU ttya - 9600 tb9600 Direct ttya - 9600 direct
I have only the single modem, a Telebit QBlazer at 9600 baud. It is attached to /dev/ttya and uses the tb9600 dialer script when I connect via UUCP. It is configured to allow me to use cu to talk to the modem.
Dialers
The Dialers file is used to initiate conversation with the modem. It ties the dialer specified in the Devices file to a chat script. It consists of three fields. The first is the name of the dialer script. This must match exactly with the dialer
specified in the Devices file. Like with devices, all dialers are one line and are started in the first column. The #, or white space, in the first column indicates a comment.
The second field is a translation table for older communication devices.
The third field is the chat script needed to talk with the modem and to place the call. My machine came with several dialers already installed, including dialers for penril, ventel, micom, hayes, and telebit modems. I looked over my set of telebit
dialers, listed below, and selected tbfast for my first dialer for my ACU.
tb1200 =W-, "" \dA\pA\pA\pTE1V1X1Q0S2=255S12=255S50=2\r\c\
OK\r \EATDT\T\r\c CONNECT\s1200 tb2400 =W-, "" \dA\pA\pA\pTE1V1X1Q0S2=255S12=255S50=3\r\c\
OK\r \EATDT\T\r\c CONNECT\s2400 tbfast =W-, "" \dA\pA\pA\pTE1V1X1Q0S2=255S12=255S50=255\r\c\
OK\r \EATDT\T\r\c CONNECT\sFAST
I knew I wasn't connecting at 1200 or 2400 baud, so it seemed that the fast connection was the way to go. I quickly learned that this was wrong! By using cu to mimic the dialing of the UUCP number, I saw that the final message was not CONNECT FAST, but
CONNECT 9600. I first considered altering tbfast, but instead opted to write my own dialer, tb9600, in case I need to make other changes.
Note that each of these dialers has a long, confusing list of numbers and characters as the first send sequence. These are the parameters that need to be set in the modem for the UUCP call to take place, in a language the modem understands. Although the
hayes modem syntax is fairly common, some modems do not use it, so you'll need to check your modem's documentation to determine the correct settings.
In my efforts, I found that by sending just the string to the modem, I'd get an error, because I didn't yet have the modem's attention. To get its attention, I'd need to send AT to the modem and receive back OK. I placed this at the beginning of my chat
script. Testing also revealed that the best modem settings were different from those above, so I added them to the chat script, as well. It ended up looking like this:
tb9600 =W-, "" AT OK-AT-OK \dA\pA\pA\pTE1V1X1Q0S2=255S12=255S50=6S58=2S68=2S7=80\r\c\
OK\r \EATDT\T\r\c CONNECT\s9600-\c-CONNECT\s9600
Basically, I am setting modem registers to match what I need. I also wait for CONNECT 9600 a bit longer than the time-out, so if I don't get it, I just sit a little while longer. This is the dialer I use for my UUCP connections.
Dialcodes
The Dialcodes file is an optional file that equates some string with a series of numbers to be dialed. Although UUCP is perfectly happy to have a sequence such as 1028801144716194550,,2354 to reach a distant computer in the city of London, for a human
being glancing at the file it may not be obvious. So Dialcodes permits the human to tie a string, innerlondon, to a dialing sequence 102880114471.
Because I have only one number, I don't use a Dialcodes file, but if you call many places nationwide, it might be useful.
Permissions
System security is one of the most pressing issues in the computer industry, and in UUCP it is no exception. Originally, UUCP allowed any user to write to any directory on the remote system, as long as the user ID for UUCP had write permissions.
Similarly, reading files was also possible. This had the ugly effect of enabling users to steal remote password files with a simple UUCP command, and if any accounts weren't protected with passwords, those systems were definitely compromised. Similarly,
with incorrect permissions, a remote user could do significant damage by moving or destroying important files.
The way around this problem is to use the Permissions file. This mechanism ties remote systems and accounts to specific read, write, and execute permissions. There are 13 different Permissions file entries, each with the format Option=Value. They must
all be on the same line, although these lines may be broken with a backslash. Multiple values for an option are separated by colons. The 13 options are LOGNAME, MACHINE, REQUEST, SENDFILES, READ, WRITE, NOREAD, NOWRITE, CALLBACK, COMMANDS, VALIDATE,
MYNAME, and PUBDIR.
The meaning of each option are described below.
LOGNAME refers to a specific login name used by the remote site to gain access. By specifying the LOGNAME, you can tie various options to the login call.
MACHINE refers to the machine name of the remote UUCP site. Specific permissions can be tied to a LOGNAME or to a MACHINE.
REQUEST is a yes/no flag indicating whether a remote machine can request files from your machine. The default is no. By permitting a remote system to request files, a command such as uucp mymach!myfile anotherfile can be executed from a remote machine.
On a trusted network, that may be fine, but it is an invitation to trouble if set up on a link where you don't always know who is on the other end.
SENDFILES is another yes/no flag, but it is only tied to the LOGNAME. If set to yes, your system will send files to the remote system even if the remote system initiates the call. If you set the value to no, you will never send out files, and if you set
it to call, you will send out files only when you have initiated the call.
READ specifies the directories from which uucico can access files for transfer. The default is /var/spool/ucppublic.
WRITE specifies the directories to which uucico may write files. Again, the default is /var/spool/uucppublic. These two options are designed to keep harm from uucp restricted to a public file system.
NOREAD and NOWRITE are exceptions to the other directories. For example, on a trusted network, you may want to set your directory open to reading, by setting READ=/home/james. However, you might have your own private directory that you don't want anyone
to touch. To set this, you can have the options read READ=/home/james NOREAD=/home/james/.Private.
CALLBACK is another yes/no option. When set to yes, your system must call the remote system back before any transactions may take place. The default value is no. Be particularly careful using this option, because if both machines set CALLBACK to yes,
they will never communicate. Also, if one system sets SENDFILES to call, and the other has CALLBACK as yes, the first system will never transfer files to the second. CALLBACK is definitely a security feature, because a remote site could always fake a
machine name and steal a password, so by calling back you know with whom you are talking. It is also useful if one site has a particularly cheaper phone rate than the other.
COMMANDS is a very important option. The default is usually to permit rmail and rnews, the programs to receive mail and netnews. If set to ALL, any command that can be found in the local path of uuxqt will be executed. Because this often includes
commands such as cat and rm, this is usually not recommended. The COMMANDS option is tied to a MACHINE name calling in.
VALIDATE is an option tied to the LOGNAME, and if set to yes, will validate the calling system's identity.
MYNAME is an option to provide another system name for the local name. This is useful if you need an alternate UUCP name.
PUBDIR is an option to specify a directory to be treated as the public directory for reading and writing. The default is /var/spool/uucppublic.
Although this may seem complicated, the default permissions are designed to keep a system secure, and it is only when you want to loosen permissions that you need to edit the Permissions file.
My Permissions file is rather simple, with a single entry:
MACHINE=netcomsv COMMANDS=rmail:rnews SENDFILES=yes
It enables the machine netcomsv to execute rmail and rnews, and it enables me to send files to them.
Sysfiles
Sysfiles is a special addition that allows the system to specify different Systems files for different services. It also allows for multiple Systems, Devices, and Dialers files, should these become long.
The format is simple. There are four keywords: service, systems, devices, and dialers. The format is always keyword=value. The service keywords can be uucico or cu, the two commands that access the UUCP files. The other three are files that replace the
Systems, Devices, and Dialers files for that service. Each field is separated by a colon.
Poll
The Poll file is a list of times to poll a remote system. It is accessed by an administrative daemon to establish a fake request and force a UUCP call at a specific time. Its format is a system name followed by a tab, and a space-separated list of
integers from 0 to 23, representing the hours of a 24-hour clock.
Supporting Files
UUCP creates many different files and file types. Briefly, they are work files, data files, status files, lock files, log files, and temporary files.
Work files are located in /var/spool/uucp/machine name, and are prefixed with the letter C. They are the workhorse for UUCP, because they list the specific files to be transferred, including the local and remote names, permissions, and owner. A
request to send remote mail may look like this:
S D.dukeb3ae48e D.dukeb3ae48e james - D.dukeb3ae48e 0666 james S D.netco0c7f621 X.dukeNb3ae james - D.netco0c7f621 0666 james
This indicates that two files are to be transferred.
The data files are kept in the same directory, but are prefixed with D. Even the files that specify remote execution are prefixed with D. In this request are two data files being transferred, one to become a data file on the remote machine, the other to
become an execute file.
Execute files are identified by the prefix X. This prefix is sought by uuxqt, which is the program that actually runs the requested commands. These have their own format, indicating the command to be run and the input file to use.
Status files are kept in /var/spool/uucp/.Status, and have a specific format. There is a single status file per system, with six fields. The first is a type field, the second is a count field (used to indicate the number of retries, for example). The
third field is a UNIX time to identify the last connection attempt. The fourth is the number of seconds before a retry attempt may be taken, the fifth is ASCII text to describe the status, and the sixth is the machine name. Status files are usually
accessed by the uustat command.
Lock files are created when a call is attempted, and the lock files are in /var/spool/locks. These files contain the process ID of the uucico request that has locked the system.
Log files are kept in /var/spool/uucp/.Log. They are cleaned out daily by a daemon to prevent them from growing beyond control. Separate logs are kept for the uucico, uucp, uux, and uuxqt commands, each in a file named for the remote system. These are
often accessed with the uulog command.
Finally, temporary files may be created by UUCP. These are in the directory with the work files and are prefixed with TM.
UUCP Daemons
There are four UUCP daemons that should be invoked on a regular basis. They are the admin daemon, the cleanup daemon, the polling daemon, and the hourly daemon. These are all started out of cron.
The admin Daemon
The admin daemon is a daemon that should be invoked at least once a day. It will give, by e-mail, a brief image of the state of UUCP, including a snapshot of the running processes and a listing of the job queue. It will also check the log files to see
if there have been any attempts to transfer the passwd file.
The cleanup Daemon
The cleanup daemon is one of the hardest workers. It should be invoked daily, at a time when few users are likely to be on the system. It will back up all the log files and save them for three days. It will then make the current log files zero length.
Other administrative files not discussed here are also backed up.
The cleanup daemon will invoke the uucleanup command. This command removes old jobs from the queue, based on a command line argument. On my system, I have stuck with the defaults, seven days until a delete, and one day until a warning.
The daemon then removes old files, empty subdirectories, and core files. When it finishes this, it sends e-mail to the UUCP administrator announcing what it has done.
The polling Daemon
This daemon quickly examines the Poll file to create polling requests for uucico. This is essentially touching a file in the spool directory. It should be executed hourly.
The hourly Daemon
The hourly demon should be invoked each hour. It just runs the uusched command, which examines the spool to find any queued jobs, and if it finds jobs, it runs uucico for that system. When it finishes, it runs uuxqt to execute any incoming jobs.
Using UUCP
Earlier in this chapter you were introduced to the commands uucp and uux, which are two of the most common commands for UUCP. There are two alternate commands, uuto and uupick, which ease the process.
The uucp command is the basic command for the transportation of files from one machine to another. The basic form allows for the specification of two paths to files, one being the original file, the other being the destination. uucp can take a number of
arguments to help facilitate the transfer. By default, uucp will use the source file for originating the transfer. This means that if the source file is changed before the transfer is completed, the changed file will be sent. If that is not desired, the
file can be copied to a temporary file for uucp, which is done by specifying the -C option. By default, uucp will also create the necessary destination directories, if it has permission to do so. This is the -d option and is turned off by -f. uucp also
will assign a job ID to the transfer with the -j option. The -m option can be used to let the sender know when the job is complete (uucp will send a mail message to the requestor). The -g option enables the user to set the transfer grade (a single
character from 0 to 9, A to Z, or a to z. 0 is highest, and z is lowest).
Similar to the -m option, the -n option followed by a user name will notify the user at the remote machine when the transfer is complete. Debugging information can be found with -x. To prevent an immediate start of uucico, use -r.
So if I want to copy a file, data, but might change it later, and I am not worried about speed, I might try this:
uucp -r -C -gz data remote!data
If I also want to know when it is done and want to send mail to my friend Joe at the remote machine, I'd expand it to this:
uucp -r -C -gz -m -njoe data remote!data
That's an ugly command, to say the least!
uux is another command frequently used to execute remote programs. Most remote sites restrict this command, but imagine that you are on a very friendly network. At minimum, you need a command string, which is just a machine name followed by an
exclamation point and a command. The command is the same as a command typed on the system in the uucppublic directory. At minimum, you need this:
uux remote!date
That will run the date command on the remote system. Standard output is sent back to you. Assume that you want to put a message on your friend Joe's screen. If you were on the system, you'd use the command write joe and type something in. What you've
typed in is standard input, but you can't type on Joe's machine. uux will accept standard input on your screen, if we include the - on the command line. So you'd type this:
uux - remote!write joe
Then you'd enter your message. Note that you don't need to quote the command because anything after the command is considered an argument.
uux also takes some other arguments. The -b option tells uux to return the standard input if the remote execution failed. Files may be copied to the spool with -C, and -j controls the ID string. The -n option tells uux not to return any indication of
success or failure by mail. By default, uux will send mail to the originator, letting that person know whether the command worked. Standard input can also be used with -p, and -r doesn't immediately start uucico. The grade can be set with -g, and -x
controls debugging. The originator name can be altered with -a.
uuto and uupick
These commands are complicated and can baffle the novice user. Fortunately, UNIX provides two friendlier commands, uuto and uupick, for transferring files. These two commands work together. The syntax for uuto is simple:
uuto file file file machine!user
Any number of files can be listed on the line—they'll all be transferred to the remote machine using uucp. Note that a user on the remote machine must be specified. This way, the file is placed in a directory on the remote machine identified by the
user's name. Only two arguments are accepted for uuto: -m says to send mail to the originator when the transfer is complete, and -p says to copy the file to the spool before transmission. In the case of transferring a file to my friend Joe, I'd set up this
command:
uuto -m file1 remote!joe
This is all I need to do. The uuto command will convert it to this:
uucp -d -m -njoe file1 remote!~/receive/joe/duke
The remote machine will then have a directory hierarchy for my friend Joe, under the receive directory, and with a subdirectory duke. A short time later, I'll get some e-mail that says (SYSTEM remote) copy succeeded and I will find a reference to the
file in the header.
On the other machine, Joe will also receive some e-mail, saying /usr/spool/uucppublic/receive/james/duke/file1 from duke!james arrived, which lets him know that he has a file in the uucppublic directory.
Getting that file is easy using uupick. This is another shell script that searches the public directory for files under your name in a receive directory. If it finds any files, it prompts you for what you want to do. The actions are fairly
straightforward:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
So if you enter uupick, Joe will be prompted with this:
from system duke: file file1 ?
If he types m, the file is placed in his current directory, and the transfer is complete.
UUCP Utilities
There are two notable UUCP utilities available to the user. One examines log files, the other provides transfer status information.
UUCP keeps some very detailed log files in /var/spool/uucp/.Log. The uulog command is designed to access the two busiest of those logs. It always takes a system name as an argument. By default, or with the -s flag, it will display the transfer
information for a given system. Here is a sample:
uucp remote (5/14-19:18:42,9604,0) CONN FAILED (CALLER SCRIPT FAILED) uucp remote (5/14-19:48:40,9792,0) SUCCEEDED (call to remote ) uucp remote (5/14-19:48:43,9792,0) OK (startup) uucp remote (5/14-19:48:44,9792,0) REMOTE REQUESTED (remote!D.netco56c3c71\
—> duke!D.netco56c3c71 (netnews)) uucp remote (5/14-19:48:55,9792,1) REMOTE REQUESTED (remote!D.duke4f4de04\
—> duke!X.netcomsd56c3 (netnews)) uucp remote (5/14-19:48:57,9792,2) REMOTE REQUESTED (remote!D.netcobeb02bd\
—> duke!D.netcobeb02bd (netnews)) uucp remote (5/14-19:49:14,9792,3) REMOTE REQUESTED (remote!D.duke4f4e043\
—> duke!X.netcomsdbeb0 (netnews)) uucp remote (5/14-19:49:17,9792,4) OK (conversation complete ttya 136) uucp remote (5/14-20:18:41,9972,0) FAILED (LOGIN FAILED) uucp remote (5/14-20:18:41,9972,0) CONN FAILED (CALLER SCRIPT FAILED)
From this log you can see that a connection failed at 7:18 PM, succeeded at 7:48, and failed again at 8:18. Normally this file would be fairly long, but I used the -N option to cut it to the last 10 lines of the file. If I wanted to wait on the file, I
could have used -f. This is the same flag as for tail.
The only other option is -x. It gives details of the commands executed on the local system from UUCP. An example of the output (again, truncated to just the last 10 lines) is this:
uucp remote duked4f46 (5/14-17:32:37,9158,0) remote!remote!uucp-bounce XQT\
(PATH=/bin:/usr/bin USER=uucp UU_MACHINE=remote UU_USER=remote!uucp-bounce\
export UU_MACHINE UU_USER PATH; rnews ) uucp remote duked4f43 (5/14-17:32:38,9158,0) remote!remote!uucp-bounce XQT\
(PATH=/bin:/usr/bin USER=uucp UU_MACHINE=remote UU_USER=remote!uucp-bounce\
export UU_MACHINE UU_USER PATH; rnews ) uucp remote duked4f47 (5/14-17:52:08,9225,0) remote!remote!uucp-bounce XQT\
(PATH=/bin:/usr/bin USER=uucp UU_MACHINE=remote UU_USER=remote!uucp-bounce\
export UU_MACHINE UU_USER PATH; rnews ) uucp remote duked4f48 (5/14-18:32:49,9287,0) remote!remote!uucp-bounce XQT\
(PATH=/bin:/usr/bin USER=uucp UU_MACHINE=remote UU_USER=remote!uucp-bounce\
export UU_MACHINE UU_USER PATH; rnews ) uucp remote duked4f49 (5/14-18:32:50,9287,0) remote!remote!uucp-bounce XQT\
(PATH=/bin:/usr/bin USER=uucp UU_MACHINE=remote UU_USER=remote!uucp-bounce\
export UU_MACHINE UU_USER PATH; rnews ) uucp remote duked4f4a (5/14-18:32:51,9287,0) remote!remote!uucp-bounce XQT\
(PATH=/bin:/usr/bin USER=uucp UU_MACHINE=remote UU_USER=remote!uucp-bounce\
export UU_MACHINE UU_USER PATH; rnews ) uucp remote duked4f4b (5/14-18:32:52,9287,0) remote!remote!uucp-bounce XQT\
(PATH=/bin:/usr/bin USER=uucp UU_MACHINE=remote UU_USER=remote!uucp-bounce\
export UU_MACHINE UU_USER PATH; rnews ) uucp remote duked4f4c (5/14-18:32:53,9287,0) remote!remote!uucp-bounce XQT\
(PATH=/bin:/usr/bin USER=uucp UU_MACHINE=remote UU_USER=remote!uucp-bounce\
export UU_MACHINE UU_USER PATH; rnews ) uucp remote duked4f4d (5/14-19:49:19,9793,0) remote!remote!uucp-bounce XQT\
(PATH=/bin:/usr/bin USER=uucp UU_MACHINE=remote UU_USER=remote!uucp-bounce\
export UU_MACHINE UU_USER PATH; rnews ) uucp remote duked4f4e (5/14-19:49:20,9793,0) remote!remote!uucp-bounce XQT\
(PATH=/bin:/usr/bin USER=uucp UU_MACHINE=remote UU_USER=remote!uucp-bounce\
export UU_MACHINE UU_USER PATH; rnews )
Every command executed has been rnews, for transmission of netnews. To examine the other two files, my uux requests on a remote system, and my uucp requests to a remote system, I'd need to examine the files using an editor or other UNIX tools.
The other notable command is the uustat command. It has a lot of power, including the ability to delete jobs. There are several options.
The command uustat -a will give a listing of all jobs currently in the queue. Here is a sample:
netcomsn0000 05/14-20:45:00 (POLL) remoteNb1ae 05/14-19:53 S remote james 48871\
/home/james/Docs/Sams/Uucp/file1
This indicates that a poll request is in for netcom, and a file transfer request for remote.
To check the accessibility of machines, use uustat -m. It will give a listing such as this:
netcomsv 05/14-20:18 CALLER SCRIPT FAILED remote 05/14-20:20 LOGIN FAILED Count: 2
This indicates that there are presently problems reaching both machines. The command uustat -p will perform a ps command for every PID found in a lock file. uustat -q will give a listing of the state of the queue for each machine. It is similar to
uustat -m, but it also includes a count of outstanding jobs.
Detailed job information, similar to that obtained with uustat -a, can be found for a given system or a given user with uustat -ssystem or uustat -uuser. Finally, a user may kill a job or rejuvenate a job. The uustat -a command will give a
job ID in the first field. By specifying that job with a -k option, it will be removed from the queue. By using the -r option, it will be touched, and spared from any administrative daemons.
With these two commands, a user can determine the status of jobs already sent but not yet complete.
Summary
This chapter has provided a brief overview of the use and administration for UUCP. The uucp, uux, uuto, and uupick commands are used for data and command transfers. The uustat and uulog commands are used to check on the status and actions of UUCP.
Different files are used to administer the UUCP system, with the power to restrict types of access and facilitate data transfers.
Popular Tutorials
-
MS Access
1109
-
C++
1222
-
HTML
584
-
JavaScript
616
-
Vbscript
873
-
Oracle
473
-
VC++
875
-
SQL
2959
-
XML
514
-
Java
814
-
Perl
455
-
Linux
451
