BNU must be maintained to work properly on your system. To maintain BNU:
In addition, occasionally check with administrators of remote systems to keep up with changes on their systems that may affect your configuration. For example, if the supervisor of system venus changes your system's password, you will need to put the new password in the /etc/uucp/Systems file (or the appropriate Systems file specified by /etc/uucp/Sysfiles) before your system can log in to system venus .
See BNU Files, Commands, and Directories Reference for a list of commands used to maintain BNU.
BNU creates log files and error files to track its own activities. These files must be checked and removed periodically to keep them from filling the storage space on your system. BNU provides several commands for use in cleaning log files:
Run these commands manually or use entries in the /var/spool/cron/crontabs/uucp file to run the commands by the cron daemon.
BNU creates individual log files in the /var/spool/uucp/.Log directory. BNU creates these log files for each accessible remote system, using the uucp, uuto, or uux command. BNU places status information about each transaction in the appropriate log file each time someone on the system uses BNU. When more than one BNU process is running the system cannot access the log file. Instead, it places the status information in a separate file with a .LOG prefix.
The uulog command displays a summary of uucp or uux requests, by user or by system. The uulog command displays the files. However, you can also have BNU automatically combine the log files into a primary log file. This is called compacting the log files and can be done with the uudemon.cleanu command, usually run by the cron daemon.
The cron daemon runs the uudemon.cleanu command. The uudemon.cleanu command combines the uucico and uuxqt log files on the local system and stores them in the /var/spool/uucp/.Old directory. At the same time, the command removes old log files previously stored in the .Old directory. By default, the uudemon.cleanu command saves log files that are two days old.
If storage space is a problem, consider reducing the number of days that files are kept. To track BNU transactions over a longer period of time, consider increasing the number of days that files are kept. To change the default time for saving log files, modify the shell procedure for the uudemon.cleanu command. This script is stored in the /usr/sbin/uucp directory and can be modified with root authority.
BNU also collects information and stores it in the /var/spool/uucp/.Admin directory. This directory contains the errors, xferstats, Foreign, and audit files. These files must be checked and removed occasionally to save storage space. BNU creates each file when it is needed.
When another system contacts your system with the uucico daemon's debugging mode on, it invokes the uucico daemon on your system with debugging turned on. The debugging messages generated by the daemon on the local system are stored in the audit file. This file can get quite large. Check and remove the audit file often.
The errors file records errors encountered by the uucico daemon. Checking this file can help you correct problems such as incorrect permissions on BNU work files.
The xferstats file contains information about the status of every file transfer. Check and remove this file occasionally.
The Foreign file is important to the security of your system. Whenever an unknown system attempts to log in to the local system, BNU calls the remote.unknown shell procedure. This shell procedure logs the attempt in the Foreign file. The Foreign file contains the names of the systems that have attempted to call the local system and been refused. If a system has been attempting frequent calls, use this information when considering whether to allow that system access.
Because many BNU processes need root authority to complete their tasks, BNU creates frequent entries in the /var/spool/sulog log file. Similarly, using the cron daemon to schedule BNU tasks creates multiple entries in the /var/spool/cron/log file. When using BNU, check and clean these files.
The Basic Networking Utilities contain several commands for monitoring BNU activities and cleaning BNU directories and files.
BNU contains three commands that clean directories and remove files that have not been sent:
BNU also provides commands for checking the status of transfers and log files:
uuq | Displays jobs currently in the BNU job queue. Use the uuq command to display the status of a specified job or of all jobs. With root authority, you can use the uuq command to delete a job from the queue. |
uustat | Provides information similar to that provided by the uuq command, in a different format. Use the uustat to check the status of jobs and delete jobs you own. With root authority, you can also delete jobs belonging to other users. |
uulog | Displays a summary of uucp or uux requests, by user or by system. The uulog command displays the file names. See "Working with BNU Log Files". |
uupoll | Forces a poll of a remote system. This is helpful when work for that system is waiting in the queue and needs to be transferred, before the system is scheduled to be called automatically. |
uusnap | Displays a very brief summary of BNU status. For each remote system, this command shows the number of files awaiting transfer. However, it does not show how long they have been waiting. The uusnap command is the Berkeley equivalent of the uustat command. |
BNU is delivered with two shell procedures used for maintenance:
uudemon.cleanu | Discussed under "Cleanup Commands". |
uudemon.admin | Issues the uustat command The uustat command reports the status of BNU jobs. It sends the results to the uucp login ID as mail. You can modify the uudemon.admin shell procedure to send the mail elsewhere, or use a mail program to reroute all mail for the uucp login ID to the user responsible for BNU administration. |
These shell procedures are stored in the /usr/sbin/uucp directory. Copy the procedures and modify the copy, if you want to change what they do. Run the procedures from the command line or schedule them to be run by the cron daemon.
To automatically run the uudemon.cleanu and uudemon.admin commands, remove the comment characters (#) from the beginning of the relevant lines in the /var/spool/cron/crontabs/uucp file.
Note: You must have root user authority to modify the BNU configuration files.
The Uutry command can help you monitor the uucico daemon process if users at your site report file-transfer problems.
uustat -qThe system displays a status report like the following:
venus 3C (2) 05/09-11:02 CAN'T ACCESS DEVICE hera 1C 05/09-11:12 SUCCESSFUL merlin 2C 5/09-10:54 NO DEVICES AVAILABLEThis report indicates that three command (C.*) files intended for remote system venus have been in the queue for two days. There could be several reasons for this delay. For example, perhaps system venus has been shut down for maintenance or the modem has been turned off.
/usr/sbin/uucp/Uutry -r venusThis command starts the uucico daemon with a moderate amount of debugging and the instruction to override the default retry time. The Uutry command directs the debugging output to a temporary file, /tmp/venus .
Conversation Complete: Status SUCCEEDEDIf the connection is successful, assume that the temporary file-transfer problems are now resolved. Issue the uustat command again to make certain that the files in the spooling directory have been transferred successfully to the remote system. If they have not, use the steps in "Monitoring a BNU File Transfer" to check for file-transfer problems between your system and the remote system.
mchFind called (venus) conn (venus) getto ret -1 Call Failed: CAN'T ACCESS DEVICE exit code 101 Conversation Complete: Status FAILEDFirst, check the physical connections between the local and remote systems. Make sure that the remote computer is turned on and all cables are properly connected, that the ports are enabled or disabled (as appropriate) on both systems, and that the modems (if applicable) are working.
If the physical connections are correct and secure, then verify all the relevant configuration files on both the local and remote systems, including the following:
Use this procedure to monitor a file transfer to a remote system. Monitoring a file transfer is useful when file transfers to the remote system in question are failing for unknown reasons. The debugging information produced by the uucico daemon (called by the Uutry command) can help you find out what is working incorrectly.
The Uutry command enables you to monitor file transfers, as follows:
uucp -r test1 venus!~/test2The -r flag instructs the BNU program to place the test1 file in the queue but not to start the uucico daemon.
/usr/sbin/uucp/Uutry -r venusThis instructs the uucico daemon to contact remote system venus overriding the default retry time. The daemon contacts system venus , logs in, and transfers the file, while the Uutry command produces debugging output that enables you to monitor the uucico process. Press the Interrupt key sequence to stop the debugging output and return to the command prompt.
The Uutry command also stores the debugging output in the /tmp/SystemName file. If you break out of the debugging output before the connection is complete, you can page through the output file to see the outcome of the connection.
BNU error messages can be linked to a specific phase in the conversation flow. Use the BNU Conversation Flow Diagram and the following error descriptions to help diagnose your BNU problems. Some of the following messages may not be sent from BNU, but are included in case another uucp version is in use.
Note: You must have root user authority to modify the BNU configuration files.
/usr/sbin/uucp/uucico -r 1 -s venus -x 9where -r 1 specifies the master, or caller mode; -s venus , the name of the remote system to which you are trying to connect; and -x 9 , the debug level that produces the most detailed debugging information.
venus Any venus 1200 - "" \n in:--in: uucp1 word: mirrorthe uucico daemon connects the local system to the remote system venus. The debugging output is similar to:
expect: "" got it sendthem (^J^M) expect (in:)^ M^Jlogin:got it sendthem (uucp1^M) expect (word:)^ M^JPassword:got it sendthem (mirror^M) imsg >^M^J^PShere^@Login Successful: System=venuswhere:
Notes:
- The expect-send debugging output produced by the uucico command can come either from information in the /etc/uucp/Dialers file or from information in the /etc/uucp/Systems file. Information about communication with the modem comes from the Dialers file, while information about communication with the remote system comes from the Systems file. (Note that /etc/uucp/Systems and /etc/uucp/Dialers are default BNU configuration files. Other files can be specified in /etc/uucp/Sysfiles to serve the same role.)
- To set up a connection with a remote system, you must be familiar with the login sequence of that system.
Use the tip command to contact any connected system running the UNIX operating system. The tip command is installed with the Basic Networking Utilities (BNU) and can use the same asynchronous connections used by BNU.
The tip command uses variables and escape signals, as well as flags, to control its operations. The flags can be entered at the command line. The escape signals can be used over a connection with a remote system to start and stop file transfers, change the direction of a file transfer, and exit to a subshell.
The tip command variables define settings such as the end-of-line character, the break signal, and the mode of file transfers. Variable settings can be initialized at run time using a .tiprc file. Variable settings can also be changed during execution using the ~s escape signal. Some variables, such as the end-of-line character, can be set for an individual system in that system's entry in the remote file.
The tip command reads three files, the phones file, remote file, and .tiprc file, to determine initial settings for its variables. The .tiprc file must always be in the user's home directory. The names and locations of the remote and phones files can vary. The names of the remote file and the phones file can be determined by environment variables:
To use an environment variable, set it before starting the tip command. As an alternative, the names of the phones and remote files can be determined using the tip command phones variable and remote variable, respectively, in the .tiprc file.
Note: The tip command reads only the last remote or phones file specified. Thus, if you specify a remote or phones file with a variable, the new file is used in place of (not in addition to) any previous files you specified.
The tip command uses variable settings in the following order:
Note: Any tip user can create a .tiprc file and use this file to specify initial settings for tip variables. The .tiprc file must be placed in the user's $HOME directory.
Before the tip command can connect to a remote system, the /etc/remote and /etc/phones files must be established.
To establish one of these files, copy a sample file to the correct name and modify it to suit the needs of your site. Sample remote and phones files are delivered with the bos.net.uucp package. The sample remote file is named /usr/lib/remote-file. The sample phones file is named /usr/lib/phones-file.
Note: You must have root authority to create files in the /usr/lib directory.
A tip user can also create customized remote and phones files. An individual remote file must be in the format of the /usr/lib/remote-file file and specified with the remote variable or the REMOTE environment variable. An individual phones file must be in the format of the /usr/lib/phones-file file and specified with the phones variable or the PHONES environment variable. If an individual phones or remote file is specified with one of the variables, that file is read in place of (not in addition to) the /etc/phones or /etc/remote file.
Users of tip can use combinations of individual phones and remote files. For example, a user could read the default remote file, /usr/lib/remote-file, but use an individual phones file named with the phones variable.