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:
|Deletes all files older than a specified number of hours, from the BNU administrative directories. Use the uuclean command to specify a directory to be cleaned or a type of file to be deleted. You can also instruct the command to notify the owners of the deleted files. The uuclean command is the Berkeley equivalent of the uucleanup command.
|Performs functions similar to the uuclean command. However, the uucleanup command checks the age of files based on days rather than hours. Use the uucleanup command to send a warning message to users whose files have not been transferred, notifying them that the files are still in the queue. The uucleanup command also removes files relating to a specified remote system.
|A shell procedure that issues the uulog and uucleanup commands to compress the BNU log files and remove log and work files over three days old. The uudemon.cleanu command is run by the cron daemon.
BNU also provides commands for checking the status of transfers and log files:
|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.
|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.
|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".
|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.
|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:
|Discussed under "Cleanup Commands".
|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.
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.
|The local system unit is having problems. Check the error report for possible causes by issuing the command errpt -a | pg.
|System not in Systems
|If you supply a remote system name that is not found in the Systems files, this status message is created. BNU will terminate. Use the uuname command to check the system name again.
|Wrong time to call
|The Systems file has restrictions on times to allow outgoing calls. BNU will keep trying until the time is right. Check the Systems file.
|The network has restricted usage either for security or economic reasons, and access is denied at this time.
|These errors mean BNU recently tried to call the remote system and failed. It will not immediately try again. They can also be caused by an old system status file being retained thus keeping uucico from trying again.
|Dialer Script Failed
|Your Dialers file script did not complete successfully.
|No Device Available
Can't Access Device
|The modem or the outgoing phone line from your system is busy. Check for an error in the device entry of the Systems file. Also, check the Devices and Dialers files to be sure logical devices have physical devices associated with them. The file /etc/uucp/Sysfiles may be specifying an alternate Systems, Devices or Dialers file that is not correctly configured. Is the device in use by some other program? Check the /etc/locks directory for lock on port. If a lock file exists (for example, LCK..TTY0), check to see if the process identified by the number in the lock file is still active. If not, you can remove it (for example, rm /etc/locks/LCK..TTY0 ). Also check the permissions on the port.
Failed (call to system)
|These errors appear when your system dials another successfully but the other system does not answer. It may also indicate a problem in the Devices files. Enter the command uucico -r1 -x6 -s SystemName . It could be that BNU is expecting some string that it is not receiving. Make connection by hand to find out what needs to be incorporated into the Systems files entry to satisfy the request. Please keep "timing" in mind; perhaps some delays in the modem's dial string are needed. This could also mean that the port is busy, you dialed an incorrect number, or BNU lost ownership of the port.
|These are informative messages only and do not indicate an error.
|Handshake Failed (LCK)
|The device is being used by someone else; the process could not create the LCK file. Sometimes LCK files must be manually removed by the administrator. After a number of retries, see your system administrator. See if another process has control of the port (for example, another instance of uucico).
|The login failed due to a bad connection or possibly a slow machine.
|The remote system did not respond within a set period of time. This could also indicate a problem with the chat script.
|Succeeded (Call to System)
|The call was completed.
|These are informative messages only and do not indicate an error.
Remote reject after login
|After login, uucico is started on the remote system. If there is a problem initiating a conversation between the two systems, these messages are created. You may have also logged into the incorrect BNU account or the initial handshake failed.
|Wrong machine name
|A machine was called incorrectly or the machine's name was changed.
|Bad login/machine combination
|The login to the remote system failed. The problem could be an incorrect phone number, an incorrect login or password, or an error in the chat script.
|Remote has a LCK file for me
|Both systems were simultaneously trying to call each other. The local request will fail temporarily.
|These are informative messages only and do not indicate an error.
| If the login or password prompt is in all capital letters, the modem may be in echo mode (E1 on Hayes
compatibles). This causes the modem to echo back, or send, a RING to your system when an incoming call is received.
The getty command receives the string and accordingly changes the login:
into all caps. Change the echo mode on the modem to off (use ATE0
Note: Keep in mind that once this change is made, you should use ATE1 in the chat script of your Dialers files, or you will not get the expected OK back from the modem.
If the remote port is set for delay or getty -r and the chat script expects key input, then the ports set for delay are expecting one or more carriage returns before proceeding with the login. Try beginning the chat script on the dialing system with the following:
|uucico is having trouble with the connection. Either the connection is bad or "xon/xoff" is set to yes on the modem.
|Remote access to path/file denied
|These messages indicate a permission problem; check file and path permissions.
|The remote system ran out of space, most likely in the spool area, or uucico could not read or write to device.
|The modem's carrier detect was lost. Possibly the modem was turned off, the cable is loose or disconnected, or the remote system crashed or is shut down. Telephone disconnection can also cause this error.
|These are informative messages only and do not indicate an error.
|OK (Conversation Complete)
|The remote system can deny the hangup request and reverse the roles (meaning the remote system has work for the local system to do). Once the two uucicos agree that no more work exists, they hang up.
|This is an informative message only and does not indicate an error.
/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:
|Specifies that the local system will not wait for any information from the remote system.
|Acknowledges that the message has been received.
|Specifies that the local system will send the remote system a carriage return and a new line.
|Specifies that the local system will expect to receive the remote system login prompt, which ends in the in: character string.
|Confirms that the local system will receive the remote login prompt.
|Specifies that the local system will send the uucp1 login ID to the remote system.
|Specifies that the local system will expect to receive the remote system password prompt, which ends in the word: character string.
|Confirms the local system will receive the remote password prompt.
|Specifies that the local system will send the password for the uucp1 login ID to the remote system.
|imsg >^M^J^PShere^@Login Successful: System=venus
|Confirms the local system is successfully logged in to remote system venus .
- 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:
|Specifies the name of the user's phone file. The file can have any valid file name and must be set up in the format of the file /usr/lib/phones-file. The default file is etc/phones. If a file is specified with the PHONES variable, it is used in place of (not in addition to) the /etc/phones file.
|Specifies the name of the user's remote system definition file. The file can have any valid file name and must be set up in the format of the /usr/lib/remote-file file. The default file is /etc/remote. If a file is specified with the REMOTE variable, it is used in place of (not in addition to) the /etc/remote file.
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.
|Defines attributes of remote systems such as the port and type of device to use to reach the system, as well as the signals to use to indicate the beginnings and endings of transmissions.
|Lists telephone numbers used to contact remote systems over a modem line.
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.