0707070000020023031006440001460001440000010341170363177235400000500000000004Size300 0707070000020024101007770001460001440000010351430363177230500001000000000566Install# install for HDB documents # SPOT=$HOME/Filecabinet/HDB.docs mkdir $SPOT 2>/dev/null rm -rf ${SPOT}/* ln docs/* $SPOT message -i "Version 2.0a HDB Documents are installed in $SPOT.\nBe sure to read the document README.7300 BEFORE ordering or installing the HDB Software.\nYou may wish to delete some of these documents to conserve disk space.\nTouch Enter to continue." 0707070000020023011007770001460001440000010341150357433053300000700000000107Remove# remove for HDB documents cd $HOME/Filecabinet /bin/rm -rf HDB.docs 0707070000020022771006660001460001440000010341200363177252500000600000000604Files./Size ./Install ./Remove ./Files ./Name ./MAKEcpio ./docs ./docs/AppendixI ./docs/AppendixII ./docs/AppendixIII ./docs/AppendixIV ./docs/README ./docs/README.7300 ./docs/Uutry.1m ./docs/ct.1c ./docs/cu.1c ./docs/uucheck.1m ./docs/uucico.1m ./docs/uucleanup.1m ./docs/uucp.1c ./docs/uucp.D ./docs/uugetty.1m ./docs/uusched.1m ./docs/uustat.1c ./docs/uuto.1c ./docs/uux.1c ./docs/uuxqt.1m 0707070000020024321006440001460001440000010351360363177232700000500000000111NameHoneyDanBer UUCP Documents v2.0a (starlan) 1/6/86 - from THE STORE! 0707070000020024301007770001460001440000010341130363177245300001100000000046MAKEcpiocat Files | cpio -ocBv > HONEYDOCS+IN 0707070000020023060407770001460001440000020341210363177077000000500000000000docs0707070000020023071006660001460001440000010341220357433053400001700000014100docs/AppendixI.P The parms.h header file is used to set up local site options before a ``make'' command is attempted. The file is set up with default settings for a standard UNIX distribution, however, there are some options that the local administrator might want to use. The file has comments to briefly describe the options; this section contains more details. .BL .LI ATTSV, V7, BSD4_2: One of these three should be defined: .DL .LI ATTSV for standard UNIX systems. .LI V7 for Version 7 based systems like 32V, Berkeley 4.1 systems. .LI BSD4_2 for Berkeley 4.2 systems. .LE .LI UUCPUID: There are several places in the code where the uid of ``uucp'', the owner of the uucp programs, files, and directories, must be used. In most cases, the uid can be obtained, but on some systems, when running as root, the info will not be forthcoming, so this manifest is used; it is the uid of the uucp login (again, the owner) from the /etc/passwd file. .LI ATTSVKILL: The new lock-file mechanism uses the system call ``kill(0, pid)'' to determine if a process-id in a LCK file is still active. Standard UNIX systems provide this facility, but some do not support it. Define ATTSVKILL if you system supports the kill(0, pid) call. (Note that this is automatically defined if ATTSV is defined). NONAP: Define NONAP if you have no high-resolution sleep call. Standard UNIX does not have this high-resolution sleep, so this must be defined. .LI FASTTIMER: This is the device that goes along with the high-resolution timer. Not available on standard UNIX systems; don't define it. .LI V7USTAT Uucp use ``ustat'' to decide whether there's enough space to receive a file. If you're not ATTSV, you can use a setgid program to read the number of free blocks and free inodes directly off the disk. If you choose this course, do not define NOUSTAT; rather, define V7USTAT to be the name of that program. Be sure it accepts 2 args, major and minor device numbers, and returns two numbers, blocks and inodes, in "%d %d" format, or you'll never receive another file. .LI NOUSTAT: Define this if your system does not have a ustat() system call. Standard UNIX has the call; don't define it for those systems. .LI GRPCHK, GRPMIN, GRPMAX: Define GRPCHK if you want to restrict the ability to read Systems information by way of the DEBUG flags. If you define GRPCHK, then the group-ids GRPMIN and GRPMAX limit the group-ids for which the Systems file password information will be displayed when the DEBUG option is used. .LI UNET: Use this to include code for 3com ethernet media. Appropriate changes must be made in the ``makefile'' to include the needed routines. See comments in the makefile. .LI DATAKIT: Define DATAKIT if your system is connected to a DATAKIT VCS. If you use this option, you must also make the appropriate changes in the ``makefile'' to access the dk library and loading of the dio.o routine\(emsee the comments in the makefile. .LI TCP: Define TCP for BSD systems that have TCP or UNET. .LI SYTEK: Define SYTEK for systems that access a Sytek network. .LI TDK_DATAKIT: Define this for the few systems that have the old tdk Datakit interface. .LI DIAL801: This is defined for the standard 801/212-103 dialer interface. If will be defined by default. .LI X25: Use this to include code for the X25 media. Appropriate changes must be made in the ``makefile'' to include the needed routines. See comments in the makefile. .LI DUMB_DN: Define DUMB_DN if your dn driver (801 acu) can't handle '=' character to wait for dialtone. .LI DEFAULT_BAUDRATE: This is the baud rate you want to use when both Systems file and Devices file allow "Any" .LI UUSTAT_TBL: There is a table in uustat.c that can hold all machine names that currently have work or execute files (C. or X.) or have a status file. If necessary, the table size can be changed. For machines with much memory, a large number like 1000 will not hurt much since the program is not executed often. For small machines, 256K memory, the number should be much smaller like 100. .LI UNAME: Define UNAME if uname() should be used to get uucpname; this will be defined automatically if ATTSV is defined. .LI RETRYTIME: This is the initial retry after failure time. Each successive failure will double the current retry time. Time is given in minutes. .LI MAXRETRYTIME: This is the high limit to the retry backoff. .LI PATH: This is the path that will be used for uuxqt command executions. .LI DEFAULTCMDS: This is the set of default commands that can be executed if none is given for the system name in PERMISSIONS file. It is a colon separated list as in PERMISSIONS file . .LI HZ: Define HZ to be the number of clock ticks per second; not needed for standard UNIX system. .LI MYNAME: Put in local uucp name of this machine if there is no "/etc/whoami" and no uname() call. This is not needed for standard UNIX systems. .LI NOSTRANGERS: Define NOSTRANGERS if you want to reject calls from systems that are not in your Systems file. If defined, NOSTRANGERS should be the name of the program to execute when such a system dials in. The argument to the program will be the name of the calling system. A shell procedure (remote.unknown) is supplied and installed in /usr/lib/uucp. .LI LMTUUXQT: Define LMTUUXQT to be the name of a file that contains the number (in ascii) of simultaneous uuxqt's that you will permit. If it is not defined, there may be "many" uuxqt's running. 2 is reasonable number. The system will create the default file and set the limit to 2. .LI LMTUUSCHED: Define LMTUUSCHED to be the name of a file that contains the number (in ascii) of simultaneous uusched's that you will permit. If it is not defined, there may be "many" uusched's running. 2 is reasonable number. The system will create the default file and set the limit to 2. The more you permit the higher the load on the system; each uusched has one uusched associated with it. .LI USRSPOOLLOCKS: Define USRSPOOLLOCKS if you like your lock files in /usr/spool/locks. Be sure other programs such as 'cu' and 'ct' know about this. .LI ASCIILOCKS: Define ASCIILOCKS if you like your lock files to contain ascii pids rather than binary representations. Remember cu and ct need to understand this. .LE 0707070000020023111006660001460001440000010341310357433053500002000000013653docs/AppendixII.P These are the ASSERT error messages that can occur. The will appear in the error log (/usr/spool/uucp/.Admin/errors). When the errors occur, the program will abort--the file name, sccsid, line number will appear in the error message along with the following text. In most cases, these result from file system problems; use the errno, when present to check out the problem. .P .VL 23 0 .LI "CAN'T OPEN" An open() or fopen() failed--``errno'' appears in () .LI "CAN'T WRITE" A write() or fwrite() or fprintf() etc--``errno'' appears in () .LI "CAN'T READ" A read(), fgets(), etc failed--``errno'' appears in () .LI "CAN'T CREATE" A creat() call failed--``errno'' appears in () .LI "CAN'T ALLOCATE" A dynamic allocation failed. .LI "CAN'T LOCK" An attempt to make a LCK (lock) file failed. In some cases, this is a fatal error. .LI "CAN'T STAT" A stat() call failed--``errno'' appears in () .LI "CAN'T CHMOD" A chmod() call failed--``errno'' appears in () .LI "CAN'T LINK" A link() call failed--``errno'' appears in () .LI "CAN'T CHDIR" A chdir() call failed--``errno'' appears in () .LI "CAN'T UNLINK" A unlink() call failed--``errno'' appears in () .LI "WRONG ROLE" This is an internal logic problem. .LI "CAN'T MOVE TO CORRUPTDIR" .br An attempt to move some bad C. or X. files to the .Corrupt directory failed--the directory is probably missing or has wrong modes or owner. (/usr/spool/uucp/.Corrupt) .LI "CAN'T CLOSE" A close() or fclose() call failed--``errno'' appears in () .LI "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 a software error. .LI "No uucp server" A tcp/ip call is attempted, but there is no server for uucp. .LI "BAD UID" The uid can not be found in the /etc/passwd file. The file system is in trouble, or the /etc/passwd file is inconsistant. .LI "BAD LOGIN_UID" same as previous. .LI "ULIMIT TOO SMALL" The ulimit for the current user/process is too small; file transfers may fail, so transfer is not attempted. .LI "BAD LINE" There is a bad line in the Devices file; there are not enough arguments on one or more lines. .LI "FSTAT FAILED IN EWRDATA" .br There is something wrong with the ethernet media. .LI "SYSLST OVERFLOW" An internal table in gename.c overflowed. A big/strange request was attempted--send it with MR to the appropriate place. .LI "TOO MANY SAVED C FILES" .br same as previous .LI "RETURN FROM fixline ioctl" .br An ioctl, which should never fail, failed. There is a system or driver problem. .LI "BAD SPEED" A bad line speed appears in the Devices/Systems files. .LI "PERMISSIONS file: BAD OPTION--" .br There is a bad line or option in the PERMISSIONS file. Fix it immediately! .LI "PKCGET READ" The other side probably hung up; don't worry about it. .LI "SYSTAT OPEN FAIL" There is a problem with the modes of /usr/lib/uucp/.Status, or there is a file with bad modes in the directory. .LI "TOO MANY LOCKS" There is some internal problem! Send in an MR. .LI "CAN NOT ALLOCATE FOR" .br There is some kernel problem; a call to calloc() failed. .LI "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 the program attempts this. .LI "CAN'T FORK" An attempt to fork and exec failed. The current job should not be lost, but will be attempted later (uuxqt). No action need be taken. .LE .SK These are the messages that will appear in the system status file: .VL 23 0 .LI "OK" Things are OK. .LI "NO DEVICES AVAILABLE" There is no currently available device for the call. Check to see that there is a valid device in Devices file for this system. .LI "WRONG TIME TO CALL" self explanatory .LI "TALKING" self explanatory .LI "SOME FAILURE" to be determined .LI "BAD SEQUENCE CHECK" If sequence checking is used between systems, the sequence numbers do not agree. (This is almost never used.) .LI "CALLER SCRIPT FAILED" The negotiations with the modem/network specified in the DIALERS file did not complete successfully. This is similar to DIAL FAILED. I may occassionally fail, but if it never succeeds, there may be a problem with the entry in the DIALERS file. .LI "LOGIN FAILED" The login for the given machine failed. It could be a wrong login/passwd, wrong number, a very slow machine, or failure in getting through the chat script. .LI "CONVERSATION FAILED" The conversation failed after successful startup. This usually means that one side went down, the program aborted, or the line just hung up. .LI "DIAL FAILED" The remote never answered. It could be a bad dialer or the wrong phone number. .LI "BAD LOGIN/MACHINE COMBINATION" .br The machine called us with login/machine name that does not agree with our PERMISSIONS file. They could be trying to masquerade! .LI "DEVICE LOCKED" The calling device is currently locked and in use by some process. .LI "ASSERT ERROR" An ASSERT error occurred--see /usr/spool/uucp/.Admin/errors. .LI "SYSTEM NOT IN Systems" The system name is not in Systems. .LI "CAN'T ACCESS DEVICE" The device tried does not exist, or the modes are wrong. .LI "DEVICE FAILED" The open of the device failed. .LI "WRONG MACHINE NAME" The called machine is reporting a different name in the Shere= message. .LI "CALLBACK REQUIRED" The called machine requires that it call us. .LI "REMOTE HAS A LCK FILE FOR ME" .br The remote site has a LCK file for this system. They could be trying to call us. If they have an older version of uucp, the process that was talking to us may have failed leaving the LCK file. If they have the new uucp, and they are not trying us, then the process that was talking to us is hung! .LI "REMOTE DOES NOT KNOW ME" .br The remote site does not have our name in their Systems file. .LI "REMOTE REJECT AFTER LOGIN" .br The login we used does not correspond to what the remote site is expecting. .LI "REMOTE REJECT, UNKNOWN MESSAGE" .br The remote site rejected us for unknown reason--they are probably not running a standard version of uucp. .LE 0707070000020023131006660001460001440000010341370357433053600002100000011302docs/AppendixIII.P The following list gives the program affected and a description of the change. .VL 15 0 .LI all The spool directory is now a tree with one directory for each active or recently accessed remote. The inactive directories are removed periodically. .LI all The error messages were cleaned up; ASSERT messages are standardized and they will now be put into an error log (/usr/spool/uucp/.Admin/errors). Other rare error messages will also appear in the file. The most common message is a PKXSTART message; it can be discounted, since it just means that the other side hung up in the middle of a conversation. .LI all All programs use \fIgetopt()\fR to read arguments. .LI uucp \-e option was removed; forwarding is specified in the same manner as with mail. .LI uucp Uucp is more robust; Files that the user can read, but are unreadable by others can now be sent; uucp will assume \-C option for these files. .LI uucico The locking mechanism was redone; non-active lock files will be automatically deleted when a program needs access to the facility. .LI uucico The retry time algorithm was changed; it now uses an exponential backoff instead of a constant time. In addition, the format and meaning of the retry time in the Systems (old name was L.sys) file changed; a ';' is used in place of the previously used ','. .LI uucico The conn routine in uucico was made much more flexible; it can now handle many more device types: develcon, ventel, micom switches and dialers. .LI uucico It can now talk over DATAKIT using either normal uucp protocol, or the DATAKIT protocol, which is much faster. (Some sites may not be able to use the DATAKIT protocol with uucp.) .LI uucico Uucico can now be compiled so that it will not converse with any site that is not in the local Systems file. (This is set in the parms.h file before compiling the uucp programs.) A shell called remote.unknown is provided that puts the name of the remote site into a file. The local administrator can change it to meet local needs. .LI uucico Uucico no longer will search for a system to call; rather, a new program ``uusched'' provides that function. .LI uuxqt One can now specify the commands available to a remote system by system name. .LI "uuxqt, uux" There is a more flexible and more informative error return mechanism; new options allow the return of standard input when commands fail. In addition, one can control error return notification for always, only when non-zero, or never. When notification is returned for error, stderr is returned with the error message. .LI uustat Uustat was completely rewritten; some of the old features are gone and some new features are added. .LI uulog The uulog program was removed and replaced by a shell; there are new features and old features were removed. .LI uucheck A new program was written to check the existence of all files required for execution of uucp programs. It is automatically run during installation; if failure occurs, the installation is discontinued. In addition, this program can be invoked by the administrator to produce an English interpretation of the Permissions file. .LI uusub Uusub was deleted. .LI uucleanup Uuclean was completely rewritten and renamed uucleanup. Using heuristics and knowledge of the structure and contents of various uucp generated files, \fIuucleanup\fRt tries to return undeliverable mail messages, execute rnews on ophan netnews data files, and gives specific date and file name information to the requester for requests that can not be executed due to failure to contact the remote in a given number of days. .LI uuxqt The number of uuxqt program running at one time is now controlled by a file in /usr/lib/uucp (Maxuuxqts). .LI uugetty A new program in included; it is a getty that can be used on ports that have dialers 801/212-103 or intelligent modems so that the port can be used for both input (getty) or output (uucico). .LI LOGFILE The file is no longer used; there is now a separate log file for each system and command. The uulog program knows about them as do the demons that take care of cleanup. Note also that the log messages have changed; they more clearly indicate what system and what files are being transmitted. .LI Systems The format of the direct line connections changed; the first field that had a tty number is now replaced by the word Direct. .LI Devices New fields were added to each line and some new type device lines are available. See documentation on the Systems, Devices files. .LI Permissions The USERFILE, used for security, was deleted; it was replaced by the Permissions file, which is easier to read, understand, and has more flexibility. A new document describes this feature. One important aspect is that permissions must be overtly granted, the default is for a high level of security. .LE 0707070000020023141006660001460001440000010341440357433054000002000000043105docs/AppendixIV.H 1 Introduction The Permissions file replaces the USERFILE for uucp. It's purpose is to specify the permission that remote sites have with respect to login, file access, and command execution. Options provide for restricting the ability to request files and the ability to receive files queued by the local site. In addition, an option is available to specify the commands that a remote site can execute on the local system. .P The next section gives three Permissions' file entries. Taken together, they provide all the entries needed by most sites running the uucp system. Section three gives the basics of the syntax and semantics of the Permissions file. The remainder of the documents gives a detailed explanation of the options available, their uses, and setting up the default values. .H 1 " Starting Examples" The first example is the model of an entry for the public login on your system; it represents the most restrictive access to your system. .HU "Example 1" .sp .nf LOGNAME=nuucp .fi .sp It states that login "nuucp" has all the default permissions/restrictions: .BL .LI The remote site can send files exclusively to the \fIuucp public\fR directory. (usually /usr/spool/uucppublic) .LI The remote site can \fInot\fR request to receive any files. .LI \fINo\fR files that are queued for the remote site will be transferred during the present session. .LI The only commands that can be executed are the defaults--usually "rmail". (See section 6 for details on how to set this default.) .LE .P This entry alone is sufficient to start communications with remote sites, permitting files to be transferred to the uucp public directory by request of the remote site. .HU "Example 2" The next entry is for remote sites that log in, but have fewer restrictions. The login and passwd corresponding to this entry should not be distributed to the general public; it is usually reserved for closely coupled systems where the Systems file information can be tightly controlled. .sp .nf LOGNAME=uucpz REQUEST=yes SENDFILES=yes \\ READ=/ WRITE=/ .fi .sp This entry provides the following permissions when a remote site logs in as "uucpz": .BL Files can be requested from the local site (REQUEST option). .LI Files can be transferred to any directory or any file that is writable by user "other"--that is a file/directory that is writable by a local user with neither owner nor group permissions. (Option WRITE controls this permission.) .LI Any files readable by user "other" can be requested. (Option READ controls this permission.) .LI Any requests queued by the local site will be executed during the conversation; these are requests by local users that are destined for the site that is calling in. (SENDFILES option). .LI The commands sent for execution on the local system by the remote must be in the default set ( usually "rmail"). .LE .HU "Example 3" Thus far, the examples showed entries that referred to remote sites when they log in to the local system. This example is an entry used when calling a remote site. .sp .nf MACHINE=mhtsa:mhtsb:mhtsc:pwbcc \\ REQUEST=yes READ=/ WRITE=/ .fi .sp When calling any of the systems given in the MACHINE list, the following permissions prevail: .BL .LI The remote site can both request and send files (REQUEST option). .LI The source or destination of the files on the local system can be anywhere in the file system. .LI The only commands that will be executed for the remote site are those in the default list. .LE .P Any site that is called that does not have its name in a MACHINE entry will have the default permissions as stated in "example 1" with the exception that files queued for that site will be sent (the SENDFILES option only has meaning in a LOGNAME entry). .P It is possible to put these three examples together to form a Permissions file that can be used by a system with a public login for remote sites and several closely coupled machines. .H 1 Basics Each \fIentry\fR is a logical line; physical lines are terminated with a "\\" to indicate continuation. Entries are made up of "white space" delimited \fIoptions\fR. Each option is a name/value pair; these are constructed by an option name followed by a "=" followed by the value. Note that \fIno\fR white space is allowed within an option assignment. .P Comment lines begin with '#'; they occupy the entire line up to a newline character. Blank lines are ignored (even within multi line entries). .P There are two types of entries: .BL .LI LOGNAME entries specify permissions for remote sites when they log in to the local machine. .LI MACHINE entries specify permissions for sites that the local machine call. .LE .P LOGNAME entries will contain a LOGNAME option. MACHINE entries will contain a MACHINE option. .H 1 "Some Rules" \fIRULE\fR:--All login ids used by remote sites to login for uucp \fImust\fR appear in one and only one LOGNAME entry. .P \fIRULE\fR:--Any site that is called whose name \fIdoes not\fR appear in a MACHINE entry in the Permissions file will have the following default permissions/restrictions: .BL .LI Local send and receive requests will be executed. .LI The remote can send files to the system's public uucp directory. .LI The commands sent by the remote for execution on the local machine must be in the default set--usually "rmail" and "rnews". .LE .H 1 "Options" This section give the details of each option, specifying how they are used and their default values. .HU "MACHINE" The MACHINE entry specifies the permissions that take effect when a remote site is called. .sp .nf MACHINE=mhtsa .fi .sp is the start of an entry that will specify the permissions associated with machine "mhtsa". The MACHINE option can contain a list of different system names, each separated by a ":". For example, .sp .nf MACHINE=mhtsa:mhtsb:mhtsc .fi .sp .HU "LOGNAME" The LOGNAME option specifies a list of login ids of remote sites that are able to log into the local system. The option contains one or more names separated by a ":". For example, .sp .nf LOGNAME=nuucp .sp .or LOGNAME=uucpz:uucyz .fi .sp Names that appear in LOGNAME options can appear in only one such option. .HU "REQUEST" The REQUEST option can appear in either a LOGNAME entry or a MACHINE entry and specifies whether the remote can make requests to receive local files. .sp .nf REQUEST=yes .fi .sp specifies that the remote \fIcan\fR request files. .sp .nf REQUEST=no .fi .sp specifies that the remote \fIcan not\fR request files. The latter is the default--it will be used if the REQUEST option is not specified. .HU "SENDFILES" SENDFILES specifies whether the \fIcalled\fR site will execute locally queued requests during the conversation. The default is that locally queued requests will not be executed during the call; they will be done only when the remote is \fIcalled\fR by the local system. (I don't care who you say you are, I'll send you queued files when I call you.) .P Clearly, this option is only significant in LOGNAME entries, since MACHINE entries apply when calls are made out to remote sites. In fact, the option is ignored when a MACHINE entry is being used. .sp .nf SENDFILES=yes .fi .sp specifies that the locally queued requests will be executed when the remote site logs in as one of the names in this entry's LOGNAME option. .P The default setting for the SENDFILE option is .sp .nf SENDFILES=call .fi .sp meaning that queued files will be sent only when I call you. This option can be specified for documentation purposes. .HU "READ and WRITE" The default for both the READ and WRITE options is the uucp public directory. The options .sp .nf READ=/usr/spool/uucppublic \\ WRITE=/usr/spool/uucppublic .fi .sp are the defaults and may be specified for documentation purposes. The options .sp .nf READ=/ WRITE=/ .fi .sp specify permission to access any file that can be accessed by a local user with "other" permissions. .P The value of these entries is a colon separated list of path names. The READ option is for requesting files and the WRITE option for depositing files. One of the values must be the prefix of any full path name of a file coming in or going out. .P To grant permission to deposit files in /usr/news as well as the public directory, specify .sp .nf WRITE=/usr/spool/uucppublic:/usr/news .fi .sp in the entry. .P \fIRULE\fR:--If the READ or WRITE option is specified, all the path names must be specified; these do not add to the default list. .HU "NOREAD and NOWRITE" There are two other options in the file access class, NOREAD and NOWRITE. These will rarely be used; they specify exceptions to the READ and WRITE options or defaults. .sp .nf READ=/ NOREAD=/etc \\ WRITE=/usr/spool/uucppublic .fi .sp This example would permit reading any file except those in the /etc directory (and its sub directories--remember these are prefixes) and writing only to the default /usr/spool/uucppublic directory. NOWRITE works the same way for sending files to the local system. .HU "CALLBACK - Is That Really You?" The CALLBACK option is used in LOGNAME entries to specify that no transaction will take place, but the calling system, as established during handshake, will be called back. .sp .nf CALLBACK=yes .fi .sp specifies this action. The default is .sp .nf CALLBACK=no .fi .sp The CALLBACK option will rarely be used. (Note that if two sites have this option set for each other, a conversation will never get started.) .HU "COMMANDS" WARNING!! \fI The COMMANDS option can be hazardous to the security of your system. Use it with extreme care. \fR The VALIDATE option should be used in conjunction with the COMMANDS option whenever potentially dangerous commands like "cat" and "uucp" are specified. Any command that reads or writes files is potentially dangerous to local security when executed by the uucp remote execution demon (uuxqt). .P The \fIuux\fR program will generate remote execution requests and queue them to be transferred to the remote site. Files and a command are sent to the target site. The COMMANDS option can be used in MACHINE entries to specify the commands that a remote machine can execute. .sp .nf COMMANDS=rmail:rnews .fi .sp This line indicates the commands that can be executed by the remote machine are either rmail or rnews exclusively. (The default list is specified in the "parms.h" header file during installation of uucp. The defaults settings will be discussed later.) The entry .sp .nf MACHINE=owl:raven:hawk:dove \\ COMMANDS=rmail:rnews:lp .fi .sp overrides the COMMAND default such that the command list for machines owl, raven, hawk, and dove now consists of "rmail", "rnews" and "lp". .HU "VALIDATE" \fIRULE\fR:--If you don't trust a caller's identity, don't let that system execute dangerous commands. .sp \fICOROLLARY\fR:--If you can't trust a site, don't give it a privileged login and passwd. .sp \fBWARNING!\fR Giving a site a special login, with file access and remote execution capability, is like giving anyone on that system a normal login. .P Use the VALIDATE option in connection with the COMMANDS option when specifying dangerous commands. It is used in LOGNAME entries to provide \fIsome\fR verification of the caller's identity. However, an important aspect of this validation is that the login/passwd associated with this entry be protected. If an outsider gets that information, the validation is not valid! .P Now that the warnings are out of the way, here is an example: .sp .nf LOGNAME=uucpfriend VALIDATE=eagle:owl:hawk .fi .sp This entry specifies that if a remote logs in and says that it is any of the specified birds, it must have logged in as "uucpfriend". As can be seen, if an outsider gets the uucpfriend login/passwd, masquerading is trivial. .P But what does this have to do with the COMMANDS option, which only appears in MACHINE entries? A short answer is that it connects the MACHINE entry that has the COMMANDS option with a protected login entry that appears in a LOGNAME option. This connection is needed because the execution demon is not running while the remote is logged in; it is in fact, an asynchronous process with no knowledge of what system sent the execution requests. .P Therefore, the real question is, how does the local site know who put the execution files (X. files created by the uux command on the remote site)? .P Each remote site has its own "spool" directory, with write permission only given to the uucp programs. The execution files from the remote site are put in its spool directory. Therefore, when the "uuxqt" demon program runs, it can use the spool directory name to find the MACHINE entry in the Permissions file and get the COMMANDS list, or if the machine name does not appear in the Permissions file, the default list will be used. Example .sp .nf MACHINE=mhtsa:mhtsb:mhtsc REQUEST=yes \\ COMMANDS=ALL \\ READ=/ WRITE=/ LOGNAME=uucpz VALIDATE=mhtsa:mhtsb:mhtsc \\ REQUEST=yes SENDFILES=yes \\ READ=/ WRITE=/ .fi .sp provides unlimited read, write, and command execution. The ALL value in the commands option means that any command can be executed! \fBWARNING\fR: Using the ALL value gives the remote site unlimited access to your system. In fact, files that are only readable or writable by user "uucp" (like Systems) can be accessed using commands like "ed". .P The assumption you make by the first entry above is that when you call mhtsa, mhtsb or mhtsc, you really know who you are talking to. Therefore, any files put into one of the "mhtsa", "mhtsb", or "mhtsc" spool directories is put there by one of those sites. If a remote site logs in and says they are one of these three systems, their execution files will also be put in the privileged spool directory. You therefore have to validate that the site has the privileged login "uucpz". .HU "COMMANDS revisited" The COMMANDS option specifies a list of commands that can be executed by remote machines. In addition to the names as specified above, they can be full path names of commands, for example .sp .nf COMMANDS=rmail:/usr/lbin/rnews:/usr/local/lp .fi .sp specifies that command "rmail" uses the default path, which is set up at uucp installation time--specified in the parms.h file. When the remote site specifies rnews or /usr/lbin/rnews for the command to be executed, /usr/lbin/rnews will be executed regardless of the default path. Likewise, /usr/local/lp is the lp command that will be executed. .P Including the "ALL" value in the list means that any command from the remote machine(s) specified in the entry will be executed. If you use this value, you give the remote machine full access to you machine! .sp .nf COMMANDS=/usr/lbin/rnews:ALL:/usr/local/lp .fi .sp This example illustrates two points. The ALL value can appear anywhere in the string. And, the path names specified for rnew and lp will be used if the requested command does not contain the full path names for rnews or lp. .H 1 "Who Am I?" When a remote calls, the called system responds with the local system name; this communicated in the \fIShere\fR message. There are some situations when a system may want to say it is someone else. First, for testing, this permits a system to call itself. Also, a series of systems can be made to look like one to the outside world, while retaining unique identities within a local network. .sp .nf LOGNAME=uucptest MYNAME=testing .fi .sp The local system will report its name as \fItesting\fR whenever a remote logs in as uucptest. .P This facility can also be used when calling out: .sp .nf MACHINE=testmach MYNAME=atest .fi .sp Tells the machine, \fItestmach\fR, that machine \fIatest\fR is calling. .H 1 "Public Directory" The public directory, \fI/usr/spool/uucppublic\fR, provides a tree for public access (by default, receiving files from sites.) One may want to have different public directories based on login ids. .sp .nf LOGNAME=loginA PUBDIR=/usr/spool/uucppublic/loginA LOGNAME=loginB PUBDIR=/usr/spool/uucppublic/loginB .fi .sp This can also be specified when remote machines are called: .sp .nf MACHINE=machineA PUBDIR=/usr/spool/uucppublic/machineA MACHINE=machineB PUBDIR=/usr/spool/uucppublic/machineB .fi .sp .H 1 "Default Settings" The parms.h header file contains some default settings that affect the Permissions file processing. The PATH manifest defines the PATH environment variable that will be set when remote commands are executed. A typical line is .sp .nf #define PATH "PATH=/bin:/usr/bin:/usr/lbin " /* */ .fi .sp The default list of commands is defined by .sp .nf #define DEFAULTCMDS "rmail" .fi .sp Another example is .sp .nf #define DEFAULTCMDS "rmail:rnews:xp:lp" .fi .sp These take effect if no COMMANDS option is specified for the machine that sent the remote execution. .H 1 "MACHINE Entry For Other Systems" An administrator may want to specify different option values for the machines it calls that are not mentioned in specific MACHINE entries. This may occur when there are many machines calling in, and the command set changes from time to time. For these cases, it is not convenient to change the DEFAULTCMDS as it would require a recompile. The name "OTHER" for the machine name is used for this entry. .sp .nf MACHINE=OTHER \\ COMMANDS=rmail:rnews:/usr/lbin/Photo:/usr/lbin/xp .fi .sp All other options available for the MACHINE entry may also be set for the machines that are not mentioned in other MACHINE entries. .H 1 "Combining MACHINE and LOGNAME Entries" It is possible to combine MACHINE and LOGNAME entries into a single entry where the common options are the same. For example, these two entries .sp .nf MACHINE=mhtsa:mhtsb:mhtsc REQUEST=yes \\ READ=/ WRITE=/ LOGNAME=uucpz REQUEST=yes SENDFILES=yes \\ READ=/ WRITE=/ .fi .sp share the REQUEST, READ, and WRITE options. They can be merged into one entry .sp .nf MACHINE=mhtsa:mhtsb:mhtsc REQUEST=yes \\ LOGNAME=uucpz SENDFILES=yes \\ READ=/ WRITE=/ .fi .sp that will take the place of the two entries. 0707070000020023171006660001460001440000010343360357433054000001400000007102docs/README Basic Networking Utilities Customer Information Documents Basic Networking Utilities Product Overview - release 1 # 307-038 Basic Networking Utilities Installation Guide and Release Notes - Release 1 # 307-036 Basic Networking Utilities - release 1 # 307-165 See the following for additional information: Permissions: an example of a Permissions file. (a default will be generated during the installation procedure. uucp.1c manual page for uucp uustat.1c: uustat man page uulog.1c: uulog man page uucleanup.1m: man page for uucleanup uugetty.1m man page for a getty that permits input/output on a port uudemon.hour: hourly demon uudemon.poll: polling demon uudemon.admin: to send messages about status to the administrator of uucp uudemon.cleanup: cleanup demon Some useful shells: Uutry: shell for debugging--starts uucico with debugging option Cvt: shell to move C. and D. files from /usr/spool/uucp to proper place for the new directory structure SetUp shell that copies old system files to the new places (L.sys etc) NOTE - this will be automatically run during installation Here are some pointers for converting to the new version: 1- There are some significant changes in L.sys (new name = Systems) format. a- For direct lines, the first device specification is changed from "ttyxx" to "Direct" b- On time fields where the default wait time was specified, the ',' must be changed to a ';' In addition, the time has a slightly different meaning. The retry algorithm is now an exponential backoff with initial time (RETRYTIME in parms.h) and max retrytime (MAXRETRYTIME in parms.h). If the ;time field is specified, that will always be the retry time. If it is not given, the backoff will be used. (SEE Basic Networking Utilities - release 1 # 307-165 for details) 2- The L-devices (new name=Devices) file must also be changed. a- All ACU lines must have "801" or the name of the modem (for example, penril) added to the end of the line. b- All DIR lines must have "DIR" changed to "Direct" and the work 'direct' added to the line. See the comments in the Devices file delivered with the source. (SEE Basic Networking Utilities - release 1 # 307-165 for details) 3- The uucico program no longer searches for a system to call, it must be called with a -s option. A new program, uusched, does the search for work and calls remotes in random order, by invoking uucico with -sSYSTEM option. (see uudemon.hour) Cron entries should be put into crontab for the demons. For example 39,9 * * * * /bin/su uucp -c "/usr/lib/uucp/uudemon.hour" > /dev/null 10 * * * * /bin/su uucp -c "/usr/lib/uucp/uudemon.poll" > /dev/null 45 23 * * * ulimit 5000; /bin/su uucp -c "/usr/lib/uucp/uudemon.cleanup" > /dev/null 48 10,14 * * 1-5 /bin/su uucp -c "/usr/lib/uucp/uudemon.admin" > /dev/null Note - It is best to run these demons from the root cron file. At a minimum, the uudemon.cleanup entry must be started as root since it must invoke a 'ulimit' command. For building the system: 1- Carefully go through the parms.h file to set it up for your environment. (SEE Basic Networking Utilities - release 1 # 307-165 for details) 2- During installation, a Permissions file will be created if one does not already exist. It will also make the needed directories, create some files in /usr/lib/uucp and install the uudemons. 3- The demons also send mail to someone (default uucp). Change as desired. Other misc: 0- SEE Basic Networking Utilities - release 1 # 307-165 to learn how to set up the Permissions file. A default one will be created by make install. 0707070000020023211006660001460001440000010343550361000511600002100000013506docs/README.7300This is release 2.0a of the Honey-Danber (HDB) communications subsystem for the AT&T UNIX PC 7300, system releases 2.0, 2.06, 2.96 and 3.0. It is Proprietary material of ATT-IS and must not be released outside AT&T without express written permission at director level. This version was distributed 1/6/86. Please report any bugs or problems to: S.Coffin mtuxn!3215sc {mtuxn!}fjsc!coffin Here are notes on this release: 1) cu and the uucp subsystem are included here. They are tested and are believed to work correctly. 2) uugetty is included, and has been tested. uugetty and the 7300 lockfile scheme are fully integrated, and should correctly handle contentions with the 7300 telephone manager and terminal emulator. However, there are several problems with uugetty on the 7300, because of bugs in the 7300 device drivers. When uugetty is used on the built-in tty port (/dev/tty000) on the 7300, outgoing cu or uucp jobs over the port may fail with a "device busy" error even when the port is idle. Also, you cannot use uugetty on the console, but only on the phone and RS232 ports. (Windows don't work right when uugetty is used on the console. We're not sure why this is, but it may be the result of a permissions problem with /dev/window. We're investigating!) Remember that you may need to change the login sequence in the L.sys files of systems that call into uugetty, since you may set it up to expect a character to start the login sequence. We'd appreciate input from users of uugetty with the 7300 "combo board." 3) ct is included, and is slightly tested. We'd appreciate input from any ct users out there! 4) This release includes support for the STARLAN network. you must already have installed and configured the STARLAN system software before you can use HDB with it. The uucp system and "cu" will work over STARLAN, but "ct" will not. 5) This release of HDB for the 7300 is 2.0a. It should install correctly on the 2.0, 2.06, 2.96, and 3.0 releases of the 7300 software system. The executable programs should also work with 2.01, 2.06, 2.2, 2.32, 2.91 and other releases higher than 2.0, but the administative shell programs that interface with the 7300 User Agent will probably not work correctly. It WILL NOT WORK with 7300 releases 5.3, 1.5, or 1.6. 6) When you install the HDB programs, be sure that no uucp or remote mail jobs are running, since the install procedure will not overwrite an executing program. Also be sure that there are no queued jobs, since the install procedure deletes the queue. 7) The HDB install procedure overwrites the old executable programs with the same names, both in /usr/bin and in /usr/lib/uucp. It also deletes the directory /usr/spool/uucp and rebuilds it. Files in /usr/lib/uucp that have different names are not touched. The HDB install procedure makes NO BACKUP of the old uucp stuff that is overwritten. If you want to save the old uucp system, you will have to make your own backup. Save everything in the /usr/lib/uucp and /usr/spool/uucp directories and subdirectories, and these files in /usr/bin: cu uucp uuto uupick uux uulog uuname uustat Lsys.sh Phones.sh RSfree.sh RS232.sh 8) When HDB is installed, the status feature of the EMAIL package ("CT Mail"), versions 2.01 and 3.0, will be broken. The EMAIL program changes /usr/bin/uux and /usr/bin/Lsys.sh from the originals, and these are also changed by the installation of the HDB package. If you have the 2.01 or 3.0 version of EMAIL, then install it first, then install the HDB package on top. 9) The administative shell programs that interface between the 7300 User Agent and the HDB Systems and Devices files are included, but like their counterparts in the default 7300 uucp system, they probably will begin to fail if you do anything slightly unusual with the setup. You must take care when you use tricky configurations for unusual devices and "chat" scripts. The included shell programs are /usr/bin/Lsys.sh, /usr/bin/RS232.sh, /usr/bin/RSfree.sh, and /usr/bin/Phones.sh. You must set up your Permissions, Dialcodes, Poll, and other HDB files manually. 10) The /usr/lib/uucp/L.sys file is still required for proper operation of the telephone manager. However, it can be of the new format. So, for best results link Systems and L.sys together, using the new Systems file as the master. This is done within the "Electronic Mail Names of Other Systems" feature (/usr/bin/Lsys.sh), if you use the User Agent Administration tools. If you edit the Systems file manually, you will have to make sure that /usr/lib/uucp/L.sys and /usr/lib/uucp/Systems are the same. The other HDB files can replace their older equivalents. 11) You may need entries in /etc/passwd for BOTH uucp and nuucp. Use these lines (or similar): uucp::5:6:uucp:/usr/spool/uucppublic:/usr/lib/uucp/uucico nuucp::6:6:uucp:/usr/spool/uucppublic:/usr/lib/uucp/uucico uucpadm: NOPE :7:6:Uucp Administration:/usr/lib/uucp: These should be in the standard /etc/passwd file, but if remote systems can't log in, check these first! 12) You may need to modify the uudemon lines in /usr/lib/crontab. uudemon.hr is now called uudemon.hour, uudemon.day is now called uudemon.admin, and uudemon.wk is now called uudemon.cleanu. The install procedure for HDB will make these changes for you. You might wish to look over these shells (located in /usr/lib/uucp) to be sure they meet your needs. 13) We think that the phone setup section of Aministration Hardware Setup will work correctly, and the system will use the phone lines in the same way that the default system uses them. The HDB lock files are located in /usr/spool/uucp, NOT /usr/spool/locks, to keep compatibility with the 7300 phone manager. Good luck, and thanks for your help in testing and improving this material. A popular movement in favor of HDB will make it easier to include it in the default UNIX PC system. =sc 0707070000020023221006660001460001440000010343740357433054200001600000002326docs/Uutry.1m.TH UUTRY 1M .SH NAME Uutry \- try to contact remote system with debugging on .SH SYNOPSIS .B /usr/lib/uucp/Uutry [ .B \-x debug_level ] [ .B \-r ] system_name .SH DESCRIPTION .I Uutry is a shell that is used to invoke .I uucico to call a remote site. Debugging is turned on (default is level 5); .B \-x will override that value, and can be a single digit between 0 and 9; higher numbers give more detailed debugging information. (The .B -DSMALL option severely limits the amount of debugging that is compiled into the program. \fB-DSMALL\fR is the default compilation option.) The .B \-r overrides the retry time in .BR /usr/spool/uucp/.Status . The debugging output is put in file \fB/tmp/\fIsystem_name\fR. A tail \fB\-f\fR of the output is executed. A or will give control back to the terminal while the \fIuucico\fR continues to run, putting its output in \fB/tmp/\fIsystem_name\fR. .SH FILES .nf /usr/lib/uucp/Systems /usr/lib/uucp/Permissions /usr/lib/uucp/Devices /usr/lib/uucp/Dialers /usr/lib/uucp/Dialcodes /usr/lib/uucp/Maxuuxqts /usr/lib/uucp/Maxuuscheds /usr/spool/uucp/* /usr/spool/locks/LCK* /usr/spool/uucppublic/* /tmp/system_name .fi .SH "SEE ALSO" uucico(1M), uucp(1C), uux(1C). .\" @(#)Uutry.1m 4.1 0707070000020023311006660001460001440000010343760357433054200001300000006002docs/ct.1c.tr ~ .TH CT 1C .SH NAME ct \- spawn getty to a remote terminal .SH SYNOPSIS .B ct [ .BR \-w " n" ] [ .BR \-x " n" ] [ .B \-h ] [ .B \-v ] [ .BR \-s " speed" ] telno ... .SH DESCRIPTION .I Ct\^ dials the telephone number of a modem that is attached to a terminal, and spawns a .I getty\^ process to that terminal. .I Telno\^ is a telephone number, with equal signs for secondary dial tones and minus signs for delays at appropriate places. (The set of legal characters for \fItelno\fR is 0 thru 9, -, =, *, and #. The maximum length .I telno is 31 characters). If more than one telephone number is specified, .I ct\^ will try each in succession until one answers; this is useful for specifying alternate dialing paths. .PP .I Ct\^ will try each line listed in the file .B /usr/lib/uucp/Devices until it finds an available line with appropriate attributes or runs out of entries. If there are no free lines, .I ct\^ will ask if it should wait for one, and if so, for how many minutes it should wait before it gives up. .I Ct\^ will continue to try to open the dialers at 1-minute intervals until the specified limit is exceeded. The dialogue may be overridden by specifying the .BI \-w n\^ option, where .I n\^ is the maximum number of minutes that .I ct\^ is to wait for a line. .PP The .BI \-x n\^ option is used for debugging; it produces a detailed output of the program execution on stderr. The debugging level, .IR n , is a single digit between 0 and 9; .BR \-x 9\^ is the most useful value. .PP Normally, .I ct\^ will hang up the current line, so the line can answer the incoming call. The .B \-h option will prevent this action. If the .B \-v option is used, .I ct\^ will send a running narrative to the standard error output stream. .PP The .B -v option is turned off if the program is compiled with .B -DSMALL option (default compilation option). .PP The data rate may be set with the .B \-s option, where .I speed\^ is expressed in baud. The default rate is 1200. .PP After the user on the destination terminal logs out, there are two things that could occur depending on what type of getty is on the line (\fIgetty\fR or \fIuugetty\fR). For the first case, .I ct\^ prompts, \fBReconnect?\fP~ If the response begins with the letter \fBn\fP, the line will be dropped; otherwise, .I getty\^ will be started again and the \fBlogin:\fP prompt will be printed. In the second case, there is already a getty (\fIuugetty\fR) on the line, so the \fBlogin:\fP message will appear. .PP Of course, the destination terminal must be attached to a modem that can answer the telephone. .SH FILES /usr/lib/uucp/Devices .br /usr/lib/uucp/Dialers .br /usr/adm/ctlog .SH "SEE ALSO" cu(1C), login(1), uucp(1C). .br getty(1M), uugetty(1M) in the .IR "\s-1UNIX\s+1 System V Administrator Reference Manual" . .SH BUGS For a shared port, one used for both dial-in and dial-out, the .I uugetty program running on the line must have the .B \-r option specified [see \fIuugetty\fR(1M)]. However, .I ct will not work when .I uugetty is used with an intelligent modem. .tr ~~ .\" @(#)ct.1c 4.1 0707070000020023351006660001460001440000010344040357433054300001300000020232docs/cu.1c.TH CU 1C .SH NAME cu \- call another\s-1 UNIX\s+1 system .SH SYNOPSIS .B cu .RB [\| \-s " speed\|]" .RB [\| \-l " line\|]" .RB [\| \-h \|] .RB [\| \-t \|] .RB [\| \-d \|] .RB [\| \-o | .BR \-e \|] .RB [\| \-n \|] telno .br .B cu .RB [\| \-s " speed\|]" .RB [\| \-h \|] .RB [\| \-d \|] .RB [\| \-o | .BR \-e \|] .BR \-l " line" .br .B cu .RB [\| \-h \|] .RB [\| \-d \|] .RB [\| \-o | .BR \-e \|] systemname .SH DESCRIPTION .I Cu\^ calls up another \s-1UNIX\s+1 system, a terminal, or possibly a non-\s-1UNIX\s+1 system. It manages an interactive conversation with possible transfers of .SM ASCII files. .PP .I Cu accepts the following options and arguments: .TP 12 \&\f3\-s\fR\fIspeed\fR Specifies the transmission speed (300, 1200, 2400, 4800, 9600). The default value is "Any" speed which will depend on the order of the lines in the \fB/usr/lib/uucp/Devices\fR file. Most modems are either 300 or 1200 baud. Directly connected lines may be set to a speed higher than 1200 baud. .TP \&\f3\-l\fR\fIline\fR Specifies a device name to use as the communication line. This can be used to override the search that would otherwise take place for the first available line having the right speed. When the \fB\-l\fR option is used without the \fB\-s\fR option, the speed of a line is taken from the Devices file. When the \fB\-l\fR and \fB\-s\fR options are both used together, cu will search the Devices file to check if the requested speed for the requested line is available. If so, the connection will be made at the requested speed; otherwise, an error message will be printed and the call will not be made. The specified device is generally a directly connected asynchronous line (e.g., \fB/dev/ttyab\fR) in which case a telephone number (\fItelno\fR) is not required. If the specified device is associated with an auto dialer, a telephone number must be provided. Use of this option with .I systemname rather than .I telno will not give the desired result (see \fIsystemname\fR below). .TP .B \-h Emulates local echo, supporting calls to other computer systems which expect terminals to be set to half-duplex mode. .TP .B \-t Used to dial an ASCII terminal which has been set to auto answer. Appropriate mapping of carriage-return to carriage-return-line-feed pairs is set. .TP .B \-d Causes diagnostic traces to be printed. .TP .B \-o Designates that odd parity is to be generated for data sent to the remote system. .TP .B \-e Designates that even parity is to be generated for data sent to the remote system. .TP .B \-n For added security, will prompt the user to provide the telephone number to be dialed rather than taking it from the command line. .TP .I telno When using an automatic dialer, the argument is the telephone number with equal signs for secondary dial tone or minus signs placed appropriately for delays of 4 seconds. .TP .I systemname A uucp system name may be used rather than a telephone number; in this case, .I cu will obtain an appropriate direct line or telephone number from .B \%/usr/lib/uucp/Systems. .sp Note: the \fIsystemname\fR option should not be used in conjunction with the \fB\-l\fR and \fB\-s\fR options as .I cu\^ will connect to the first available line for the system name specified ignoring the requested line and speed. .P After making the connection, .I cu\^ runs as two processes: the .I transmit\^ process reads data from the standard input and, except for lines beginning with .BR ~ , passes it to the remote system; the .I receive\^ process accepts data from the remote system and, except for lines beginning with .BR ~ , passes it to the standard output. Normally, an automatic \s-1DC\s+1\&3/\s-1DC\s+1\&1 protocol is used to control input from the remote so the buffer is not overrun. Lines beginning with .B ~ have special meanings. .PP The .I transmit\^ process interprets the following user initiated commands: .TP 20 .B ~. terminate the conversation. .TP .B ~! escape to an interactive shell on the local system. .TP .BI ~! cmd\|.\|.\|. execute .I cmd\^ on the local system (via .BR "sh \-c" ). .TP .BI ~$ cmd\|.\|.\|. run .I cmd\^ locally and send its output to the remote system for execution. .TP \&\f3~%cd\fP change the directory on the local system. .sp Note: .B ~!cd will cause the command to be run by a subshell, probably not what was intended. .TP \&\f3~%take\fP \|\f2from\fP \|[ \|\f2to\fP \|] copy file .I from\^ (on the remote system) to file .I to\^ on the local system. If .I to\^ is omitted, the .I from\^ argument is used in both places. .TP \&\f3~%put\fP \|\f2from\fP \|[ \|\f2to\fP \|] copy file .I from\^ (on local system) to file .I to\^ on remote system. If .I to\^ is omitted, the .I from\^ argument is used in both places. .sp For both \fB~%take\fR and \fBput\fR commands, as each block of the file is transferred, consecutive single digits are printed to the terminal. .TP \&\f3~~\fB \|\fIline\fR send the line .BR ~ .I line to the remote system. .TP \&\f3~%break\fP transmit a .B BREAK to the remote system (which can also be specified as .BR ~%b ). .TP .B ~%debug toggles the .BR -d debugging option on or off (which can also be specified as .BR ~%d ). .TP .B ~t prints the values of the termio structure variables for the user's terminal (useful for debugging). .TP .B ~l prints the values of the termio structure variables for the remote communication line (useful for debugging). .TP .B ~%nostop toggles between \s-1DC\s+1\&3/\s-1DC\s+1\&1 input control protocol and no input control. This is useful in case the remote system is one which does not respond properly to the \s-1DC\s+1\&3 and \s-1DC\s+1\&1 characters. .PP The .I receive\^ process normally copies data from the remote system to its standard output. Internally the program accomplishes this by initiating an output diversion to a file when a line from the remote begins with \f3~>\fP. .P Data from the remote is diverted to .IR file on the local system. The trailing \f3~>\fP marks the end of the diversion. .PP The use of .B ~%put requires .IR stty (1) and .IR cat (1) on the remote side. It also requires that the current erase and kill characters on the remote system be identical to these current control characters on the local system. Backslashes are inserted at appropriate places. .PP The use of .B ~%take requires the existence of .IR echo (1) and .IR cat (1) on the remote system. Also, .I tabs mode [see .I stty(1)] should be set on the remote system if tabs are to be copied without expansion to spaces. .PP When .I cu is used on system X to connect to system Y and subsequently used on system Y to connect to system Z, commands on system Y can be executed by using ~~. Executing a tilde command reminds the user of the local system uname. For example, uname can be executed on Z, X, and Y as follows: .br .sp .RS uname .br Z .br ~[X]!uname .br X .br ~~[Y]!uname .br Y .br .RE .sp In general, .B ~ causes the command to be executed on the original machine; .B ~~ causes the command to be executed on the next machine in the chain. .SH EXAMPLES To dial a system whose telephone number is 9 1 201 555 1212 using 1200 baud (where dial tone is expected after the 9): .RS cu \-s 1200 9=12015551212 .RE .PP If the speed is not specified, "Any" is the default value. .PP To login to a system connected by a direct line: .RS cu \-l /dev/ttyXX .RE .PP or .RS cu \-l ttyXX .RE .PP To dial a system with the specific line and a specific speed: .RS cu \-s 1200 \-l ttyXX .RE .PP To dial a system using a specific line associated with an auto dialer: .RS cu \-l culXX 9=12015551212 .RE .PP To use a system name: .RS cu systemname .br .SH FILES .br /usr/lib/uucp/Systems .br /usr/lib/uucp/Devices .br /usr/spool/locks/\s-1LCK\s+1..(tty-device) .SH SEE ALSO cat(1), ct(1C), echo(1), stty(1), uname(1), uucp(1C). .SH DIAGNOSTICS Exit code is 0 for normal exit, otherwise, -1. .SH WARNINGS .I Cu\^ cannot be used from the 3B20 system console. .I Cu\^ does not do any integrity checking on data it transfers. .br Data fields with special .I cu\^ characters may not be transmitted properly. Depending on the interconnection hardware, it may be necessary to use a .B ~. to terminate the conversation even if .B stty 0 has been used. .P There is an artificial slowing of transmission by .I cu\^ during the .B ~%put operation so that loss of data is unlikely. .\" @(#)cu.1c 4.2 0707070000020023471006660001460001440000010344270357433054400002000000002464docs/uucheck.1m.TH UUCHECK 1M .SH NAME uucheck \- check the uucp directories and permissions file .SH SYNOPSIS .B /usr/lib/uucp/uucheck [ .B \-v ] [ .B \-x debug_level ] .SH DESCRIPTION .I Uucheck checks for the presence of the \fIuucp\fR system required files and directories. Within the \fIuucp\fR makefile, it is executed before the installation takes place. It also checks for some obvious errors in the Permissions file (\fB/usr/lib/uucp/Permissions\fR). When executed with the \fB\-v\fR option, it gives a detailed explanation of how the uucp programs will interpret the Permissions file. The \fB\-x\fR option is used for debugging; it takes a single digit, higher numbers for more detail. Note , however, that compiling .I uucp with the .B -DSMALL option will result in little debugging output ( .B DSMALL is the default compliation option). Note that \f3uucheck\f1 can only be executed by the superuser. .SH FILES .nf /usr/lib/uucp/Systems /usr/lib/uucp/Permissions /usr/lib/uucp/Devices /usr/lib/uucp/Maxuuscheds /usr/lib/uucp/Maxuuxqts /usr/spool/uucp/* /usr/spool/locks/LCK* /usr/spool/uucppublic/* .fi .SH "SEE ALSO" uucico(1M), uusched(1M), uucp(1C), uustat(1C), uux(1C). .SH BUGS The program does not check file/directory modes or some errors in the Permissions file such as duplicate login or machine name. .\" @(#)uucheck.1m 4.1 0707070000020023521006660001460001440000010344350357433054400001700000002264docs/uucico.1m.TH UUCICO 1M .SH NAME uucico \- file transport program for the uucp system .SH SYNOPSIS .B /usr/lib/uucp/uucico [ .B \-r role_number ] [ .B \-x debug_level ] .br .B \-s system_name .SH DESCRIPTION .I Uucico is the file transport program for \fIuucp\fR work file transfers. Role numbers for the \f3\(mir\f1 option are the digit 1 for master mode or 0 for slave mode (default). The .B \-r option should be specified as the digit 1 for master mode when .I uucico is started by a user, program, or .I cron. .I Uux and .I uucp both queue jobs that will be transferred by .I uucico. It is normally started by the scheduler, .I uusched but can be started manually; this is done for debugging. For example, the shell .I Uutry starts .I uucico with debugging turned on. A single digit must be used for the .B \-x option with higher numbers for more debugging. .SH FILES .nf /usr/lib/uucp/Systems /usr/lib/uucp/Permissions /usr/lib/uucp/Devices /usr/lib/uucp/Dialcodes /usr/lib/uucp/Dialers /usr/lib/uucp/Maxuuxqts /usr/lib/uucp/Maxuuscheds /usr/spool/uucp/* /usr/spool/locks/LCK* /usr/spool/uucppublic/* .fi .SH "SEE ALSO" cron(1M), uusched(1M), Uutry(1M), uucp(1C), uustat(1C), uux(1C). .\" @(#)uucico.1m 4.1 0707070000020023531006660001460001440000010344400357433054500002200000005125docs/uucleanup.1m.\"@(#)uucleanup.1m 5.2 .TH UUCLEANUP 1M .SH NAME uucleanup \- uucp spool directory clean-up .SH SYNOPSIS .B /usr/lib/uucp/uucleanup [ .B \-C time ] [ .B \-D time ] [ .B \-W time ] [ .B \-X time ] [ .B \-m time ] [ .B \-o time ] [ .B \-s system ] .SH DESCRIPTION .I Uucleanup\^ will scan the spool directories for old files and take appropriate action to remove them in a useful way: Inform the requester of send/receive requests for systems that cannot be reached. Return mail, which cannot be delivered, to the sender. Delete or execute rnews for rnews type files (depending on where the news originated locally or remotely). Remove all other files. In addition, there is provision to warn users of requests that have been waiting for a given number of days (default 1). Note that .I uucleanup will process as if all option .I times were specified to the default values unless \fItime\fR is specifically set. .PP The following options are available. .TP 10 .BI \-C time\^ Any \fBC.\fR files greater than or equal to \fItime\fR days old will be removed with appropriate information to the requester (default 7 days). .TP .BI \-D time\^ Any \fBD.\fR files greater than or equal to \fItime\fR days old will be removed. An attempt will be made to deliver mail messages and execute rnews when appropriate (default 7 days). .TP .BI \-W time\^ Any \fBC.\fR files equal to \fItime\fR days old will cause a mail message to be sent to the requester warning about the delay in contacting the remote. The message includes the \fIJOBID\fR, and in the case of mail, the mail message. The administrator may include a message line telling whom to call to check the problem (\fB\-m\fR option) (default 1 day). .TP .BI \-X time\^ Any \fBX.\fR files greater than or equal to \fItime\fR days old will be removed. The \fBD.\fR files are probably not present (if they were, the \fBX.\fR could get executed). But if there are \fBD.\fR files, they will be taken care of by D. processing (default 2 days). .TP .BI \-m string\^ This line will be included in the warning message generated by the .B \-W option. .TP .BI \-o time\^ Other files whose age is more than .I time\^ days will be deleted (default 2 days). The default line is "See your local administrator to locate the problem". .TP .BI \-s system\^ Execute for \fIsystem\fR spool directory only. .PP This program is typically started by the shell \fIuudemon.cleanup\fR, which should be started by .IR cron (1M). .SH FILES .TP 20 /usr/lib/uucp directory with commands used by .I uucleanup\^ internally .TP /usr/spool/uucp spool directory .SH SEE ALSO cron(1M), uucp(1C), uux(1C). .\" @(#)uucleanup.1m 4.1 0707070000020023601006660001460001440000010344470357433054700001500000014135docs/uucp.1c'\" t .TH UUCP 1C .SH NAME uucp, uulog, uuname \- \s-1UNIX\s+1 system-to-\s-1UNIX\s+1 system copy .SH SYNOPSIS .B uucp [ options ] source-files destination-file .br .B uulog [ options ] .BR \-s " system" .br .B uulog [ options ] .BR \-f " system" .br .B uuname [ .B \-l ] .SH DESCRIPTION .SS Uucp .I Uucp\^ copies files named by the .I source-file\^ arguments to the .I destination-file\^ argument. A file name may be a pathname on your machine, or may have the form: .PP .RS system-name!path-name .RE .PP where .I system-name\^ is taken from a list of system names that .I uucp\^ knows about. The destination .I system-name\^ may also be a list of names such as .PP .RS system-name!system-name!...!system-name!path-name .RE .PP in which case, an attempt is made to send the file via the specified route to the destination. Care should be taken to ensure that intermediate nodes in the route are willing to forward information. (See \fBWARNINGS\fR below for restrictions.) .PP The shell metacharacters .B ? , .B \(** , and .B [\|.\|.\|.\|] appearing in .I path-name\^ will be expanded on the appropriate system. .PP Pathnames may be one of: .PP .RS .TP 5 (1) a full pathname. .TP 5 (2) a pathname preceded by .BI ~ user\^ where .I user\^ is a login name on the specified system and is replaced by that user's login directory. Note that if an invalid login is specified, the default will be to the public directory (\fB/usr/spool/uucppublic\fR). .TP 5 (3) a pathname preceded by .BI ~/ destination\^ where .I destination\^ is appended to .BR /usr/spool/uucppublic. .sp \fBNOTE:\fR This destination will be treated as a file name unless more than one file is being transfered by this request or the destination is already a directory. To ensure that it is a directory, follow the destination with a '/'. For example, ~/dan/ as the destination will make the directory /usr/spool/uucppublic/dan if it does not exist and put the requested file(s) in that directory. .TP 5 (4) anything else is prefixed by the current directory. .RE .PP If the result is an erroneous pathname for the remote system, the copy will fail. If the .I destination-file\^ is a directory, the last part of the .I source-file\^ name is used. .ig If a simple .I ~user\^ destination is inaccessible to .IR uucp , data is copied to a spool directory and the user is notified by .IR mail (1). .. .PP .I Uucp\^ gives 0666 read and write permissions [see .IR chmod (2)] and preserves execute permissions across the transmission. .PP The following options are interpreted by .IR uucp : .TP 10 .B \-c Do not copy local file to the spool directory for transfer to the remote machine (default). .TP .B \-C Force the copy of local files to the spool directory for transfer. .TP .B \-d Make all necessary directories for the file copy (default). .TP .B \-f Do not make intermediate directories for the file copy. .TP .BI \-g grade \fIGrade\fR is a single letter/number; lower ASCII sequence characters will cause the job to be transmitted earlier during a particular conversation. (The default is 'N'.) .TP .B \-j Output the job identification \s-1ASCII\s+1 string on the standard output. This job identification can be used by .I uustat\^ to obtain the status or terminate a job. .TP .B \-m Send mail to the requester when the copy is completed. .TP .BI \-s file\^ Report status of the transfer to .I file.\^ Note that the .I file must be a full pathname. .TP .BI \-n user\^ Notify .I user\^ on the remote system that a file was sent. .TP .B \-r Do not start the file transfer; just queue the job. .TP .BI \-x debug_level Produce debugging output on standard output. The \fIdebug_level\fR is a number between 0 and 9; higher numbers give more detailed information. Note, however, that if the program is compiled with the .B \-DSMALL option, there will be little debugging output ( .B \-DSMALL is the default compilation option). .SS Uulog .PP .I Uulog\^ queries a log file of .I uucp\^ or .I uuxqt transactions in a file .BI /usr/spool/uucp/.Log/uucico/ system .br or .BI /usr/spool/uucp/.Log/uuxqt/ system. .ne 3 .PP The options cause .I uulog to print logging information: .TP 10 .BI \-s system Print information about file transfer work involving system \fIsystem\fR. .TP .BI \-f system Does a ``tail \fB\-f\fR'' of the file transfer log for \fIsystem\fR. .P Other options used in conjunction with the above: .TP .B \-x Look in the \fIuuxqt\fR log file for the given system. .TP .BI \- number Indicates that a ``tail'' command of .I number lines should be executed. .SS Uuname .PP .I Uuname\^ lists the \fIuucp\fR names of known systems. The .B \-l option returns the local system name. .SH FILES .TP 28 /usr/spool/uucp spool directories .TP /usr/spool/uucppublic/\(** public directory for receiving and sending (/usr/spool/uucppublic) .TP /usr/lib/uucp/\(** other data and program files .SH SEE ALSO mail(1), uustat(1C), uux(1C). .br uuxqt(1M) in the .IR "\s-1UNIX\s+1 System V Administrator Reference Manual" . .SH WARNINGS The domain of remotely accessible files can (and for obvious security reasons, usually should) be severely restricted. You will very likely not be able to fetch files by pathname; ask a responsible person on the remote system to send them to you. For the same reasons you will probably not be able to send files to arbitrary pathnames. As distributed, the remotely accessible files are those whose names begin .B /usr/spool/uucppublic (equivalent to .BR ~/ ). .PP All files received by .I uucp\^ will be owned by .IR uucp . .br The \fB\-m\fP option will only work sending files or receiving a single file. Receiving multiple files specified by special shell characters \fB? \(** \fRand \fB\|[\|.\|.\|.\|]\fP will not activate the \fB\-m\fP option. .P The forwarding of files through other systems may not be compatible with the previous version of \fIuucp\fR. If forwarding is used, all systems in the route must have the same version of \fIuucp\fR. .SH BUGS Protected files and files that are in protected directories that are owned by the requester can be sent by .IR uucp . However, if the requester is root and the directory can not be searched by "other" or the file can not be read by "other", the request will fail. .\" @(#)uucp.1c 4.2 0707070000020023611006660001460001440000010344650357433055300001400000117255docs/uucp.D....mm -t -rC3 this document .ND "September 15, 1984" .EH "'10/18/84'UUCP ADMINISTRATION''" .OH "''UUCP ADMINISTRATION'10/18/84'" .H 1 "UUCP ADMINISTRATION" .H 2 "INTRODUCTION" .P This chapter describes how a \fBuucp\fR network is set up, the format of control files, and administrative procedures. Administrators should be familiar with the manual pages for each of the \fBuucp\fR related commands. .H 2 "PLANNING" .P In setting up a network of UNIX systems, there are several considerations that should be taken into account \fIbefore\fR configuring each system on the network. The following parts attempt to outline the most important considerations. .H 3 "Extent of the Network" .P Some basic decisions about access to processors in the network must be made before attempting to set up the configuration files. If an administrator has control over only one processor and an existing network is being joined, then the administrator must decide what level of access should be granted to other systems. The other members of the network must make a similar decision for the new system. The UNIX system \fIpassword\fR mechanism is used to grant access to other systems. The file \fI/usr/lib/uucp/Permissions\fR provides various permissions/restrictions for file system tree access and command execution from remote machines, and the file \fI/usr/lib/uucp/Systems\fR (old name was \fI/usr/lib/uucp/L.sys\fR) on the local processor determines the systems on the network that can be directly reached. .P When setting up more than one processor, the administrator has control of a larger portion of the network and can make more decisions about the setup. For example, the network can be set up as a private network where only those machines under the direct control of the administrator can access each other. Granting no access to machines outside the network can be done if security is paramount; however, this is usually impractical. Very limited access can be granted to outside machines by each of the systems on the private network. Alternatively, access to/from the outside world can be confined to only one processor. This is frequently done to minimize the effort in keeping access information (passwords, phone numbers, login sequences, etc.) updated and to localize the security holes for the private network. .H 3 "Hardware and Line Speeds" .P There are several supported means of interconnection by \fBuucp\fR(1), .AL .LI Direct connection using a null modem. .LI Connection over the Direct Distance Dialing (DDD) network using various dialers (e.g. WECo 801, Ventel, Vadic, Penril). .LI Connection using a DATAKIT\*(Tm VCS. .FS "" DATAKIT is a trademark of AT&T. .FE .LI A UNET\*(EMEthernet\*(Tm network. .FS "" Ethernet is a trademark of Xerox Corporation. .FE .LE .P In choosing hardware, the equipment used by other processors on the network must be considered. For example, if some systems on the network have only 103-type (300-baud) data sets, then communication with them is not possible unless the local system has a 300-baud data set connected to a calling unit. (Most data sets available on systems are 1200-baud.) If hard-wired connections are to be used between systems, then the distance between systems must be considered since a null modem cannot be used when the systems are separated by more than several hundred feet. The limit for communication at 9600-baud and 19200-baud is about 800 to 1000 feet. However, the RS232 specification and Western Electric Support Groups allow for up to 50 feet. Limited distance modems must be used beyond 50 feet as noise on the lines becomes a problem. .H 4 "Setting Up ACU Devices" Create a device in the /dev directory corresponding to the port of the ACU. .DS mknod /dev/tty10 c 1 6 .DE will create the ACU device on tty10 which has major and minor device numbers 1 and 6. This will correspond to the following entry in /usr/lib/uucp/Devices .DS ACU tty10 - 1200 penril .DE if a penril modum is placed on tty10. If the ACU is to work at 300 baud as well, add .DS ACU tty10 - 300 penril .DE to the /usr/lib/uucp/Devices file. The major device number of the device interface type on your machine (for example, tn4 for the 3B 20) can be found in /etc/master. Minor device numbers are assigned consecutively from 0 to n. .P Next execute a chown command and chmod command for that device. .DS chown uucp /dev/tty10 chmod 644 /dev/tty10 .DE (If you do not require a new device entry, it is possible to change ownership of an existing device to uucp without executing the mknod command.) .P This same procedure will work for other intelligent modems that have a standard RS-232 interface. .P For 212/801 type modems, an additional device is required -- the 801 device. First create the 212 port as above. For example .DS mknod /dev/cul1 c 1 6 chown uucp /dev/cul1 chmod 644 /dev/cul1 .DE Next, create a separate node for the 801 by executing a mknod command. For example .DS mknod /dev/cua1 c 7 1 chown uucp /dev/cul1 chmod 644 /dev/cua1 .DE The corresponding /usr/lib/uucp/Devices entry for this ACU would look like .DS ACU cul1 cua1 1200 801 .DE Note that for 801/212 type modems, only one speed is allowed; it can not be configured to work at both speeds when calling out. .H 4 "Setting Up /etc/inittab" After the ports are set up, entries should be put into /etc/inittab corresponding to the devices. Typically, these ports are configured for outgoing traffic only, in which case, the action field of the /etc/inittab entry is in the "off" state. .P However, with the new version of uucp, they can be configured to work in both directions. This is accomplished by using a different "getty" command called "/usr/lib/uucp/uugetty". Using uugetty as shown below, the port will allow incoming and outgoing traffic when the device is available. NOTE - at this time however, the ct command will not work on ports that have the /usr/lib/uucp/uugetty running. If ct is to be used, the state of the /etc/inittab entry must be "off". .P An entry for tty10 as set up above with getty would be .DS 10:off:/etc/getty tty10 1200 # outgoing ACU entry .DE This entry is basically for information since the status is off. If this were to be bidirectional (with uugetty), it would be .DS 10:respawn:/usr/lib/uucp/uugetty -r -t60 tty10 1200H # bidirectional ACU .DE Note here that in the speed field there is an H after the speed. This corresponds to the 1200H /etc/gettydefs entry which does not set HUPCL in the initial flags for the line. If the HUPCL flag was set, some intelligent modems would drop DTR causing the "uugetty" to exit. Here is a typical /etc/gettydefs entry for the 1200H case. .DS 1200H# B1200 # B1200 SANE IXANY TAB3 HUPCL #login: #300H .DE whereas the 1200 entry would be .DS 1200# B1200 HUPCL # B1200 SANE IXANY TAB3 #login: #300 .DE In addition, notice that there is a -r option on the uugetty command. The -r option is needed to inhibit the echo of the "login" prompt until a character is read; this is due to the fact that on intelligent modems, the DTR will come up as soon as the open is executed and the uugetty would not be able to determine whether the process was calling in or out. Also, if there was a direct line as shown below with uugettys running on both sides, the "login" prompt would be read by both sides as a user attempting to login and would get into a loop. .P The -t60 option in the inittab entry is the same as for normal getty (optional). .H 4 "Setup for Direct Lines" The procedure for establishing the port is the same as above: .DS mknod /dev/tty23 c 1 23 chown uucp /dev/tty23 chmod 644 /dev/tty23 .DE However, there are different entries in /usr/lib/uucp/Devices for direct lines. Also, where entries in /usr/lib/uucp/Systems for the ACU devices have the word "ACU" in the device field (field 3), entries for direct lines have an keyword that identifies the particular line (the remote machine name is often used for the purpose). For example, a Systems file entry for a direct line might be: .DS robin Any robin Any - login--login nuucp sswrd: xyz .DE Notice that the third field is the device identifier that will appear in the first field of the Devices file and the fifth field (where the phone number would appear for an "ACU" entry) is a place holder (-). The Devices file entry for this direct line would be .DS robin tty23 - 9600 direct .DE The /etc/inittab entries for direct lines are the same as for ACUs as discussed above. Bidirectional traffic would be set up using uugetty as described above. .H 3 "Maintenance and Administration" .P There is a minimum amount of maintenance that must be provided on each system to keep the access files updated, to ensure that the network is running properly, and to track down line problems. When more than one system is involved, the job becomes more difficult because there are more files to update and because users are much less patient when failures occur between machines that are under local control. A tool, \fIuustat\fR, is available to aid the administrator by providing information about the last attempts to contact various systems and the age and number of jobs in the queue for remote systems. .P There is also a new cleanup program, \fBuucleanup\fR, that knows about the different type files that could get left in the spool directories. It uses some heuristics in an attempt to give the users relevant information about failures, for example, it tries to return undeliverable mail messages to the sender. In addition, for send/receive requests, it tells the requestor what was attempted by giving specific file names. The program is started by \fBuudemon.cleanup\fR, which provides some addition cleanup functions. See the \fIuucleanup.1m\fR manual page for details. .H 2 "UUCP SOFTWARE" .P Figure 10-1 (at the end of this chapter) illustrates the daemons used by the \fBuucp\fR network to communicate with another system. The \fBuucp\fR(1) or \fBuux\fR(1) commands queue users' requests and spawn the \fBuucico\fR daemon to call another system. Figure 10-2 (at the end of this chapter) illustrates the structure of \fBuucico\fR and the tasks that it performs in communicating with another system. \fBUucico\fR initiates the call to another system and performs the file transfer. On the receiving side, \fBuucico\fR is invoked to receive the transfer. Remote execution jobs are actually done by transferring a command file to the remote system and invoking a daemon (\fBuuxqt\fR) to execute that command file and return the results. .H 2 "INSTALLATION" .P The \fBuucp\fR(1) package is delivered as part of the standard UNIX system distribution. It resides in its own subdirectory (called \fIuucp\fR) in the commands area and has its own make file (\fIuucp.mk\fR). The \fBuucp\fR package is installed as part of the normal distribution; however, if it must be reinstalled for any reason, then the sequence .DS I make \-f uucp.mk install .DE should be executed. In addition, the distribution has default setting for uucp system parameters, such as the available communication media. If there are local differences, the \fIparms.h\fR file should be modified before the ``make'' command is executed. (See appendix I for details of the options for the parms.h file.) .H 3 "Object Modules" .P The following object modules are installed as part of the \fBuucp\fR make procedure. .AL .LI \fBUucp\fR\*(EMThe file transfer command. .LI \fBUux\fR\*(EMThe remote execution command. .LI \fBUucico\fR\*(EMThe \fBuucp\fR network daemon. .LI \fBUustat\fR\*(EMNetwork status command. .LI \fBUusched\fR\*(EMFile tranfer daemon scheduler. .LI \fBUucheck\fR\*(EMThe \fIuucp\fR system files, directories, and Permissions file checker. .LI \fBUuxqt\fR\*(EMThe remote execution daemon. .LI \fBUugetty\fR\*(EMA getty that can be used for lines/modems that are to work as dialin and dialout ports. .LI \fBUulog\fR\*(EMA shell for looking at the various log files. .LI \fBUutry\fR\*(EMA shell for administrators that is used to try a remote system with debugging options. Note that the name has the first letter in upper case (Uutry). .LI Several shell procedures are also distributed; these are started periodically by \fIcron\fR. \fBUudemon.cleanup\fR is usually executed daily to clean up various directories. \fBUudemon.hour\fR is used to start the file transfer scheduler and the command execution daemon. \fBUudemon.admin\fR is available to send data to the uucp administrator giving information about the status of the system. And \fBuudemon.poll\fR is used for periodic polling of remote systems. .LE .H 3 "Password File" .P To allow remote systems to call the local system, password entries must be made for any \fBuucp\fR logins. For example, .DS \s-1nuucp:zaaAA:6:1:UUCP.Admin:/usr/spool/uucppublic:/usr/lib/uucp/uucico\s+1 .DE Note that the \fBuucico\fR daemon is used for the shell, and the spool directory is used as the working directory. .P There must also be an entry in the \fIpasswd\fR file for a \fBuucp\fR administrative login. This login is the owner of all the \fBuucp\fR object and spooled data files and is usually ``uucp''. For example, the following is a entry in \fI/etc/passwd\fR for this administrative login: .DS I uucp:zAvLCKp:5:1:UUCP.Admin:/usr/lib/uucp: .DE Note that the standard shell is used instead of \fBuucico\fR. If an owner other than ``uucp'' is chosen, the \fImake\fR file for \fBuucp\fR (\fI/usr/src/cmd/uucp/uucp.mk\fR) must be edited. The line "OWNER=uucp" must be changed to reflect the new owner login. .H 3 "Devices File" .P The file \fI/usr/lib/uucp/Devices\fR (old name was \fI/usr/lib/uucp/L-devices\fR) contains the device information needed for calling other systems. The format of the file is .ml | .DS I Caller Line Line2 Class Dialer-Token-Pairs .DE where each field is .VL 18 4 .LI \fICaller\fR The keywords available in this field are .VL 9 0 .LI Direct for a hard-wired line used by cu for direct connections. .LI ACU to make the connection through an autodialer. .LI \fINETWORK\fR to make the connection through a switch where \fINETWORK\fR is replaces by one of Sytek, Unetserver, DK, Sytek, TCP. .LI \fISYSTEM-NAME\fR for hard-wired connections to a particular system where \fISYSTEM-NAME\fR is replaced by the name of the system. .LE .LI \fILine\fR This is the device name for the line (e.g., \fIttyab\fR for a direct line or hard-wired line to a system, \fIcul0\fR for a line connected to an ACU). .LI \fILine2\fR If the ACU keyword is specified and the device type is 801, this field contains the device name of the 801 dialing device ACU. Otherwise, the field is ignored; however, a placeholder must be used in this field (use '-' character for the placeholder). .ml .LI \fIClass\fR For ACU, this can be just the speed, or it can contain a letter and speed (e.g. D1200, C1200) to differentiate between classes of dialers (Centrex, Dimension). Some devices can be used at any speed, so the keyword ``Any'' is used\*(EMthis line will match any speed requested in Systems. Note: If this field is ``Any'' and the Systems class field is ``Any'' then the speed is taken from the default set in \fIparms.h\fR by the \fIDEFAULT_BAUDRATE\fR constant. (The Class field is currently ignored if an X.25 link is used.) .ml | .LI \fIDialer-Token-Pairs\fR The rest of the line contains pairs of dialers and tokens. Each pair represents a caller function and an argument to pass to that function. (The last token may be left blank if it is to represent a phone number. See examples below.) Dialers that are supported are .VL 18 0 .LI 801 standard 801 autodialer with 212 or 103 modem. .LI penril this is a penril autodialer. .LI hayes this is a hayes autodialer. .LI ventel this is a ventel autodialer. .LI vadic this is a vadic dialer. .LI \fINETWORK\fR one of the names listed for \fINETWORK\fR above. .LI \fIOTHER-DIALERS\fR other dialers can be constructed by putting information in the \fIDialers\fR file. See \fIDialers\fR section below. .LE .P The token following the Dialer can usually be left blank; this represents the phone number. The string ``\\D'' can be used in place of the blank; it means use the phone number given in the \fISystems\fR file as the argument to the dialer routing. .P It is possible to have dialout modems on networks. For these cases, the \fICaller\fR will be ACU and the \fIDialer-Token-Pair\fR will be the token given to the network routine to attach to the dialout modem. These two fields will be followed by another \fIDialer-Token-Pair\fR, the dialer routine name (e.g. ventel) and the phone number (e.g. ``\\D'' or ``\\T'' or blank.) .LE .P The following examples illustrate various types of connections: .TS l l l l l . ACU cul0 cua0 1200 801 ACU cul1 cua1 300 801 ACU vn0 - 1200 ventel ACU vn0 - 300 ventel ACU vd0 - 1200 vadic ACU vd0 - V1200 vadic ACU pn2 - 1200 penril ACU pn2 - 300 penril .TE .ml .P /dev/cul0 and /dev/cul1 are 212 modems (cul1 may be a 103 type), with 801s at /dev/cua0 and /dev/cua1 respectively; /dev/vn0 is hooked to a ventel and can be used at 1200 or 300 baud, and /dev/vd0 is hooked to a vadic. There are two entries for vadic so that sites that speak vadic tones only can be flagged V1200 in \fISystems\fR. (Actually, this assumes the vadic is a triple, because sites that talk 212 tones will get the vadic as well as these two entries.) There is also a penril dialer on /dev/pn2; it can be used at either 300 or 1200 baud. .P .ml | .tr ~\\ .TS l l l l l . ACU culd0 - Any develcon vent ventel ~D ACU culd1 - Any develcon vent ventel ~D .TE .tr ~ .P There are two ventel attached to the develcon; the line is culd0. The ``vent'' is the token given to the develcon switch to get to the ventel modem. The ``\\D'' specifies the telephone number from the \fISystems\fR file. .P Note: In addition to the ``\\D'', there will sometimes be a need for passing a phone number to a built-in routine (e.g. DK) after it is expanded using the \fIDialcodes\fR file. In this case, a ``\\T'' symbol is used instead of the ``\\D''. For example .TS l l l l l . ACU - 0 Any DK dial.\T .TE .P is an entry for using a dialer on a Datakit network. .P .TS l l l l l . raven ttyab - 9600 direct Direct ttyab - 9600 direct cbgbd x25.s0 - 9600 direct .TE .P There is a direct lines, one (ttyab) is a null-modem type connection with the other end on system raven while the second (x25.s0) is an X.25 permanent virtual circuit connection to machine cbgbd. Note also the ``Direct'' line; this is used if a user would like to use the command .DS cu -lttyab .DE to connect to machine ``raven''. .H 4 "Naming Conventions" .P It is often useful when naming lines that are directly connected between systems or that are dedicated to calling other systems to choose a naming scheme that conveys the use of the line. In the earlier examples, the name \fIttyab\fR is used for the line that directly connects two systems named \fIa\fR and \fIb\fR. Similarly, lines associated with calling units are best given names that relate them to the calling unit autodialer (note the names \fIcul0\fR and \fIcua0\fR to specify the line and calling unit, respectively). .H 3 "Dialers" .P Each line in the \fIDialers\fR file is used to specify the initial handshaking that should occur on a line before it is made available for user data. This initial handshaking is usually a sequence of ascii strings that are transmitted and expected, and is often used to dial a phone number using an ascii dialer (such as a PENRIL 300/1200AD) or connect via a dataswitch to another system on the dataswitch. If the fifth field in the Devices file line is not a built-in function name, the field is used as an index into the \fIDialers\fR file, attempting to match the first field on each line. In addition, each odd numbered field starting with the 7th position is used as an index into the ``Dialers'' file. .P If the match succeeds, the ``Dialers'' line is interpreted to perform the dialer negotiations. Field 1 match the 5th and additional odd numbered fields in the ``Devices'' file. The second field is used as a translate string: the first of each pair of characters in the string is mapped to the second character in the pair in the phone number to be dialed. This is usually used to translate = and \- into whatever the dialer requires for ``wait for dialtone'' and ``pause''. .P The remaining fields are ``expect''/``send'' strings (seethe ``login'' section for an explaination of expect-send fields.) Here are some sample line; these will be distributed with the system and installed as part of the installation procedures. The administrator can modify them as required. The escape characters, those beginning with ``\\'', have the same meaning as specified in the ``Login'' section of the ``Systems'' file below. In addition to those mentioned in that section, the `\\T'' and ``\\D'' are used to substitute the phone number string passed to the dialing function: ``\\T'' is expanded using the ``Dialcodes'' file and ``\\D'' is the unexpanded string. .P .nf .tr ~\\ penril =W-P "" ~d > s~p9~c )-W~p~r~ds~p9~c-) y~c : ~E~TP > 9~c OK ventel =&-% "" ~E~r~e~p $-~E~r~e~p-$ ~c ONLINE! vadic =K-K "" ~005~p *-~005~p-*~005~p-* D~p BER? ~E~T~e ~r~c LINE develcon "" "" ~pr~ps~c est:~007 ~D ~007 direct .fi .P The \fIpenril\fR entry executes as follows: First the phone number argument is translated, replacing any ``='' with a ``W'' (wait for dialtone) and replacing any ``\-'' with a ``P'' (pause). .P The handshake given by the remainder of the line works as follows: .VL 18 0 .tr ~" .LI ~~ Wait for nothing. .LI ~d .tr ~\\ Delay for 2 seconds. .LI > Wait for a >. .LI s~p9~c send an ``s'', pause for 1 seconds, send a 9, send no terminating new-line. .LI )\-W~p~r~ds~p9~c\-) wait for a ``)''. If it does not arrive, process the string between the ``\-'' characters as follows. Send a ``W'', pause, send a carriage-return, delay, send an ``s'', pause, send ``9'', without a new-line, and then wait for the ``)''. .LI y~c send a ``y''. .LI : wait for a ``:''. .LI ~E~TP enable echo checking. (From this point on, whenever a character is transmitted, will wait for the character to be received before doing anything else.) Then send the phone number followed by a penril \fIpause\fR character. (The ~Tmeans take the phone number passed as argument and apply the ``Dialcodes'' translation and the modem function translation specified by field number 2 of this entry.) .LI > wait for a ``>''. .LI 9~c send a ``9'' without a new-line. .LI OK Wait for the string ``OK''. .LE .P As another example, consider the \fIdevelcon\fR entry: The is phone number is the token used by the switch, for example the machine name to be connected.) .VL 18 0 .LI "" wait for nothing. .LI ~pr~ps pause, send an ``r'', pause, send an ``s''. .LI est:~007 wait for the string ``est:'' followed by a bell character (~007). .LI ~T send the token passed from the \fIDevices\fR file; often the token in the phone number field from the .ml \fISystems\fR file. .LI ~007 wait for a bell. .LE .P The ``direct'' line above indicates that for direct connections, ne negotiation is required. .H 3 "System File" .P Each entry in the \fI/usr/lib/uucp/Systems\fR file represents a system that can be called by the local \fBuucp\fR programs. In addition, the system can be configured to prevent any system that does not appear in this file from logging in. (This is the default configuration; it can be modified by changing ``parms.h'' before compilation.) More than one line may be present for a particular system; the additional lines represent alternative communication paths that will be tried in sequential order. The fields are described below. .VL 18 4 .LI "\fISystem name\fR" Name of the remote system. .LI \fITime\fR This is a string that indicates the days-of-week and times-of-day when the system should be called (e.g., MoTuTh0800\-1730). .P The day portion may be a list containing \fISu\fR, \fIMo\fR, \fITu\fR, \fIWe\fR, \fITh\fR, \fIFr\fR, \fISa\fR; or it may be .I Wk for any week-day or .I Any for any day. The time should be a range of times (e.g., 0800\-1230). If no time portion is specified, any time of day is assumed to be allowed for the call. Note that a time range that spans 0000 is permitted; 0800-0600 means all times are allowed \fIexcept\fR times between 6 and 8 am. Multiple time fields may be include using a ``,'' separator (e.g. Wk1800-0600,Sa,Su). An optional subfield is available to specify the minimum time (minutes) before a retry following a failed attempt. (Note that if this subfield is used, it will override the normal exponential backoff algorithm for retry upon failure.) This subfield is separated by a ``;''. .LI \fICaller\fR The available callers are ACU, Micom, Develcon, Sytek. .LI \fIClass\fR This is usually the line speed for the call (e.g., 300, 1200, Any). If the field is not used for a particular entry, a ``\-'' can be used as the place holder. When the value is ``Any'', it means match any speed found for the particular caller. If both the Systems and Devices value is ``Any'', then the value is taken from the \fIDEFAULT_BAUDRATE\fR constant defined in \fIparms.h\fR. .LI \fIPhone\fR For autodialers, the phone number is made up of an optional alphabetic abbreviation (dialing prefix) and a numeric part. The abbreviation should be one that appears in the .I "Dialcodes (old name was L-dialcodes)" file (e.g., mh1212, boston555\-1212). For direct connections, the phone field is ignored. (A ``\-'' should be used as a place holder.) .P For \fINETWORK\fR access as mentioned above such as \fISwitch\fR, \fIDevelcon\fR, and \fIMicom\fR, the phone field is the token the switch needs to get to the particular system\*(EMit is used by the caller functions specified in the ``Devices'' file. .LI \fILogin\fR The login information is given as a series of fields and subfields in the format .DS I [ expect\ \ send ] .\|.\|. .DE where \fIexpect\fR is the string expected to be read and .I send is the string to be sent when the .I expect string is received. This is simimilar processing to the negotiation specified in the ``Dialers'' file. The expect field may be made up of subfields of the form .DS I expect[\-send\-expect] .\|.\|. .DE where the .I send is sent if the prior .I expect is .I not successfully read and the .I expect following the .I send is the next expected string. (For example, login--login will expect .I login ; if it gets it, the program will go on to the next field; if it does not get .I login , it will send .I null followed by a new line, then expect .I login again.) If no characters are initially expected from the remote machine, the string ``""'' (a null string) should be used in the first expect field. Note that all send fields will be sent followed by a new-line unless the send string is terminated with a \\c. .sp There are two special names available to be sent during the login sequence. The string .I EOT will send an EOT character, and the string \fIBREAK\fR will try to send a \fIBREAK\fR character. .LE .P There are several character strings that cause specific actions when they are a part of a string sent during the login sequence. .VL 10 2 .tr ~\\ .LI ~K insert a BREAK. .LI ~N Send a null character. .LI ~b Send a backspace character. .LI ~c If at the end of a string, suppress the new-line that is normally sent. Ignored otherwise. .LI ~d Delay two seconds before sending or reading more characters. .LI ~n Send a new-line character. .LI ~p insert a pause (1 second). .LI ~r Send a carrage-return. .LI ~s Send a space character. .LI ~t Send a tab character. .LI ~~ Send a ~ character. .LI EOT Send \fIeot\fR character (actually \fIeot\fR new-line is sent twice). .LI BREAK Send a break character. .LI ~ddd Collapse the octal digits (ddd) into a single character and send that character. .br .tr ~~ .LE .P These character strings are useful for making \fBuucp\fR communicate via direct lines to data switches. .P A typical entry in the \fISystems\fR file would be .DS I sys\ \ Any\ \ ACU\ \ 300\ \ mh7654\ \ login\-\-login\ \ uucp\ \ ssword:\ \ word .DE A \fISystems\fR file entry for a direct connection would be .DS I hawk\ \ Any\ \ hawk\ \ 9600\ \ \-\ \ login\-\-login\ \ uucp\ \ ssword:\ \ word .DE The corresponding \fIDevice\fR file entry would be .DS I hawk\ \ ttyhh\ \ \-\ \ 9600\ \ direct .DE The ``expect'' algorithm matches all or part of the input string as illustrated in the password field above. .H 3 "Dialing Prefixes" .P This file contains the dial-code abbreviations used in the .I Systems file (e.g., py, mh, boston). The entry format is .DS I abb\ \ dial-seq .DE where .I abb is the abbreviation and .I "dial-seq" is the dial sequence to call that location. .P The line .DS I py\ \ 165\- .DE would be set up so that entry py7777 would send 165\-7777 to the dial unit. .H 3 "Permissions File" The Permissions file replaces the USERFILE for uucp. (The USERFILE was used in previous version of uucp to specify file access permissions). Its purpose is to specify the permission that remote sites have with respect to login, file access, and command execution. Options provide for restricting the ability to request files and the ability to receive files queued by the local site. In addition, an option is available to specify the commands that a remote site can execute on the local system. .P The installation procedure will construct a default file if one does not already exist in \fI/usr/lib/uucp/Permissions\fR. This default file will provide a high degree of restriction on remote sites. A line will be constructed for each login in the \fI/etc/passwd\fR file that has \fI/usr/lib/uucp/uucico\fR as the shell field. Each line will look like .DS CB LOGNAME=nuucp .DE .P It states that login ``nuucp'' has all the default permissions/restrictions: .BL .LI The remote site can send files exclusively to the \fI/usr/spool/uucppublic\fR directory tree. .LI The remote site can \fINOT\fR request to receive any files. .LI \fINO\fR files that are queued for the remote site will be transferred during the present session. .LI The only commands that can be executed are the defaults. (The default commands are set in parms.h. The distribution has them set to \fIrmail\fR and \fIrnews\fR.) (See appendix IV for full details of the \fIPermissions\fR file setup.) .LE .H 3 "Maxuuxqts File" The \fI/usr/lib/uucp/Maxuuxqts\fR file limits the number of simultaneous \fIuuxqt\fR programs running; it contains an ASCII number. The installation procedure sets the number to two; the administrator may want to change this number to meet local needs. If you get a lot of traffic from mail or netnews, you may want to increase the number to decrease wait time. But remember, the more you have running, the higher the load on the system. .H 3 "Maxuuscheds File" The \fI/usr/lib/uucp/Maxuuscheds\fR file limits the number of simultaneous \fIuusched\fR programs running; it contains an ASCII number. Each \fIuusched\fR running will have one \fIuucico\fR associated with it; limiting the number will throttle the load on the system. The limit should be less than the number of outgoing lines used by uucp; a smaller number is often desirable. The installation procedure sets the number to two; the administrator may want to change this number to meet local needs. But remember, the more you have running, the higher the load on the system. .H 3 "remote.unknown Shell" This shell program is called when a remote site that is not in the \fISystems\fR file calls in to start a conversation. The shell distributed with the system appends the name and time information to a file, \fI/usr/spool/uucp/.Admin/Foreign\fR. The calling of the shell can be turned off by an option in parms.h. In addition, the shell can be modified to meet local needs. As distributed, it contains the following: .DS I FOREIGN=/usr/spool/uucp/.Admin/Foreign echo "`date`: call from system $1" >> $FOREIGN .P Since it is a shell, it can be easily modified. For example, it can send mail to the administrator. .DE .H 3 "uudemon Shells" .P .H 2 "ADMINISTRATION" .P The role of the \fIuucp\fR administrator depends heavily on the amount of traffic that enters or leaves a system and the quality of the connections that can be made to and from that system. For the average system, only a modest amount of traffic (100 to 200 files per day) pass through the system and little if any intervention with the \fIuucp\fR automatic cleanup functions is necessary. Systems that pass large numbers of files (200 to 10,000) may require more attention when problems occur. The following parts describe the routine administrative tasks that must be performed by the administrator or are automatically performed by the \fIuucp\fR package. The part on problems describes what are the most frequent problems and how to effectively deal with them. .H 3 "Cleanup" .P The biggest problem in a dialup network like \fIuucp\fR is dealing with the backlog of jobs that cannot be transmitted to other systems. The following cleanup activities should be routinely performed. .H 4 "Cleanup of Undeliverable Jobs" .P The \fIuustat\fR program should be invoked regularly to give information about the status of connection to various machines, and the size and age of the queued requests. The \fBuudemon.admin\fR shell should be started by \fBcron\fR(1) at least once per day\*(EMthis will send the administrator the current status. Of particular interest are the age (in days) of the oldest request in each queue, the number of times failure to reach that system has occurred, and the reason for failure. In addition, the age of the oldest execution request (X. file) is also given. .P Each spool directory will contain some X. files, C. files, and D. files. When work can not be accomplished, these files should be removed. The \fBuucleanup\fR program, which is run from \fBuudemon.cleanup\fR will provide this function. Options to \fBuucleanup\fR specify the age for sending a warning message to the requestor and age for deleting the various file. Note that before deleting, the program tries to figure out what the job was (e.g. a mail job) and if possible, tries to send it to the receiver, rather than the sender. If this is not possible, it gets returned to the sender. For plain file transfers, the requestor is informed of the file name(s), date, and destination of the request. .H 4 "Cleanup of the Public Area" .P In order to keep the local file system from overflowing when files are sent to the public area, the \fBuudemon.cleanup\fR procedure is set up with a \fBfind\fR command to remove any files that are older than 7 days and directories that are empty. This interval may need to be shortened if there is not sufficient space to devote to the public area. .P Since the spool directories are very dynamic, they may grow large before transfers take place, it is a good idea to reorganize the structure. The best way to do this is to put some code in \fI/etc/rc\fR to be executed once per week. For example .DS I # # clean up /usr/spool/uucp # Most cleanup is now done by uudemon.cleanup # so just do copy out and back # DY=`date +'%w'` HR=`date +'%H'` echo "cleanup uucp spool directories" echo "FULL CLEANUP ONLY ON MONDAY before 9am " if [ $DY -eq 1 -a $HR -lt 9 ] then echo "MONDAY--DO FULL CLEANUP!" cd /usr/spool/uucp mkdir ../nuucp chown uucp ../nuucp chgrp uucp ../nuucp find . -print|cpio -pdml ../nuucp cd .. mv uucp ouucp mv nuucp uucp rm -rf ouucp fi chown uucp /dev/cu[al]* chgrp uucp /dev/cu[al]* chmod 0644 /dev/cul* chmod 0222 /dev/cua* # cleanup uucp LCK files so that a new # process doesn't accidently get a pid # corresponding to a left around LCK file-- # thus preventing it from being removed. echo "cleanup /usr/spool/locks" rm -f /usr/spool/locks/* echo "done uucp directory cleanup" .DE .H 4 "Compaction of Log Files" .P This version of \fBuucp\fR has individual log files for each system and each program (e.g. system \fIeagle\fR has a logfile for \fIuucico\fR requests and a logfile for \fIuuxqt\fR execution requests). The \fIuulog\fR shell gives the user access to the information in these files by system name. These files are combined and stored in directory \fI/usr/lib/uucp/.Old\fR whenever \fBuudemon.cleanup\fR is executed. The daemon saves two days files; this can be easily changed by the administrator. If space is a problem, the administrator might consider reducing the number of days the files are kept, or modify the shell to compact the files using the \fBpack\fR command. .H 3 "Polling Other Systems" .P Systems that are passive members of the network must be polled by other systems in order for their files to be sent. This can be arranged by using the \fBuudemon.poll\fR shell. \fBUudemon.poll\fR read the \fI/usr/lib/uucp/Poll\fR file which contains the systems and times to poll them. The lines contain the name of the remote to call followed by a TAB character and then a space separated list of times to poll. For example, .sp eagle 0 4 8 12 16 20 .sp will provide polling of system eagle every four hours. Note that \fBuudemon.poll\fR does not actually do the poll, it merely sets up a polling C. file in the spool directory that will be seen by the scheduler started by \fBuudemon.hour\fR. .H 3 Problems .P The following sections list the most frequent problems that appear on systems that make heavy use of \fBuucp\fR(1). .H 4 "Out of Space" .P The file system used to spool incoming or outgoing jobs can run out of space and prevent jobs from being spawned or received from remote systems. The inability to receive jobs is the worse of the two conditions. When file space does become available, the system will be flooded with the backlog of traffic. .H 4 "Bad ACU and Modems" .P The ACU and incoming modems occasionally cause problems that make it difficult to contact other systems or to receive files. These problems are usually readily identifiable since the status files accessed by \fBuustat\fR give counts and reasons for contact failure. If a bad line is suspected, it is useful to use the \fBcu\fR(1) command to try calling another system using the suspected line. This method could also be used to check the login/password information and phone number. .H 4 "Administrative Problems" .P Some \fBuucp\fR networks have so many members that it is difficult to keep track of changing passwords, changing phone numbers, or changing logins on remote systems. This can be a very costly problem since ACU's will be tied up calling a system that cannot be reached. .H 2 "DEBUGGING" .P In order to verify that a system on the network can be contacted, the \fBuucico\fR daemon can be invoked from a user's terminal directly. A shell procedure \fBUutry\fR is distributed for this purpose; the administrator will have to install it in an appropriate place. For example, to verify that \fImhtsd\fR can be contacted, try .DS I Uutry mhtsd .DE This will start the transfer daemon (\fBuucico\fR) with a moderate amount of debugging output, putting the output into a temporary file (/tmp/mhtsa) and executing a \fItail -f\fR command so the administrator can hit a BREAK to get back to the shell, while being able to come back at a later time to look at the output. .P If that works, the administrator can attempt to transfer a file while watching the debugging output. Procede as follows .DS I uucp -r some\-file mhtsd!~/some\-name .DE This will queue a job but not start the transfer daemon. Now proceed as before using \fBUutry\fR. If any of these steps fail, a support person may be needed to diagnose the problem. The output of the above steps will make it easier. .P The file \fI/usr/spool/uucp/.Admin/errors\fR contains error indications, conditions that causes one of the \fBuucp\fR programs to abort (\fIASSERT\fR errors). An explanation of these is given in in Appendix II along with an explanation of the messages one can see as output from \fBuustat -q\fR. Most of these will never occur and indicate that something is wrong with your system or the \fBuucp\fR software. However, the \fIPKXSTART\fR will occur and generally means that the other side aborted during a conversation in a non recoverable way; these can be generally ignored. .FG 40 27 TPA-726626 "Uucp Network Daemon" .FG 40 27 TPA-726627 "Uucico Daemon Functional Blocks" .ES .SK .DS C Appendix I parms.h Header File Setup Local Configuration Options .DE .so AppendixI .SK .DS C Appendix II Error Messages .DE .so AppendixII .SK .DS C Appendix III New Features .DE .so AppendixIII .SK .DS C Appendix IV Setting Up the Permissions File .DE .so AppendixIV .SK 0707070000020023621006660001460001440000010351120357433055400002000000005331docs/uugetty.1m.TH UUGETTY 1M .SH NAME uugetty \- set terminal type, modes, speed, and line discipline .SH SYNOPSIS .B /usr/lib/uucp/uugetty [ .B \-h ] [ .B \-t timeout ] [ .B \-r ] line .br [ speed [ type [ linedisc ] ] ] .br .B /usr/lib/uucp/uugetty \-c file .SH DESCRIPTION .I Uugetty is identical to \fIgetty\fR(1M) but changes have been made to support using the line for \fIuucico\fR, \fIcu\fR, and \fIct\fR; that is, the line can be used in both directions. The \fIuugetty\fR will allow users to login, but if the line is free, \fIuucico\fR, \fIcu\fR, or \fIct\fR can use it for dialing out. The implementation depends on the fact that \fIuucico\fR, \fIcu\fR, and \fIct\fR create lock files when devices are used. When the "open()" returns (or the first character is read when .B \-r option is used), the status of the lock file indicates whether the line is being used by \fIuucico\fR, \fIcu\fR, \fIct\fR, or someone trying to login. Note that in the .B \-r case, several characters may be required before the login message is output. The human users will be able to handle this slight inconvenience. .PP Unless .I uugetty is invoked with the .B -h flag, it will force a hangup on the line by setting the speed to zero before changing it to the default or specified speed. The .B -t flag plus timeout in seconds specifies that .I uugetty should exit if the open on the line succeeds and nothing is typed in the specified number of seconds. .PP With the .B -c option and .B file , .I uugetty will scan the file (generally .B /etc/gettydefs ) and print a summary of its contents to the standard output. .PP \fIUucico\fR trying to login will have to be told by using the following login script: .PP "" \\r\\d\\r\\d\\r\\d\\r in:--in: . . . .PP where the . . . is whatever would normally be used for the login sequence. .PP Here is an \fB/etc/inittab\fR entry using \fIuugetty\fR on an 801/212 dialer: .PP 30:2:respawn:/usr/lib/uucp/uugetty -t 60 cul04 1200 .PP The line name, cul04, is the name that appears in the \fB/usr/lib/uucp/Devices\fR file for the 212 dialer. .PP An entry for an intelligent modem or direct line that has a \fIuugetty\fR on each end must use the .B \-r option. (This causes \fIuugetty\fR to wait to read a character before it puts out the login message, thus preventing two uugettys from looping.) Here is an \fB/etc/inittab\fR entry using \fIuugetty\fR on an intelligent modem or direct line: .PP 30:2:respawn:/usr/lib/uucp/uugetty -r -t 60 tty12 1200 .PP .SH FILES /etc/gettydefs .br /etc/issue .SH "SEE ALSO" getty(1M), init(1M), uucico(1M), tty(7), ct(1C), cu(1C), login(1), ioctl(2), gettydefs(4), inittab(4). .SH BUGS .I Ct will not work when uugetty is used with an intelligent modem such as penril or ventel. .\" @(#)uugetty.1m 4.1 0707070000020023631006660001460001440000010351150357433055500002000000002174docs/uusched.1m.TH UUSCHED 1M .SH NAME uusched \- the scheduler for the uucp file transport program .SH SYNOPSIS .B /usr/lib/uucp/uusched [ .B \-x debug_level ] [ .B \-u debug_level ] .SH DESCRIPTION .I Uusched is the \fIuucp\fR file transport scheduler. It is usually started by the daemon .I uudemon.hour that is started by \fIcron\fR; .P 39 * * * * /bin/su uucp -c "/usr/lib/uucp/uudemon.hour > /dev/null" .P The two options are for debugging purposes only; .BI \-x " debug_level" will output debugging messages from .I uusched and \fB\-u\fR \fIdebug_level\fR will be passed as \fB\-x\fR \fIdebug_level\fR to .IR uucico . The \fIdebug_level\fR is a number between 0 and 9; higher numbers give more detailed information. Note, however, that compiling uucp with the .B -DSMALL option will result in little debugging output ( .B -DSMALL is the default compilation option). .SH FILES .nf /usr/lib/uucp/Systems /usr/lib/uucp/Permissions /usr/lib/uucp/Devices /usr/lib/uucp/Dialers /usr/lib/uucp/Dialcodes /usr/spool/uucp/* /usr/spool/locks/LCK* /usr/spool/uucppublic/* .fi .SH "SEE ALSO" cron(1M), uucico(1M), uucp(1C), uustat(1C), uux(1C). .\" @(#)uusched.1m 4.1 0707070000020023711006660001460001440000010351170357433055500001700000007201docs/uustat.1c.TH UUSTAT 1C .SH NAME uustat \- uucp status inquiry and job control .SH SYNOPSIS .B uustat .RB [ \-a ] or .RB [ \-m ] or .RB [ \-p ] or .RB [ \-q ] or [ .BI \-k " jobid" ] or [ .BI \-r " jobid" ] .br .B uustat [ .BI \-s " system" ] [ .BI \-u " user" ] .SH DESCRIPTION .I Uustat\^ will display the status of, or cancel, previously specified .I uucp\^ commands, or provide general status on .I uucp\^ connections to other systems. Only one of the following options can be specified with .I uustat per command execution: .PP .PD 0 .TP 10 .B \-a\^ Output all jobs in queue. .TP 10 .B \-m\^ Report the status of accessibility of all machines. .TP .B \-p\^ Execute a ``ps \-flp'' for all the process-ids that are in the lock files. .TP .B \-q\^ List the jobs queued for each machine. If a status file exists for the machine, its date, time and status information are reported. In addition, if a number appears in () next to the number of \fBC\fR or \fBX\fR files, it is the age in days of the oldest \fBC.\fR/\fBX.\fR file for that system. The Retry field represents the number of hours until the next possible call. The Count is the number of failure attempts. .sp \fBNOTE:\fR For systems with a moderate number of outstanding jobs, this could take 30 seconds or more of real-time to execute. .PD .PP As an example of the output produced by the \f3\(miq\f1 option: .PD .PP .na eagle 3C 04/07-11:07 NO DEVICES AVAILABLE mh3bs3 2C 04/07-10:42 SUCCESSFUL .ad .PD .PP The above output tells how many command files are waiting for each system. Each command file may have zero or more files to be sent (zero means to call the system and see if there is work to be done). The date and time refer to the previous interaction with the system followed by the status of the interaction. .TP 10 .BI \-k " jobid" Kill the .I uucp\^ request whose job identification is .IR jobid . The killed .I uucp\^ request must belong to the person issuing the .I uustat\^ command unless one is the superuser. .TP 10 .BI \-r " jobid" Rejuvenate .I jobid\^. The files associated with .I jobid\^ are touched so that their modification time is set to the current time. This prevents the cleanup daemon from deleting the job until the jobs modification time reaches the limit imposed by the daemon. .PD .PP Either or both of the following options can be specified with .IR uustat : .PP .PD 0 .TP 10 .BI \-s " sys" Report the status of all .I uucp\^ requests for remote system \fIsys\fR. .TP 10 .BI \-u " user" Report the status of all .I uucp\^ requests issued by .IR user . .PD .PP Output for both the .B -s and .B -u options has the following format: .sp .TS l l. eaglen0000 04/07\-11:01:03 (POLL) eagleNlbd7 04/07\-11:07 S eagle dan 522 /usr/dan/A eagleClbd8 04/07\-11:07 S eagle dan 59 D.3b2a12ce4924 04/07\-11:07 S eagle dan rmail mike .TE .sp .PP With the above two options, the first field is the jobid of the job. This is followed by the date/time. The next field is either an 'S' or 'R' depending on whether the job is to send or request a file. This is followed by the user-id of the user who queued the job. The next field contains size of the file or, in the case of a remote execution (rmail--the command used for remote mail), the name of the command. When the size appears in this field, the file name is also given. This can either be the name given by the user, or an internal name (e.g., D.3b2a1ce4924) that is created for data files associated with remote executions (rmail in this example). .PD .PP When no options are given, .I uustat\^ outputs the status of all .I uucp\^ requests issued by the current user. .SH FILES .TP 20 /usr/spool/uucp/* spool directories .SH SEE ALSO uucp(1C). .\" @(#)uustat.1c 4.1 0707070000020024031006660001460001440000010351230357433055600001500000005445docs/uuto.1c.TH UUTO 1C .SH NAME uuto, uupick \- public \s-1UNIX\s+1 system-to-\s-1UNIX\s+1 system file copy .SH SYNOPSIS .B uuto [ .B -p ]\ [ .B -m ]\ source-files destination .br .B uupick [ .B \-s system ] .SH DESCRIPTION .I Uuto\^ sends .I source-files\^ to .IR destination . .I Uuto\^ uses the .IR uucp (1C) facility to send files, while it allows the local system to control the file access. A source-file name is a pathname on your machine. Destination has the form: .RS system\f3!\fP\fIuser\fP .RE .PP where .I system\^ is taken from a list of system names that .I uucp\^ knows about (see .IR uuname ). .I User\^ is the login name of someone on the specified system. .PP Two \fIoptions\fP are available: .PP .PD 0 .TP 8 .B \-p Copy the source file into the spool directory before transmission. .TP .B \-m Send mail to the sender when the copy is complete. .PD .PP The files (or subtrees if directories are specified) are sent to .SM PUBDIR on .IR system , where .SM PUBDIR is a public directory defined in the .I uucp\^ source. Specifically, the files are sent to .PP .RS \s-1PUBDIR\s+1/receive/\fIuser\fP/\fImysystem\fR/files. .RE .PP The destined recipient is notified by .IR mail (1) of the arrival of files. .PP .I Uupick\^ accepts or rejects the files transmitted to the user. Specifically, .I uupick\^ searches .SM PUBDIR for files destined for the user. For each entry (file or directory) found, the following message is printed on the standard output: .PP .RS \fBfrom \fIsystem\^\fB:\fR [\^file \fIfile-name\^\fR] [dir \fIdirname\^\fR] \fB?\fR .RE .PP .I Uupick\^ then reads a line from the standard input to determine the disposition of the file: .TP 16 Go on to next entry. .TP .B d Delete the entry. .TP \f3m\fP [ \f2dir\^\fP ] Move the entry to named directory .I dir.\^ If .I dir\^ is not specified as a complete pathname (in which $HOME is legitimate), a destination relative to the current directory is assumed. If no destination is given, the default is the current directory. .TP \f3a\fP [ \f2dir\^\fP ] Same as \fBm\fR except moving all the files sent from .IR system . .TP .B p Print the content of the file. .TP .B q Stop. .TP \s-1EOT\s0 (control-d) Same as .BR q . .TP .BI ! command\^ Escape to the shell to execute .IR command . .TP .B * Print a usage summary. .PP .I Uupick\^ invoked with the .BI -s system option will only search the .SM PUBDIR for files sent from .IR system . .SH FILES \s-1PUBDIR\s+1 /usr/spool/uucppublic public directory .SH SEE ALSO mail(1), uucp(1C), uustat(1C), uux(1C). .br uucleanup(1M) in the .IR "\s-1UNIX\s+1 System V Administrator Reference Manual" . .bp .SH WARNINGS In order to send files that begin with a dot (e.g., .profile), the files must by qualified with a dot. For example .profile, .prof*, .profil? are correct; whereas *prof* and ?profile are incorrect. .\" @(#)uuto.1c 1.2 0707070000020024051006660001460001440000010351260357433055700001400000012033docs/uux.1c.\"@(#)uux.1c 5.2 .TH UUX 1C .SH NAME uux \- \s-1UNIX\s+1 system-to-\s-1UNIX\s+1 system command execution .SH SYNOPSIS .B uux [ options ] command-string .SH DESCRIPTION .I Uux\^ will gather zero or more files from various systems, execute a command on a specified system, and then send standard output to a file on a specified system. Note that, for security reasons, many installations will limit the list of commands executable on behalf of an incoming request from .IR uux . Many sites will permit little more than the receipt of mail [see .IR mail (1)] via .IR uux . .PP The \fIcommand-string\fP is made up of one or more arguments that look like a shell command line, except that the command and file names may be prefixed by .IB system-name !\fR.\fP A null \fIsystem-name\fP is interpreted as the local system. .PP File names may be one of .RS .TP 5 (1) a full pathname .TP 5 (2) a pathname preceded by .BI ~ xxx\^ where .I xxx\^ is a login name on the specified system and is replaced by that user's login directory .br .TP 5 (3) anything else is prefixed by the current directory. .RE .PP As an example, the command .IP uux "\^!diff usg!/usr/dan/file1 pwba!/a4/dan/file2 > !~/dan/file.diff\^" .PP will get the \fIfile1\fP and \fIfile2\fP files from the ``usg'' and ``pwba'' machines, execute a .IR diff (1) command, and put the results in \fIfile.diff\fP in the local PUBDIR/dan/ directory. .PP Any special shell characters such as \fB<>;\fR and \fB\(bv\fP should be quoted either by quoting the entire \fIcommand-string\fP or quoting the special characters as individual arguments. .PP .I Uux\^ will attempt to get all files to the execution system. For files that are output files, the file name must be escaped using parentheses. For example, the command .IP uux a!cut -f1 b!/usr/file \\(c!/usr/file\\) .PP gets /usr/\fIfile\fP from system ``b'', sends it to system ``a'', performs a \fIcut\fP command on that file, and sends the result of the .I cut command to system ``c''. .PP .I Uux\^ will notify you if the requested command on the remote system was disallowed. This notification can be turned off by the \fB\-n\fP option. The response comes by mail from the remote machine. .PP The following \fIoptions\fP are interpreted by .IR uux : .TP 10 .B \- The standard input to .I uux is made the standard input to the .IR command-string . .TP 10 .BI \-a name Use .I name as the user identification replacing the initiator user-id. (Notification will be returned to the user.) .TP 10 .BI \-b Return standard input to the command if the exit status is nonzero. .TP 10 .BI \-c Do not copy local file to the spool directory for transfer to the remote machine (default). .TP 10 .BI \-C Force the copy of local files to the spool directory for transfer. .TP .BI \-g grade .I Grade is a single letter/number; lower ASCII sequence characters will cause the job to be transmitted earlier during a particular conversation. (The default is 'N'.) .TP 10 .BI \-j Output the jobid \s-1ASCII\s+1 string on the standard output which is the job identification. This job identification can be used by .I uustat\^ to obtain the status or terminate a job. .TP 10 .B \-n Do not notify the user if the command fails. .TP 10 .B \-p Same as \-: The standard input to .I uux is made the standard input to the .IR command-string . .TP 10 .B \-r Do not start the file transfer, just queue the job. .TP .BI \-s file Report status of the transfer in \fIfile\fR. .TP .BI \-x debug_level Produce debugging output on the standard output. The .I debug_level is a number between 0 and 9; higher numbers give more detailed information. Note that if the program is compiled with .B -DSMALL option, no debugging information will appear. The .B -DSMALL option is the default compilation option. .TP 10 .B \-z Send success notification to the user. .SH FILES .PD 0 .TP 22 /usr/spool/uucp/\(** spool directories .TP /usr/lib/uucp/\(** other data and programs .PD .SH SEE ALSO mail(1), uucp(1C), uustat(1C). .SH WARNINGS Only the first command of a shell pipeline may have a .IB system-name !\fR. All other commands are executed on the system of the first command. .br The use of the shell metacharacter .B \(** will probably not do what you want it to do. The shell tokens .B << and .B >> are not implemented. .PP The execution of commands on remote systems takes place in an execution directory known to the .I uucp system. All files required for the execution will be put into this directory unless they already reside on that machine. Therefore, the simple file name (without path or machine reference) must be unique within the .I uux request. The following command will NOT work: .PP .RS .nf uux "a!diff b!/usr/dan/xyz c!/usr/dan/xyz > !xyz.diff" .fi .RE .PP but the command .PP .RS .nf uux "a!diff a!/usr/dan/xyz c!/usr/dan/xyz > !xyz.diff" .fi .RE .PP will work. (If .I diff is a permitted command.) .SH BUGS Protected files and files that are in protected directories that are owned by the requester can be sent in commands using .IR uux . However, if the requester is root and the directory is not searchable by "other", the request will fail. .\" @(#)uux.1c 4.4 0707070000020024061006660001460001440000010351340357433056000001600000002710docs/uuxqt.1m.TH UUXQT 1M .SH NAME uuxqt \- execute remote command requests .SH SYNOPSIS .B /usr/lib/uucp/uuxqt [ .B \-s system ] [ .B \-x debug_level ] .SH DESCRIPTION .I Uuxqt is the program that executes remote job requests from remote systems generated by the use of the .I uux command. (\fIMail\fR uses \fIuux\fR for remote mail requests). .I Uuxqt searches the spool directories looking for .I X. files. For each \fIX\fR. file, \fIuuxqt\fR checks to see if all the required data files are available and accessible and file commands are permitted for the requesting system. The .I Permissions file is used to validate file accessibility and command execution permission. .PP There are two environment variables that are set before the .I uuxqt command is executed: .br UU_MACHINE is the machine that sent the job (the previous one). .br UU_USER is the user that sent the job. .br These can be used in writing commands that remote systems can execute to provide information, auditing, or restrictions. .PP The \fB-x\fR debug level is a single digit between 0 and 9; higher numbers give more detailed debugging information. Note, however, that compiling .I uucp with the .B -DSMALL option will result in little debugging output. (The .B -DSMALL option is the default compilation option.) .SH FILES .br .nf /usr/lib/uucp/Permissions /usr/lib/uucp/Maxuuxqts /usr/spool/uucp/* /usr/spool/locks/LCK* .fi .SH "SEE ALSO" uucico(1M), mail(1), uucp(1C), uustat(1C), uux(1C). .\" @(#)uuxqt.1m 4.1 0707070000020024061006660001460001440000010351340357433056000001300000000000TRAILER!!!iles and files that are in protected directories that are owned by the requester can be sent in commands using .IR uux . However, if the requester is root and the directory is not searchable by "other", the request will fail. .\" @(#)uux.1c 4.4 0707070000020024061006660001460001440000010351340357433056000001600000002710docs/uuxqt.1m.TH UUXQT 1M .SH NAME uuxqt \- execute remote command requests .SH SYNOPSIS .B /usr/lib/uucp/uuxqt [ .B \-s system ] [ .B \-x debug_level ] .SH DESCRIPTION .I Uuxqt is the program that executes remote job requests from remote systems generated by the use of the .I uux command. (\fIMail\fR uses \fIuux\fR for remote mail requests). .I Uuxqt searches the spool directories looking for .I X. files. For each \fIX\fR. file, \fIuuxqt\fR checks to see if all the required data files are available and accessible and file commands are permitted for the requesting system. The .I Permissions file is used to validate file accessibility and command execution permission. .PP There are two environment variables that are set before the .I uuxqt command is executed: .br UU_MACHINE is the machine that sent the job (the previous one). .br UU_USER is the user that sent the job. .br These can be used in writing commands that remote systems can execute to provide information, auditing, or restrictions. .PP The \fB-x\fR debug level is a single digit between 0 and 9; higher numbers give more detailed debugging information. Note, however, that compiling .I uucp with the .B -DSMALL option will result in little debugging output. (The .B -DSMALL option is the default compilation option.) .SH FILES .br .nf /usr/lib/uucp/Permissions /usr/lib/uucp/Maxuuxqts /usr/spool/uucp/* /usr/spool/locks/LCK* .fi .SH "SEE ALSO" uucico(1M), mail(1), uucp(1C), uustat(1C), uux(1C). .\" @(#)uuxqt.1m 4.1 0707070000020024061006660001460001440000010351340357433056000001300000000000TRAILER!!!iles and files that are in protected directories that are owned by the requester can be sent in commands using .IR uux . However, if the requester is root and the directory is not searchable by "other", the request will fail. .\" @(#)uux.1c 4.4 0707070000020024061006660001460001440000010351340357433056000001600000002710docs/uuxqt.1m.TH UUXQT 1M .SH NAME uuxqt \- execute remote command requests .SH SYNOPSIS .B /usr/lib/uucp/uuxqt [ .B \-s system ] [ .B \-x debug_level ] .SH DESCRIPTION .I Uuxqt is the program that executes remote job requests from remote systems generated by the use of the .I uux command. (\fIMail\fR uses \fIuux\fR for remote mail requests). .I Uuxqt searches the spool directories looking for .I X. files. For each \fIX\fR. file, \fIuuxqt\fR checks to see if all the required data files are available and accessible and file commands are permitted for the requesting system. The .I Permissions file is used to validate file accessibility and command execution permission. .PP There are two environment variables that are set before the .I uuxqt command is executed: .br UU_MACHINE is the machine that sent the job (the previous one). .br UU_USER is the user that sent the job. .br These can be used in writing commands that remote systems can execute to provide information, auditing, or r