Adding UUCP Logins

For incoming UUCP (uucico) requests from remote machines to be handled properly, each machine has to have a login on your system.

Here is a typical entry that you might put into the /etc/passwd file for a remote machine permitted to access your system with a UUCP connection.:

Ugobi:*:5:5:gobi:/var/spool/uucppublic:/usr/lib/uucp/uucico

By convention, the login name of a remote machine is the machine name preceded by the letter U. Note that the name should not exceed eight characters, so that in some cases you may have to truncate or abbreviate it.

The previous entry shows that a login request by Ugobi is answered by /usr/lib/uucp/uucico. The home directory is /var/spool/uucppublic. The password is obtained from the /etc/shadow file. You must coordinate the password and the login name with the UUCP administrator of the remote machine. The remote administrator must then add an appropriate entry, with login name and unencrypted password, in the remote machine's Systems file.

Similarly, you must coordinate your machine's name and password with the UUCP administrators of all machines that you want to reach through UUCP.

Starting UUCP

UUCP comes with four shell scripts that poll remote machines, reschedule transmissions, and clean up old log files and unsuccessful transmissions. The scripts are:

• uudemon.poll
• uudemon.hour
• uudemon.admin
• uudemon.cleanup

These shell scripts should execute regularly to keep UUCP running smoothly. The crontab file to run the scripts is automatically created in /usr/lib/uucp/uudemon.crontab as part of Solaris installation process, if you select the Full installation. Otherwise, it is created when you install the UUCP package.

You can also run the UUCP shell scripts manually.The following is the prototype uudemon.crontab file that you can tailor for a particular machine

# #ident "@(#)uudemon.crontab 1.3 93/02/02 SMI" # 48 8,12,16 * * * /usr/libuucp/uudemon.admin 45 23 * * * /usr/lib/uucp/uudemon.cleanup 0 * * * * /usr/lib/uucp/uudemon.poll 11,41 * * * * /usr/lib/uucp/uudemon.hour

To activate the uudemon.crontab file, become superuser and type:

# su uucp # crontab < /usr/lib/uucp/uudemon.crontab

uudemon.poll Shell Script

The default uudemon.poll shell script reads the /etc/uucp/Poll file once an hour. If any machines in the Poll file are scheduled to be polled, a work file (C.sysnxxxx) is placed in the /var/spool/uucp/nodename directory, where nodename represents the UUCP node name of the machine.

The shell script is scheduled to run once an hour, before uudemon.hour, so that the work files will be there when uudemon.hour is called.

uudemon.hour Shell Script

The default uudemon.hour shell script does the following:

1. Calls the uusched program to search the spool directories for work files (C.) that have not been processed and schedules these files for transfer to a remote machine.

2. Calls the uuxqt daemon to search the spool directories for execute files (X.) that have been transferred to your computer and were not processed at the time they were transferred.

By default, uudemon.hour runs twice an hour. You may want it to run more often if you expect high failure rates of calls to remote machines.

uudemon.admin Shell Script

The default uudemon.admin shell script does the following:

1. Runs the uustat command with -p and -q options. The -q reports on the status of work files (C.), data files (D.), and execute files (X.) that are queued. The -p prints process information for networking processes listed in the lock files (/var/spool/locks).

2. Sends resulting status information to the uucp administrative login via mail.

uudemon.cleanup Shell Script

The default uudemon.cleanup shell script does the following:

1. Takes log files for individual machines from the /var/uucp/.Log directory, merges them, and places them in the /var/uucp/.Old directory with other old log information.

2. Removes work files (C.) 7 days old or older, data files (D.) 7 days old or older, and execute files (X.) two days old or older from the spool files.

3. Returns mail that cannot be delivered to the sender.

4. Mails a summary of the status information gathered during the current day to the UUCP administrative login (uucp).

Running UUCP Over TCP/IP

To run UUCP on a TCP/IP network, you need to make a few modifications, as described in this section

Activating UUCP in /etc/inetd.conf

Make sure that the following entry in /etc/inetd.conf is not preceded by a comment mark (#):

uucp stream tcp nowait root /usr/sbin/in.uucpd in.uucpd

Tailoring Systems File Entries for TCP/IP

Entries in the /etc/uucp/Systems file should have the following fields:

System-Name Time TCP Port networkname Standard-Login-Chat

A typical entry would look like this:

rochester Any TCP - ur-seneca login: Umachine password: xxx

Notice that the fifth field, networkname, permits you to specify explicitly the TCP/IP host name. This is important for some sites. In the example above, the site has a UUCP node name like rochester that is different from its TCP/IP host name ur-seneca. Moreover, there could easily be a completely different machine running UUCP that has a TCP/IP host name of rochester.

The Port field in the Systems file should have the entry -. This is equivalent to listing it as uucp. In almost every case, the networkname will be the same as the system name, and the Port field will be -, which says to use the standard uucp port from the services database. The in.uucpd daemon expects the remote machine to send its login and password for authentication, and it prompts for them much as getty and login do.

Checking /etc/inet/services for UUCP

The following entry in /etc/inet/services sets up a port for UUCP:

uucp 540/tcp uucpd # uucp daemon

You should not have to change the entry. However, if your machine runs NIS or NIS+ as its name service, you should change the /etc/nsswitch.conf entry for /etc/services to check files first, and then check nis or nisplus.

Security, Maintenance, and Troubleshooting

Once you have set up UUCP, its maintenance is straightforward. This section explains ongoing UUCP tasks with regard to security, maintenance, and troubleshooting.

Setting Up UUCP Security

The default /etc/uucp/Permissions file provides the maximum amount of security for your UUCP links. The default Permissions file contains no entries.

You can set additional parameters for each machine to define:

• Ways it can receive files from your machine
• Directories for which it has read and write permission
• Commands it can use for remote execution

A typical Permissions entry is:

MACHINE=datsun LOGNAME=Udatsun VALIDATE=datsun COMMANDS=rmail REQUEST=yes SENDFILES=yes

This entry allows files to be sent and received (to and from the ''normal'' UUCP directories, not from anywhere in the system) and causes the UUCP user name to be validated at login time. For more information, see

Regular UUCP Maintenance

UUCP does not require much maintenance. Apart from making sure that the crontab file is in place, as described in the section "uudemon.poll Shell Script" on page 227. All you have to worry about is the growth of mail files and the public directory.

email for UUCP

All email messages generated by the UUCP programs and scripts go to the user ID uucp. If you do not log in frequently as that user, you may not realize that mail is accumulating (and consuming disk space). To solve this, make an alias in /etc/aliases, and redirect that email either to root or to yourself and others responsible for maintaining UUCP. Don't forget to run the newaliases command after modifying the aliases file.

Public Directory

The directory /var/spool/uucppublic is the one place in every system to which UUCP by default is able to copy files. Every user has permission to change to /var/spool/uucppublic and read and/or write files in it. However, its sticky bit is set, so its mode is 01777. As a result, users cannot remove files that have been copied to it and that belong to uucp. Only you, as UUCP administrator logged in as root or uucp, can remove files from this directory. To prevent the uncontrolled accumulation of files in this directory, you should make sure to clean it up periodically.

If this is inconvenient for users, encourage them to use uuto and uupick rather than removing the sticky bit, which is set for security reasons. (See the uuto(1C) man page for instructions for using uuto and uupick.) You can also make the mode of the directory more restrictive, perhaps just to a group of people. If you do not want to run the risk of having someone fill your disk, you can even deny UUCP access to it.

Troubleshooting UUCP

These procedures describe how to solve common UUCP problems.

Checking for Faulty Modems or ACUs

You can check if the modems or other ACUs are not working properly in several ways.

• Run uustat -q. This will give counts and reasons for contact failure.
• Run cu -d -lline, where line is /dev/cua/a. This will let you call over a particular line and print debugging information on the attempt. The line must be defined as direct in the /etc/uucp/Devices file. (You must add a telephone number to the end of the command line if the line is connected to an autodialer or the device must be set up as direct.)

Checking the /etc/uucp/Systems File

Verify that you have up-to-date information in your Systems file if you are having trouble contacting a particular machine. Some things that may be out of date for a machine are its:

• Phone number
• Login
• Password

Debugging Transmissions

If you cannot contact a particular machine, you can check out communications to that machine with Uutry and uucp.

1. To try to make contact, type /usr/lib/uucp/Uutry -r machine and press Return.

   Replace machine with the host name of the machine you are having problems contacting. This command:

   a. Starts the transfer daemon (uucico) with debugging. You will get more debugging information if you are root.

   b. Directs the debugging output to /tmp/machine.

   c. Prints the debugging output to your terminal (tail -f). Press Control-c to end output. You can copy the output from /tmp/machine if you want to save it.

2. If Uutry doesn't isolate the problem, try to queue a job by typing uucp -r file machine\!/dir/file and press Return. Replace file by the file you want to transfer, machine by the machine you want to copy to, and /dir/file where the file will be placed on the other machine. The -r option queues a job but does not start the transfer.

3. Now use Uutry again.

   If you still cannot solve the problem, you may need to call your local support representative. Save the debugging output; it will help diagnose the problem.

You may also want to decrease or increase the level of debugging provided by Uutry through the -x n option, where n indicates the debug level. The default debug level for Uutry is 5.

Debug level 3 provides basic information as to when and how the connection is established, but not much information about the transmission itself. Debug level 9, on the other hand, provides exhaustive information about the transmission process. Be aware that debugging occurs at both ends of the

transmission. If you intend to use a level higher than 5 on a moderately large text, get in touch with the administrator of the other site and agree on a time for doing so.

Checking Error Messages

UUCP has two types of error messages: ASSERT and STATUS.

When a process is aborted, ASSERT error messages are recorded in /var/uucp/.Admin/errors. These messages include the file name, sccsid, line number, and text. These messages usually result from system problems.

STATUS error messages are stored in the /var/uucp/.Status directory. The directory contains a separate file for each remote machine your computer attempts to communicate with. These files contain status information on the attempted communication and whether it was successful.

Checking Basic Information

There are several commands you can use to check for basic networking information.

• uuname- Use this command to list those machines your machine can contact.
• uulog-Use this command to display the contents of the log directories for particular hosts.
• uucheck -v - Run this command to check for the presence of files and directories needed by uucp. This command also checks the Permissions file and outputs information on the permissions you have set up.

UUCP Error Messages

This section lists the error messages associated with UUCP.

UUCP ASSERT Error Messages

Table 13-1 lists ASSERT error messages.

Table 13-1

Error Message	Description/Action
CAN'T OPEN	An open() or fopen() failed.
CAN'T WRITE	A write(), fwrite(), fprint(), or similar ccommand, failed.
CAN'T READ	A read(),fgets(), or similar command failed.
CAN'T CREATE	A creat() call failed.
CAN'T ALLOCATE	A dynamic allocation failed.
CAN'T LOCK	An attempt to make a LCK (lock) file failed. In some cases, this is a fatal error.
CAN'T STAT	A stat() call failed.
CAN'T CHMOD	A chmod() call failed.
CAN'T LINK	A link() call failed.
CAN'T CHDIR	A chdir() call failed.
CAN'T UNLINK	An unlink() call failed.
WRONG ROLE	This is an internal logic problem.
CAN'T MOVE TO CORRUPTDIR	An attempt to move some bad C. or X. files to the /var/spool/uucp/.Corrupt directory failed. The directory is probably missing or has wrong modes or owner.
CAN'T CLOSE	A close() or fclose() call failed.
FILE EXISTS	The creation of a C. or D. file is attempted, but the file exists. This occurs when there is a problem with the sequence file access. Usually indicates a software error.
No uucp service number	A TCP/IP call is attempted, but there is no entry in /etc/services for UUCP.
BAD UID	The user ID is not in the /etc/passwd file. The file system is in trouble, or the /etc/passwd file is inconsistent.
BAD LOGIN_UID	Same as previous.
BAD LINE	There is a bad line in the Devices file; there are not enough arguments on one or more lines.

Table 13-1

Error Message	Description/Action
SYSLST OVERFLOW	An internal table in gename.c overflowed. A big or strange request was attempted. Contact your local representative.
TOO MANY SAVED C FILES	Same as previous.
RETURN FROM fixline ioctl	An ioctl(2), which should never fail, failed. There is a system driver problem.
BAD SPEED	A bad line speed appears in the Devices/Systems files (Class/Speed field).
BAD OPTION	There is a bad line or option in the Permissions file. It must be fixed immediately.
PKCGET READ	The remote machine probably hung up. No action need be taken.
PKXSTART	The remote machine aborted in a nonrecoverable way. This can usually be ignored.
TOO MANY LOCKS	There is an internal problem. Contact your system vendor.
XMV ERROR	There is a problem with some file or directory. It is likely the spool directory, since the modes of the destinations were suppose to be checked before this process was attempted.
CAN'T FORK	An attempt to make a fork and exec failed. The current job should not be lost but will be attempted later (uuxqt). No action need be taken.

UUCP STATUS Error Messages

Table 13-2 is a list of the most common STATUS error messages.

Table 13-2

Error Message	Description/Action
OK	Status is okay.
NO DEVICES AVAILABLE	There is currently no device available for the call. Check to see that there is a valid device in the Devices file for the particular system. Check the Systems file for the device to be used to call the system.
WRONG TIME TO CALL	A call was placed to the system at a time other than what is specified in the Systems file.
TALKING	Self-explanatory.
LOGIN FAILED	The login for the given machine failed. It could be a wrong login or password, wrong number, a very slow machine, or failure in getting through the Dialer-Token-Pairs script.
CONVERSATION FAILED	The conversation failed after successful startup. This usually means that one side went down, the program aborted, or the line (link) was dropped.
DIAL FAILED	The remote machine never answered. It could be a bad dialer or the wrong phone number.
BAD LOGIN/MACHINE COMBINATION	The machine called us with a login/machine name that does not agree with the Permissions file. This could be an attempt to masquerade!
DEVICE LOCKED	The calling device to be used is currently locked and in use by another process.
ASSERT ERROR	An ASSERT error occurred. Check the /var/uucp/.Admin/errors file for the error message and refer to the section "UUCP Error Messages" on page 233.
SYSTEM NOT IN Systems FILE	The system is not in the Systems file.
CAN'T ACCESS DEVICE	The device tried does not exist or the modes are wrong. Check the appropriate entries in the Systems and Devices files.
DEVICE FAILED	The device could not be opened.

Table 13-2

Error Message	Description/Action
WRONG MACHINE NAME	The called machine is reporting a different name than expected.
CALLBACK REQUIRED	The called machine requires that it calls your machine.
REMOTE HAS A LCK FILE FOR ME	The remote machine has a LCK file for your machine. It could be trying to call your machine. If it has an older version of UUCP, the process that was talking to your machine may have failed, leaving the LCK file. If it has the new version of UUCP and is not communicating with your machine, then the process that has a LCK file is hung.
REMOTE DOES NOT KNOW ME	The remote machine does not have the node name of your machine in its Systems file.
REMOTE REJECT AFTER LOGIN	The login used by your machine to login does not agree with what the remote machine was expecting.
REMOTE REJECT, UNKNOWN MESSAGE	The remote machine rejected the communication with your machine for an unknown reason. The remote machine may not be running a standard version of UUCP.
STARTUP FAILED	Login succeeded, but initial handshake failed.
CALLER SCRIPT FAILED	This is usually the same as DIAL FAILED. However, if it occurs often, suspect the caller script in the Dialers file. Use Uutry to check.