The Basic Networking Utilities (BNU) are a group of programs, directories, and files that can be used to communicate with any UNIX system on which a version of the UNIX-to-UNIX Copy Program (UUCP) is running. BNU is one of the Extended Services programs that can be installed with the base operating system.
A group of commands related to UUCP, a UNIX-to-UNIX communication program developed by AT&T and modified as part of the Berkeley Software Distribution (BSD) are contained in BNU. BNU provides commands, processes, and a supporting database for connections to local and remote systems. Communication networks such as Token-Ring and Ethernet are used to connect systems on local networks. A local network can be connected to a remote system by hardwire or telephone modem. Commands and files can then be exchanged between the local network and the remote system.
Topics discussed in this section are:
Before users on your system can run BNU programs, BNU must be installed and configured.
BNU is controlled by a set of configuration files that determine whether remote systems can log in to the local system and what they can do after they log in. These configuration files must be set up according to the requirements and resources of your system.
To maintain BNU, you must read and remove log files periodically and check the BNU queues to ensure jobs are correctly transferring to remote systems. You must also periodically update the configuration files to reflect changes in your system or remote systems.
BNU uses a set of hardware connections and software programs to communicate between systems. A structure of directories and files tracks BNU activities. This structure includes a set of public directories, a group of administrative directories and files, configuration files, and lock files. Most of the directories for BNU are created during the installation process. Some of the administrative directories and files are created by various BNU programs.
With the exception of the remote login commands, BNU works as a batch system. When a user requests a job sent to a remote system, BNU stores the information needed to complete the job. This is known as queuing the job. At scheduled times, or when a user instructs it to do so, BNU contacts various remote systems, transfers queued work, and accepts jobs. These transfers are controlled by the configuration files on your system and those of the remote system.
All BNU commands, except uucpadm, are available for National Language Support. User names need not be in ASCII characters. However, all system names must be in ASCII characters. If a user attempts to schedule a transfer or a remote command execution involving non-ASCII system names, BNU returns an error message.
BNU uses a structure of directories and files to keep track of their activities. This structure includes:
Most of the directories for BNU are created during the installation process. Some of the administrative directories and files are created by various BNU programs as they run.
When specified, the BNU public directory (/var/spool/uucppublic) stores files that have been transferred to the local system from other systems. The files wait in the public directory until users claim them. The public directory is created when BNU is installed. Within the public directory, BNU creates a subdirectory for each remote system that sends files to the local system.
The BNU configuration files, also known as the BNU supporting database, reside in the /etc/uucp directory. The files must be configured specifically for your system. They are owned by the uucp login ID and can be edited only with root authority. The configuration files contain information about:
Some configuration files also specify limits on BNU activities that prevent your system from becoming overloaded.
The BNU configuration files
include:
| Devices | Contains information about available devices, including both modems and direct connections. |
| Dialcodes | Contains dialing code abbreviations, which allow you to shorten phone numbers in the Systems file. |
| Dialers | Specifies calling command syntax for a specific modem type ("dialer"). |
| Maxuuscheds | Limits simultaneous scheduled jobs. |
| Maxuuxqts | Limits simultaneous remote command executions. |
| Permissions | Contains access permission codes. This file is the primary file for determining the security for BNU. |
| Poll | Specifies when the BNU program should poll remote systems to initiate tasks. |
| Sysfiles | Lists files that serve as the Systems, Devices, and Dialers files for the BNU configuration. If this file is not used, the default files are /etc/uucp/Systems, /etc/uucp/Devices, and /etc/uucp/Dialers. |
| Systems | Lists accessible remote systems and information needed to contact them, including the device to use and the user name and password combinations you need to log in. Also specifies the times when the systems can be contacted. |
The configuration files cross-reference each other when BNU is in use. For example:
Entries in the BNU configuration files depend on the types of connections between your system and each remote system. For example, special entries must be made if Transmission Control Protocol/Internet Protocol (TCP/IP) or direct connections are used to contact other systems. If modems are used to contact other systems, the modems must be defined in the Dialers file.
The Systems, Devices, and Permissions files must be configured on your system before you can contact remote systems using BNU. Other configuration files enable you to use BNU capabilities, such as automatic polling. Many of the configuration files must be modified periodically to reflect changes to your system or the systems you contact. The Sysfiles file can be used to specify files other than the default Systems, Devices, and Dialers files to fulfill the same role.
The BNU administrative directories and files are in subdirectories of the /var/spool/uucp directory. These directories and files contain two types of information:
Under the
/var/spool/uucp directory, BNU creates the following
directories:
| .Admin | Contains four administrative files:
These files contain error and log information about BNU activities. |
| .Corrupt | Contains copies of files that cannot be processed by the BNU program. |
| .Log and .Old | Contain log files from BNU transactions. |
| .Status | Stores the last time the uucico daemon tried to contact remote systems. |
| .Workspace | Holds temporary files that the file transport programs use internally. |
| .Xqtdir | Contains execute files with lists of commands that remote systems can run. |
| SystemName | Contains files used by file transport programs. These files
are:
BNU creates a SystemName directory for each remote system it contacts. |
The directories whose names begin with a dot are hidden. They cannot be found with an ls or li command unless the -a flag is used. When the uucico daemon is started, it searches the /var/spool/uucp directory for work files and transfers the files from any directory that is not hidden. The uucico daemon sees only the SystemName directories, not the other administrative directories.
The files in the hidden directories are owned by the uucp login ID. These files can be accessed only with root authority or with a login ID with a UID of 5.
For further information about maintaining the BNU administrative directories, see Maintaining BNU.
The BNU lock files are stored in the /var/locks directory. When BNU uses a device to connect to a remote computer, it places a lock file for that device in the /var/locks directory. When another BNU program or any other program needs the device, that program checks the /var/locks directory for a lock file. If a lock file exists, the program waits until the device is available or uses another device for the communication.
In addition, the uucico daemon places lock files for remote systems in the /var/locks directory. Before contacting a remote system, the uucico daemon checks the /var/locks directory for a lock file for that system. These files prevent other instances of the uucico daemon from establishing duplicate connections to the same remote system.
Note: Other software besides BNU, such as Asynchronous Terminal Emulation (ATE) and TCP/IP, uses the /var/locks directory.
Because other systems contact your system to log in, transfer files, and enter commands, BNU provides a means to establish security. BNU security enables you to restrict what users of remote systems can do on the local system (users of remote systems can also restrict what you can do on their systems). BNU runs several daemons to complete its activities and uses administrative directories to store the files it needs. BNU also keeps a log of its own activities.
BNU security works on several levels. When you configure BNU, you can determine:
When BNU is installed, all of the configuration files, daemons, and many of the commands and shell procedures are owned by the uucp login ID. The uucp login ID has a user ID (UID) of 5 and a group ID (GID) of 5. The cron daemon reads the /var/spool/cron/crontabs/uucp file to schedule automatic jobs for BNU.
Usually, logging in as user uucp is not allowed. To change files that are owned by the uucp login ID, log in with root authority.
Attention: Allowing remote systems to log in to the local system with the uucp login ID seriously jeopardizes the security of the local system. Remote systems logged in with the uucp ID can display and possibly modify the local Systems and Permissions files depending on the other permissions specified in the LOGNAME entry. It is strongly recommended that you create other BNU login IDs for remote systems and reserve the uucp login ID for the person responsible for administering BNU on the local system. For the best security, each remote system that contacts the local system must have a unique login ID with a unique UID number.
The operating system provides a default nuucp login ID for transferring files.
The startup shell for BNU login IDs is the uucico daemon (/usr/sbin/uucp/uucico). When remote systems call your system, they automatically start the uucico daemon on your system. Login IDs for BNU have a uucp group ID of 5.
Login IDs used by remote systems need passwords. In order to prevent security from prompting a new BNU login ID for a new password when the remote system logs in, you must set the password as soon as you create the account. To do this, use the passwd command followed by the pwdadm command. For example, to set a password for the login ID nuucp, log in as the root user and enter the following commands:
passwd nuucp
pwadm -f NOCHECK nuucp
The system prompts you for a password for the nuucp login ID. Completing these steps allows the remote system to log in without being immediately prompted for a new password (which the batch-oriented nuucp login ID can not provide).
After creating the login ID for a remote system, notify that system BNU administrator of the login ID and password to access your system.
A user with root authority can set up a BNU administrative login ID. This is useful if you want to delegate BNU administration duties to a user without root authority. The BNU administrative login ID should have password security, a UID of 5, and be in a uucp group ID 5. The login shell for the administrative login should be the /usr/bin/sh program (instead of the uucico daemon). Giving the BNU administrative login a UID of 5 causes it to have the same privileges as the uucp login ID. Thus, for security, remote systems should not be allowed to log in as the BNU administrator.
On most BNU systems, only remote systems listed in the /etc/uucp/Systems file or one of its substitutes (specified in the Sysfiles file) can log in to the local system. The /usr/sbin/uucp/remote.unknown script is executed whenever an unknown system attempts to call the local system. This script refuses to let the unknown system log in and makes an entry in the /var/spool/uucp/.Admin/Foreign file recording the time of the login attempt.
With root authority, or as a BNU administrator, you can modify the remote.unknown shell procedure to log more information about the remote system or to store the information in a different file. For example, you can modify the shell procedure to send mail to the BNU administrator whenever an unknown system tries to log in.
By taking away execute permissions on the remote.unknown shell procedure, you enable unknown machines to log in. In this case, you should add a MACHINE=OTHER entry to the /etc/uucp/Permissions file to establish permissions for the unknown machines.
Your system can contact only remote systems listed in the Systems file. This prevents users on your system from contacting unknown systems.
The /etc/uucp/Permissions file determines:
The
/etc/uucp/Permissions file contains two types of entries:
Options in the Permissions file enable you to establish various levels of security for each remote system. For example, if many remote systems share one login ID on the local system, use the VALIDATE option to require each remote system to use a unique login ID. The SENDFILES, REQUEST, and CALLBACK options specify which system has control, keeping the local system in control of transactions if necessary.
The READ, WRITE, NOREAD, and NOWRITE options define access to specific directories on the local system. These options also control where on your system remote users can place data. The COMMANDS option limits the number of commands users on remote systems can execute on the local system. The COMMANDS=ALL option allows total privileges to systems closely associated with your system.
Attention: The COMMANDS=ALL option can seriously jeopardize the security of your system.
The BNU software includes four
daemons stored in the /usr/sbin/uucp directory:
| uucico | Facilitates file transfers. |
| uusched | Facilitates work request scheduling of files queued in the local spooling directory. |
| uuxqt | Facilitates remote command executions. |
| uucpd | Facilitates communications using TCP/IP. |
The uucico, uusched, and uuxqt daemons are started by the cron daemon according to a schedule set by the BNU administrator. With root authority, you can also start these daemons manually. The uucpd daemon should be started by the TCP/IP inetd daemon.
The uucico daemon transports the files required to send data from one system to another. The uucp and uux commands start the uucico daemon to transfer command, data, and execute files to the designated system. The uucico daemon is also started periodically by the BNU scheduler, the uusched daemon. When started by the uusched daemon, the uucico daemon attempts to contact other systems and execute the instructions in the command files.
To run the instructions in the command files, the uucico daemon first checks the /etc/uucp/Systems file (or one or more other files specified by /etc/uucp/Sysfiles) for the system to be called. The daemon then checks the Systems file entry for a valid time to call. If the time is valid, the uucico daemon checks the Type and Class fields and accesses the /etc/uucp/Devices file (or one or more other files specified by /etc/uucp/Sysfiles) for a device that matches.
After finding a device, the uucico daemon checks the /var/locks directory for a lock file for the device. If one exists, the daemon checks for another device of the requested type and speed.
When no device is available, the daemon returns to the Systems files for another entry for the remote system. If one exists, the daemon repeats the process of searching for a device. If another entry is not found, the daemon makes an entry in the /var/spool/uucp/.Status/SystemName file for that remote system and goes on to the next request. The command file remains in the queue. The uucico daemon attempts the transfer again at a later time. The later attempt is called a retry.
When the uucico daemon reaches the remote system, it uses the instructions in the Systems files to log in. This causes an instance of the uucico daemon to be invoked on the remote system as well.
The two uucico daemons, one on each system, work together to make the transfer. The uucico daemon on the calling system controls the link, specifying the requests to be performed. The uucico daemon on the remote system checks the local permissions for whether they allow the request to be performed. If so, the file transfer starts.
After the uucico daemon on the calling system has finished transferring all requests it has for the remote system, it sends a hangup request. When the remote uucico daemon has transactions to send to the calling system, it denies the hangup request, and the two daemons reverse roles.
Note: Either the /etc/uucp/Permissions file on the local system or the /etc/uucp/Permissions file on the remote system can forbid the daemons to reverse roles. In this case, the remote system must wait to transfer files until it calls the local system.
When nothing is left to be transferred in either direction, the two uucico daemons hang up. At this point, the uuxqt daemon is called to execute remote command requests.
Throughout the transfer process, the uucico daemons on both systems log messages in the BNU log and error files.
The uusched daemon schedules the transfer of files that are queued in the spooling directory on the local system. The spooling directory is /var/spool/uucppublic. When the uusched daemon is invoked, it scans the spooling directory for command files, then randomizes the files and starts the uucico daemon. The uucico daemon transfers the files.
When a user issues the uux command to run a specified command on a designated system, the uuxqt daemon runs the command. After creating the necessary files, the uux command starts the uucico daemon, which transfers those files to the public spooling directory on the specified system.
The uuxqt daemon periodically searches the spooling directory for command-execution requests on every connected system. When it locates such a request, the uuxqt daemon checks for necessary files and permissions. Then, if permitted, the daemon runs the specified command.
The uucpd daemon must be able to run on the remote system before BNU can establish communications with a remote computer with Transmission Control Protocol/Internet Protocol (TCP/IP). The uucpd daemon is a subserver of the TCP/IP inetd daemon and is started by the inetd daemon.
By default, the uucpd daemon is commented in the inetd.conf file. To use it, you must remove the comment character and restart inetd. However, if this has been changed on your system, you might need to reconfigure the inetd daemon to start the uucpd daemon.