(Prcd) SETTING UP UUCP OVER MULTIPLE TCP/IP INTERFACES "SETTING UP UUCP OVER MULTIPLE TCP/IP INTERFACES" SETTING UP UUCP OVER MULTIPLE TCP/IP INTERFACES Robert Horst Robert.Horst@SanDiegoCA.NCR.COM Jeff Carter Jeff.Carter@SanDiegoCA.NCR.COM May 5, 1993 Abstract The UUCP collection of programs was first created in 1976 by Mike Lesk at AT&T Bell Laboratories as a part of a research project. Had he known what a powerful and confusing product he was about to unleash upon the UNIX world, he would have sat back and smiled. Introduction: This document is in response to a multitude of problems that we have recently encountered with setting up UUCP over TCP/IP on the NCR 3600. The intent of this paper is not to make you a UUCP guru, rather it is intended as a condensed explanation and procedure for installing UUCP over TCP/IP. The document is broken into four sections: Section 1: Detailed Explanation Of Basic UUCP Set-up Over TCP/IP Section 2: Testing The UUCP Set Up Section 3: A Simple Shell For Automating UUCP Set-up Over TCP/IP Section 4: Reference Material It is assumed that the reader has some previous knowledge of UUCP and TCP/IP. Section 1: Detailed Explanation Of Basic UUCP Set-up Over TCP/IP This section documents the steps taken to get UUCP working on the 3600 over multiple network interfaces. In this example, two network interfaces were used, the YNET, and an Ethernet interface. A two AP system was used with the APs being named app002-0 and app002-1. There are three general steps in setting up UUCP over TCP/IP: Section 1.1: Define The Network Listen Process For Each Network Interface Section 1.2: Define The Services For Each Network Listen Process Section 1.3: Configure The UUCP Files To Use The Network Interfaces Section 1.1: Define Network Listen Process For Each Network Interface This section discusses the steps necessary to set up a listen process on each of the network interfaces. It then describes how to assign a RFS address to each of the listener processes. 1) Find out what network interfaces are available: Command Syntax: # netstat -i Description: The interface display (-i) shows the status of the configured network interfaces. This display includes: the interface name; the maximum transmission unit (Mtu) in bytes; the network and interface addresses; the number of packets received and sent; and, the number of send and receive errors. For app002-0 the output was: # netstat -i Name Mtu Network Address Ipkts Ierrs Opkts Oerrs en0 1500 enet app002-0_e 2664595 0 610381 0 en1 1500 p_net app002-0_p 63449 0 6261 0 lo0 4096 Loopback me 4260 0 4258 0 dlyn 32708 ynet app002-0 928980 0 948860 0 For app002-1 the output was: # netstat -i Name Mtu Network Address Ipkts Ierrs Opkts Oerrs en0 1500 enet app002-1_e 2190566 0 68618 0 en1 1500 p_net app002-1_p 63472 0 6258 0 lo0 4096 Loopback me 4260 0 4258 0 dlyn 32708 ynet app002-1 108723 0 88814 0 This shows the network address ("Network") and the interface addresses ("Address") available for each of the APs. In this example, both APs have the same network address, however there is no need for both sides to have matching addresses. We will use the "enet" and "ynet" network addresses for this example. NOTE: Because port monitor services require alphanumeric port monitor tags, you may need to modify the information given by the netstat -i command. You do not need to change the interface, simply take the information and eliminate any non-alphanumeric characters for use in this procedure. For example, the network address p_net is shown in our example. We would have used pnet if we were going to set up UUCP over this network interface. 2) Verify what port the listen process uses and add to the /etc/services file if necessary: Description: The Services file contains information regarding the known services available in the DARPA Internet. For each service, a single line should be present with the following information: official-service-name port-number/protocol-name aliases Fields are separated by any number of blanks and/or tab characters. The port number and protocol name are considered a single field; the slash separates the port and protocol (e.g. ``512/tcp''). A pound sign (#) indicates the beginning of a comment; characters up to the end of the line are not interpreted by routines that search the file. Service names may contain any printable character other than a space, tab, newline, or comment character. Historically, there have been two "well known" port numbers used for the listen process in the NCR 3000 (SVR4) systems. They are 1025/tcp and 2766/tcp. It does not matter which is used, you just need to be consistent. This port number will be used in setting up the address of the listen process as well as in the UUCP Systems file. In the current SVR4 release, the default port number is 2766/tcp thus we used it in our example. On app002-0 and app002-1, we found that the listen port was not defined in the /etc/services file by doing the following: # grep "listen" /etc/services # Since there was no definition for the listen process, we added the following line (using vi) to the /etc/services file: listen 2766/tcp attlisten saflisten listener # listener 3) Find out if there are any network listener processes already defined on the APs: Command Syntax: # nlsadmin -x Description: Reports the status of all of the listener processes installed on this machine. If there are any network listener processes running, they will be shown. For our example, the AP systems that we were using had a network listener process running from a previous attempt at getting UUCP over TCP/IP working. The output on both app002-0 and app002-1 looked as follows: # nlsadmin -x tcp ACTIVE 4) Determine if the currently defined network listener processes are needed or will conflict with the listener processes you are going to set-up. Delete them if necessary: In the example, we knew that the currently defined listener process was not needed since it was from a previous attempt at setting up UUCP over TCP/IP that we had done ourselves. We also knew that it would conflict with our new set-up so we decided to delete the currently defined listener process. You can delete the listener process through the sysadm menu items (choose ports, port monitors, remove and mark (F2) ) however this will not remove all the files. As an alternative do the following: Command Syntax: # /usr/sbin/sacadm -r -p Command Syntax: # rm -rf /etc/saf/ Since both app002-0 and app002-1 had the tcp network listener process defined, the following commands were entered on both APs to remove it: # /usr/sbin/sacadm -r -p tcp # rm -rf /etc/saf/tcp Caution: You should not remove listen processes unless you are sure of what you are doing. There are many networking products that may set-up these listen processes and services. If you are unsure, you should consult with the systems administrator. Also use the nlsadmin -v command to show all the services defined on the network listen process. This may help determine the origin. 5) Create and initialize the files needed by the network listener process for each network interface: Command Syntax: # nlsadmin -i Description: Initializes an instance of the listener for the network specified by net_spec; that is, creates and initializes the files required by the listener as well as starting that instance of the listener. Note that a particular instance of the listener should be initialized only once. The listener must be initialized before assigning addresses or services. On both app002-0 and app002-1 the network interface names were the same so the following commands were done on both APs: # nlsadmin -i enet # nlsadmin -i ynet 6) Verify that the listener processes were setup: Command Syntax: # nlsadmin -v The output on both app002-0 and app002-1 are the same at this point: # nlsadmin -v enet 0 NOADDR ENABLED NORPC root NOMODULES /usr/lib/saf/nlp s_server # NLPS server # nlsadmin -v ynet 0 NOADDR ENABLED NORPC root NOMODULES /usr/lib/saf/nlps_server # NLPS server 7) Find the RFS address for each of the network listener processes: Command Syntax: /usr/etc/rfsaddr -h -p Description: The rfsaddr command converts an Internet address and port number to an address recognized by the Network Listener and Remote File Services. If no arguments are given to the rfsaddr command, it will read a host name from the standard input and use the port number 2766. The -h option can be used to specify a host name on the command line. Host can be either the official host name or a valid alias. The -p option can be used to specify a port number on the command line. Port must be a greater than 1024. The specified port will be used by the Network Listener Service to handle RFS traffic and should therefore be a valid TCP port not otherwise in use on the local host. The format of the address constructed by rfsaddr is: \xfamilyportinaddr where \x indicates the address is in hexadecimal, family is a four digit hex encoding of the address family, port is a four digit hex encoding of the port number, and inaddr is an eight digit hex encoding of the Internet address. To find out the address (corresponds to a /etc/hosts entry) of each interface, use the netstat -i command. For app002-0 the output was: # netstat -i Name Mtu Network Address Ipkts Ierrs Opkts Oerrs en0 1500 enet app002-0_e 2664595 0 610381 0 en1 1500 p_net app002-0_p 63449 0 6261 0 lo0 4096 Loopback me 4260 0 4258 0 dlyn 32708 ynet app002-0 928980 0 948860 0 For app002-1 the output was: # netstat -i Name Mtu Network Address Ipkts Ierrs Opkts Oerrs en0 1500 enet app002-1_e 2190566 0 68618 0 en1 1500 p_net app002-1_p 63472 0 6258 0 lo0 4096 Loopback me 4260 0 4258 0 dlyn 32708 ynet app002-1 108723 0 88814 0 We then used the rfsaddr command to get the RFS address format for each of the network interfaces that we had set-up listen processes on (enet & ynet): For app002-0 the output was: # /usr/etc/rfsaddr -h app002-0 -p 2766 \x00020ace8001c010 # /usr/etc/rfsaddr -h app002-0_e -p 2766 \x00020ace84f26fab For app002-1, the output was: # /usr/etc/rfsaddr -h app002-1 -p 2766 \x00020ace8001c011 # /usr/etc/rfsaddr -h app002-1_e -p 2766 \x00020ace84f26fac 8) Define the RFS address for each of the network listener processes: Command Syntax: # /usr/bin/nlsadmin -l Description: nlsadmin -l address net_spec changes or set the transport address on which the listener listens (the general listener service). This address can be used by remote processes to access the servers available through this listener (see the -a option). If address is just a dash ("-"), nlsadmin will report the address currently configured, instead of changing it. A change of address takes effect immediately. Using the addresses obtained in Step 8, we defined the RFS address on each of the listen processes for our example: For app002-0, we entered the following: # /usr/bin/nlsadmin -l "\x00020ace8001c010" ynet # /usr/bin/nlsadmin -l "\x00020ace84f26fab" enet For app002-1, we entered the following: # /usr/bin/nlsadmin -l "\x00020ace8001c011" ynet # /usr/bin/nlsadmin -l "\x00020ace84f26fac" enet 9) Add the definition for each network to the network configuration database (/etc/netconfig) Because we have defined new listener processes on our network interfaces, we need to define the networks to the system in the network configuration database. Definition: The network configuration database, /etc/netconfig, is a system file used to store information about networks connected to the system and available for use. The netconfig database and the routines that access it [see getnetconfig(3N)] are part of the UNIX System V Network Selection component. For a detailed description of the fields, reference the man page for netconfig. In our example, we have defined two network interfaces, ynet and enet. For app002-0 and app002-1, the entries are the same. The following lines were added to the /etc/netconfig file to define these networks: ynet tpi_cots v inet tcp /dev/tcp /usr/lib/tcpip.so enet tpi_cots v inet tcp /dev/tcp /usr/lib/tcpip.so 10) Define device nodes for each network interface In the current release of SVR4 Release 2.0 (2.00.01), the listener code has a bug in it which will be reported. The listen process tries to access a device based on the name in the /etc/netconfig file rather than the listed device (/dev/tcp). As a work around, we created device nodes for each interface with the same major and minor numbers as /dev/tcp. In our example, on each of the APs we entered the following commands: # ls -la /dev/tcp crw-rw-rw- 1 root root 0, 41 May 3 15:49 /dev/tcp This shows the major and minor numbers for /dev/tcp to be 0 and 41 respectively. We then made character special devices for each of the listener process and set the proper file permissions as follows: # mknod /dev/ynet c 0 41 # chmod 666 /dev/ynet # mknod /dev/ynet c 0 41 # chmod 666 /dev/ynet 11) Create the rc script S76uucpsetup to assure UUCP set-up at boot There are several steps in this procedure that require checking at system boot time. The checks are required for several reasons. In STEP 9 we updated the file /etc/netconfig (network configuration database). This file may be reinitialized during an update of the WIN-TCP software. Because of this, it is a good idea to check at boot time that the changes for UUCP are still in the file and add them if needed. The second area that we found to check at boot time was the device nodes that we created for each listener process. The /dev directory may be rebuilt at boot time (idmknod) due to a new kernel being installed. When this happens, the device nodes that we placed in the /dev directory will disappear. To compensate for this, we checked at boot time that the device nodes were still in place and added them needed. We created the following shell script to take care of the boot time requirements for this procedure: #!/bin/ksh # This script (S76uucpsetup) will # assure nodes for UUCP are setup after reboot # in case kernel has been rebuilt (could have # removed /dev when major/minor #s change on # pkgadd. Also assures proper entries are in # /etc/netconfig for uucp & listen daemons. echo "Checking UUCP set-up..." ENDPOINTS=/tmp/endpoints.$$ netstat -i | egrep -v "^Name.*Address|Loopback" | \ nawk '{ print $3 }' > $ENDPOINTS NETCONFIG=`egrep "^tcp" /etc/netconfig` while read NETWORK do # # port monitor tags must be alphanumeric, but stuff in /etc/networks # can be anything. This tries to weed out the non-alphanum stuff # ALPHA_NETWORK=`echo $NETWORK | sed 's/[^A-Za-z0-9]//g'` NETWORK=$ALPHA_NETWORK # # This sets up the network definitions in the /etc/netconfig # Database. # MY_NETCONFIG=`echo $NETCONFIG | sed "s/^tcp/$NETWORK/"` grep "^$MY_NETCONFIG" /etc/netconfig >/dev/null 2>&1 if [ $? -eq 1 ] then echo $MY_NETCONFIG >> /etc/netconfig fi # # This checks for nodes in /dev for each network listener # (work around for current prob w/ listener) # if [ ! -c /dev/$NETWORK ] then if [ -c /dev/tcp ] then MAJMIN=/tmp/majmin ls -la /dev/tcp | nawk '{print $5 " " $6}' \ | sed "s/,//" >$MAJMIN while read MAJ MIN do # Create node for listener device # /sbin/mknod /dev/$NETWORK c $MAJ $MIN /usr/bin/chmod 666 /dev/$NETWORK done < $MAJMIN rm -f $MAJMIN fi fi done < $ENDPOINTS rm -f $ENDPOINTS echo "Finished UUCP check" We created the script in the /tmp directory and named the file uucpsetup. After we created the script, we moved it to the /etc/init.d directory and called it uucpsetup. We then changed the file permissions and made a hard link to the file in the /etc/rc2.d directory. We did this using the following commands: # mv /tmp/uucpsetup /etc/init.d/uucpsetup # chmod 766 /etc/init.d/uucpsetup # ln /etc/init.d/uucpsetup /etc/rc2.d/S76uucpsetup Summary of Section 1.1: At this point, a listener process has been set-up on each of the network interfaces and an RFS address defined for each. The networks were defined in the /etc/netconfig database and device nodes were defined in the /dev directory. The next section discusses setting up the UUCP service for the listener processes. Section 1.2: Define The Services For Each Network Listen Process This section discuss the steps necessary to add the UUCP (uucico) service on the network listener processes set up in the previous section. 1) Add the uucp (uucico) service to each of the network interface listener's data base file: Command Syntax: nlsadmin -a -c -y Description: nlsadmin -a service_code [-p modules] [-w name] -c cmd -y comment : cmd must appear as a single word to the shell; if arguments are required, the cmd and its arguments must be enclosed in quotation marks. The comment must also appear as a single word to the shell. For UUCP, we used the following values for the variable fields of this command: = 101 = "/usr/lib/uucp/uucico -r 0 -i TLI -u nuucp" = Any description for the service = [enet / ynet] The commands for doing this on both app002-0 and app002-1 was the same and is shown below: # nlsadmin -a 101 -c "/usr/lib/uucp/uucico -r 0 -i TLI -u nuucp" \ -y "uucp over enet" enet # nlsadmin -a 101 -c "/usr/lib/uucp/uucico -r 0 -i TLI -u nuucp" \ -y "uucp over ynet" ynet 2) Verify that the services were added properly for the network interfaces: Command Syntax: # nlsadmin -v Description: nlsadmin -v net_spec prints a verbose report on the servers associated with net_spec, giving the service code, status, command, and comment for each. It also specifies the uid the server will run as and the list of modules to be pushed, if any, before the server is started. For app002-0, the output was: # nlsadmin -v enet 0 \x00020ace84f26fab ENABLED NORPC root NOMODULES /usr/lib/saf/nlps_server # NLPS server 101 NOADDR ENABLED NORPC listen NOMODULES /usr/lib/uucp/uucico -r 0 -i TLI -u nuucp # uucp over enet # nlsadmin -v ynet 0 x00020ace8001c010 ENABLED NORPC root NOMODULES /usr/lib/saf/nlps_server # NLPS server 101 NOADDR ENABLED NORPC listen NOMODULES /usr/lib/uucp/uucico -r 0 -i TLI -u nuucp # uucp over ynet For app002-1, the output was: # nlsadmin -v enet 0 \x00020ace84f26fac ENABLED NORPC root NOMODULES /usr/lib/saf/nlps_server # NLPS server 101 NOADDR ENABLED NORPC listen NOMODULES /usr/lib/uucp/uucico -r 0 -i TLI -u nuucp # uucp over enet # nlsadmin -v ynet 0 x00020ace8001c011 ENABLED NORPC root NOMODULES /usr/lib/saf/nlps_server # NLPS server 101 NOADDR ENABLED NORPC listen NOMODULES /usr/lib/uucp/uucico -r 0 -i TLI -u nuucp # uucp over ynet 3) Enable the listener process on each of the network interfaces Now that the services have been defined for the listener processes, the listener processes can be enabled for use. Command Syntax: # nlsadmin -s Description: nlsadmin -s net_spec / nlsadmin -k net_spec starts / stops the listener process for the indicated network. These operations will normally be performed as part of the system startup and shutdown procedures. Before a listener can be started for a particular network, it must first have been initialized (see the -i option). When a listener is killed, processes that are still running as a result of prior service requests will continue unaffected. For our example, the following commands were entered on both app002-0 and app002-1: # nlsadmin -s ynet # nlsadmin -s enet NOTE: You can check to see if the listeners are started using the nlsadmin -x command. It will show you if the listeners are active or inactive. Summary of Section 1.2: The UUCP service (server) has now been defined for each of the network listeners and the listeners enabled. The next section discusses setting up the UUCP files to use the UUCP services. Section 1.3: Configure The UUCP Files To Use The Network Interfaces This section discusses setting up the UUCP files to use the UUCP services defined on the network interfaces. Note that this is not a complete discussion of setting up UUCP. Only the files required to change to use the network interfaces are discussed. For a more complete discussion of setting up UUCP, see the NCR UNIX SVR4 Administrator Guide: Advanced Tasks manual (Sections 14 and 15). 1) Set up a tcp entry in the /etc/uucp/Dialers file The Dialers file specifies the initial conversation (handshaking) that must take place on a "line" before it can be made available for transferring data. This conversation is usually a sequence of transmitted/expected ASCII strings. For UUCP over TCP/IP, the following Dialers information should be defined: tcp "" "" NLPS:000:001:101\N\c NOTE: Verify that the information is not already in the /etc/uucp/Dialers directory first. If it is not, add the line to the end of the file. 2) Add a device definition to the /etc/uucp/Devices file for each of the network interface devices The Devices file contains information for all the devices that may be used to establish a link to a remote system. It contains information for modems with auto-dialing capabilities, direct links, and network connections. The Devices file is closely related to the Dialers and Systems file. Entry Format: TYPE LINE LINE2 CLASS DIALER-TOKEN-PAIRS Where: TYPE - Describes the type of link. For TCP/IP "links" we used the net_spec combined with the word "Device". This field will be referenced by the third field in the Systems file. A protocol can also be designated. For TCP/IP connections, use e,g. LINE - Contains the device name of the line (port) associated with the Device entry. In our example, we used ynet and enet since these were the listener ports we defined. LINE2 - This is used for ACU type devices and will not be discussed here, thus a "-" was placed in this field to signify not used. CLASS - This again is used for ACU type devices and will not be discussed here, thus a "-" was placed in this field to signify not used. DIALER-TOKEN-PAIRS - This contains the pairs of dialers and tokens. For TCP/IP connections, use "TLI \D tcp". This will access the built in TLI (Transport Level Interface Network) and the token tcp that we placed in the Dialers file. In our example, we entered the following two lines to the /etc/uucp/Devices file for both app002-0 and app002-1: ynetDevice,eg ynet - - TLI \D tcp enetDevice,eg enet - - TLI \D tcp 3) Set up the Permissions File The Permissions file (/etc/uucp/Permissions) specifies the permissions that the remote systems have with respect to login, file access, and command execution. Options are provided for restricting the remote system's ability to request files and to receive files queued by the local site. Another option is available to specify the commands that a remote site can execute on the local system. It is beyond the scope of this document to go into security issues for UUCP. This information is explained in detail in the NCR UNIX SVR4 Administrator Guide: Advanced Tasks manual (Section 15). We can show a basic set-up that we used just to allow the users uucp and nuucp to log into a system. For our example, we put the following information into the Permissions file on both app002-0 and app002-1: LOGNAME=uucp:nuucp \ REQUEST=yes \ SENDFILES=yes \ CALLBACK=no \ READ=/usr/spool/uucppublic \ WRITE=/usr/spool/uucppublic \ NOREAD=/etc \ NOWRITE=/etc \ COMMANDS=rnews:rmail:uucp:lp:/usr/local/bin/ditroff \ MYNAME=app002-1 #put app002-0 in app002-0 NOTE: The parameter MYNAME is not discussed in the referenced documentation, however it is a very useful parameter. It allows you to specify what name you would like to have your system known as. If this parameter is not specified, the uname of the system will be used. The name of a system is passed during the initialization phase of a UUCP connection. The calling system expects to receive back the name that was called (in the Systems file). 4) Set up the Systems file The Systems file (/etc/uucp/Systems) contains information that both the cu and uucico (UUCP) need to establish a communication link to a remote system. Each entry in the file represents a system that can be called by your system. A particular system may have more than one entry in the Systems file. The additional entries represent alternative communication paths that are tried in sequential order. It is beyond the scope of this document to go into security issues for UUCP. This information is explained in detail in the NCR UNIX SVR4 Administrator Guide: Advanced Tasks manual (Section 15). In our example, the following entries were placed in the Systems file for app002-0: app002-1 Any ynetDevice - \x00020ace8001c011 app002-1 Any enetDevice - \x00020ace84f26fac For app002-1, the following entries were placed in the Systems file: app002-0 Any ynetDevice,eg - \x00020ace8001c010 app002-0 Any enetDevice,eg - \x00020ace84f26fab NOTE: The format of the fields are explained in the Advanced Tasks Guide, however there are several items worth noting here. The first field is the name of the system that you want to call. In our case, we used the same name as the uname of the remote system. If you wish to use another name, the MYNAME parameter in the remote system Permissions file must be set to the same name as used in the local systems Systems file. The last field shown in our example is the RFS address format of the system that we are calling. This address is based on the IP address of the remote host, which will be different based on the network interface that you wish to use. In our example, there were two routes to each AP. The ynet and the enet interface. Thus we located the name of the remote host in the /etc/hosts file and used rfsaddr to provide the RFS address format. For app002-0, the following commands/output were done: # /usr/etc/rfsaddr -h app002-1 \x00020ace8001c011 # /usr/etc/rfsaddr -h app002-1_e \x00020ace84f26fac For app002-1, the following commands/output were done: # /usr/etc/rfsaddr -h app002-0 \x00020ace8001c010 # /usr/etc/rfsaddr -h app002-0_e \x00020ace84f26fab 5) Assure that the users uucp and nuucp are set-up in the /etc/passwd, /etc/shadow and /etc/groups files The users uucp and nuucp usually come pre configured as users on your system. It is a good idea to verify this however. In our example system, the following information was verified: # grep "^uucp" /etc/passwd uucp:x:5:5:0000-uucp(0000):/usr/lib/uucp: # grep "^uucp" /etc/shadow uucp:NONE:8096:::::: # grep "^nuucp" /etc/passwd nuucp:x:10:10:0000-uucp(0000):/var/spool/uucppublic:/usr/lib/uucp/uucico # grep "^nuucp" /etc/shadow nuucp::8096:::::: # grep "uucp" /etc/group uucp::5:root,uucp All your systems that need to allow the uucp and nuucp users access must have the users defined similarly. If they are not in these files, UUCP will not work. They can be added via the standard sysadm menus or by using vi. Section 2: Testing The UUCP Set Up Testing your UUCP set-up after completing the steps in section 1 of this document is a relatively simple procedure. For a more complete write up of the test procedures and troubleshooting procedures see the NCR UNIX SVR4 Administrator Guide: Advanced Tasks manual (Section 15). The easiest way to test your set-up is to use the Uutry command which is provided with the UUCP utilities. Description: Uutry is a shell that is used to invoke uucico to call a remote site. Debugging is initially turned on and is set to the default value of 5. The debugging output is put in the file /tmp/ and also to stdout. For more details, see the man pages for Uutry. To invoke Uutry, do the following: # /usr/lib/uucp/Uutry Where is the remote system that you wish to test communications with. This should be done for every system that you have set up on each host that you have set up. Further, where you have defined multiple entries in the Systems file for a given host, the entries should be commented out one at a time (put # in front of the line to comment out), so that the next route to the remote system will be tested. NOTE: After trying Uutry, the console you are on will hang in the process until it is sent a kill character (usually or ). Also, once you have tried a connection once, a file is created in the /var/spool/uucp/.Status directory for the remote host which will keep you from trying the Uutry to that system again for a given time period. If you wish to try again immediately, simply remove the file in the /var/spool/uucp/.Status directory. Section 3: A Simple Shell For Automating UUCP Set-up Over TCP/IP During our investigation into the problems we were encountering with UUCP set-up over TCP/IP, we wrote a simple shell script to automate most of the set-up. In fact, the only portion of the procedure in section 1 that this scrip does not address is setting up the Permissions file (Section 1.3, Step 3) and setting up the Systems file (Section 1.3, Step 4). NOTE: As with any shell, care should be taken when using this on your system. We know of several limitations for this script. Limitations: A) This will not work in a DNS environment since we depended on the /etc/host file being local. B) This script does not address all the aspects discussed in Section 1 of this document. Specifically it does not check for pre-existing listen processes discussed in Section 1.1. It also does not add/modify the /etc/uucp/Systems or /etc/uucp/Permissions files. C) This script may also produce duplicate listen port names if the network interface names are similar. Because the port monitor listen name must be alphanumeric, this script removes any non-alphanumeric characters. This could produce duplicate names. For instance, if there were two interface names, pnet and p_net, they would both end up having the port listen name of pnet. If this happens, only the second port will be set-up by this script. #!/bin/ksh ENDPOINTS=/tmp/endpoints.$$ echo "Creating S76uucpsetup rc2.d script" ########################################################## # Start building rc script S76uucpsetup) to assure nodes # are setup in /dev (could have been deleted # after kernel relink). Also S76uucpsetup assures that # /etc/netconfig has the required entries. # SETUPRC=/etc/init.d/uucpsetup echo "#!/bin/ksh" > $SETUPRC echo "# This script (S76uucpsetup) will " >> $SETUPRC echo "# assure nodes for UUCP are setup after reboot " >> $SETUPRC echo "# in case kernel has been rebuilt (could have " >> $SETUPRC echo "# removed /dev when major/minor #s change on " >> $SETUPRC echo "# pkgadd. Also assures proper entries are in " >> $SETUPRC echo "# /etc/netconfig for uucp & listen daemons. " >> $SETUPRC echo "echo \"Checking UUCP set-up...\"" >> $SETUPRC echo "ENDPOINTS=/tmp/endpoints.\$\$" >> $SETUPRC echo "netstat -i | egrep -v \"^Name.*Address|Loopback\" | \\" \ >> $SETUPRC echo " nawk '{ print \$3 }' > \$ENDPOINTS" >> $SETUPRC echo "NETCONFIG=\`egrep \"^tcp\" /etc/netconfig\`" >> $SETUPRC echo "while read NETWORK" >> $SETUPRC echo "do" >> $SETUPRC echo " #" >> $SETUPRC echo " # port monitor tags must be alphanumeric, but stuff in \ /etc/networks" >> $SETUPRC echo " # can be anything. This tries to weed out the non-alphanum \ stuff" >> $SETUPRC echo " #" >> $SETUPRC echo " ALPHA_NETWORK=\`echo \$NETWORK | sed 's/[^A-Za-z0-9]//g'\`" \ >> $SETUPRC echo " NETWORK=\$ALPHA_NETWORK" >> $SETUPRC echo " #" >> $SETUPRC echo " # This sets up the network definitions in the /etc/netconfig" \ >> $SETUPRC echo " # Database. " >> $SETUPRC echo " #" >> $SETUPRC echo " MY_NETCONFIG=\`echo \$NETCONFIG | sed \"s/^tcp/\$NETWORK/\"\`" \ >> $SETUPRC echo " grep \"^\$MY_NETCONFIG\" /etc/netconfig >/dev/null 2>&1" \ >> $SETUPRC echo " if [ \$? -eq 1 ]" >> $SETUPRC echo " then" >> $SETUPRC echo " echo \$MY_NETCONFIG >> /etc/netconfig" >> $SETUPRC echo " fi" >> $SETUPRC echo " #" >> $SETUPRC echo " # This checks for nodes in /dev for each network listener" \ >> $SETUPRC echo " # (workaround for current prob w/ listener) " >> $SETUPRC echo " #" >> $SETUPRC echo " if [ ! -c /dev/\$NETWORK ]" >> $SETUPRC echo " then" >> $SETUPRC echo " if [ -c /dev/tcp ]" >> $SETUPRC echo " then" >> $SETUPRC echo " MAJMIN=/tmp/majmin" >> $SETUPRC echo " ls -la /dev/tcp | nawk '{print \$5 \" \" \$6}' \\" >> $SETUPRC echo " | sed \"s/,//\" >\$MAJMIN" >> $SETUPRC echo " while read MAJ MIN" >> $SETUPRC echo " do" >> $SETUPRC echo " #" >> SETUPRC echo " # Create node for listener device" >> $SETUPRC echo " #" >> $SETUPRC echo " /sbin/mknod /dev/\$NETWORK c \$MAJ \$MIN" >> $SETUPRC echo " /usr/bin/chmod 666 /dev/\$NETWORK" >> $SETUPRC echo " done < \$MAJMIN" >> $SETUPRC echo " rm -f \$MAJMIN" >> $SETUPRC echo " fi" >> $SETUPRC echo " fi" >> $SETUPRC echo "done < \$ENDPOINTS" >> $SETUPRC echo "rm -f \$ENDPOINTS" >> $SETUPRC echo "echo \"Finished UUCP check\"" >> $SETUPRC # # Make link in /etc/rc2.d directory # chmod 766 /etc/init.d/uucpsetup ln /etc/init.d/uucpsetup /etc/rc2.d/S76uucpsetup > /dev/null 2>&1 ########################################### # Done Building RC Script ########################################### # Start creating UUCP set-up ########################################### echo "Starting UUCP set-up..." # # Create file containing "Network" & "Address" of each network # interface. Will be used to set-up port monitors # netstat -i | egrep -v "^Name.*Address|Loopback" | \ nawk '{ print $3 " " $4 }' > $ENDPOINTS # #check to see if listen is defined in /etc/services. If not, add. # echo "\tChecking/Adding \"listen\" to /etc/services" grep "listen" /etc/services > /dev/null 2>&1 if [ $? != 0 ] then echo 'listen 2766/tcp attlisten saflisten listener # listener' \ >> /etc/services fi # # get listen port number # LISTEN_PORT=`egrep "^listen" /etc/services | awk '{ print $2; exit }' | \ sed 's,/.*,,g' ` LISTEN_PORT=${LISTEN_PORT:-"2766"} # # Get "tcp" definition from /etc/netconfig Database # NETCONFIG=`egrep "^tcp" /etc/netconfig` # # Define the tcp entry in the /etc/uucp/Dialers file if required. # echo "\tChecking/Adding tcp entry in /etc/uucp/Dialers file." grep "^tcp" /etc/uucp/Dialers > /dev/null 2>&1 if [ $? -eq 1 ] then echo 'tcp "" "" NLPS:000:001:101\\N\\c' >>/etc/uucp/Dialers fi # # NETWORK will be the name of the transport interface listener, # and NAME is the entry in the host file for that interface for # this machine. # while read NETWORK NAME do # # port monitor tags must be alphanumeric, but stuff in /etc/networks # can be anything. This tries to weed out the non-alphanum stuff # ALPHA_NETWORK=`echo $NETWORK | sed 's/[^A-Za-z0-9]//g'` NETWORK=$ALPHA_NETWORK # # build listen address # LISTEN_ADDRESS=`/usr/etc/rfsaddr -h $NAME -p $LISTEN_PORT` # # check to see if the port monitor is listening on a previous address # if [ "$LISTEN_ADDRESS" != "`nlsadmin -l - $NETWORK`" ] then # # remove all knowledge of the port monitor # echo "\tCreating $NETWORK listen address." /usr/sbin/sacadm -r -p $NETWORK rm -rf /etc/saf/$NETWORK fi # # start listen monitor and initialize if needed # sacadm -l -p $NETWORK > /dev/null 2>&1 if [ $? -ne 0 ] then echo "\tAdding $NETWORK listen service... " nlsadmin -i $NETWORK if [ $? -eq 0 ] then /usr/bin/nlsadmin -l $LISTEN_ADDRESS $NETWORK if [ $? -ne 0 ] then echo "Error: adding listen service and address" fi fi fi # # start lp service - This will setup lp service on listen port # pmadm -l -p $NETWORK -s lp > /dev/null 2>&1 if [ $? -ne 0 ] then echo "\tAdding lp service... " pmadm -a -p $NETWORK -s lp -i root -v `nlsadmin -V` \ -m `nlsadmin -o /var/spool/lp/fifos/listenS5` if [ $? -ne 0 ] then echo "Error: adding lp service to port monitor" fi fi # # start uucico service # pmadm -l -p $NETWORK -s 101 > /dev/null 2>&1 if [ $? -ne 0 ] then echo "\tAdding uucico service... " nlsadmin -a 101 -c "/usr/lib/uucp/uucico -r -0 -i TLI -u uucp" \ -y "uucp listener for net $NETWORK" $NETWORK if [ $? -ne 0 ] then echo "Error: adding uucicio service to port monitor" fi fi # # This sets up the network definitions in the /etc/netconfig # Database. # echo "\tChecking/Adding $NETWORK to /etc/netconfig..." MY_NETCONFIG=`echo $NETCONFIG | sed "s/^tcp/$NETWORK/"` grep "^$MY_NETCONFIG" /etc/netconfig >/dev/null 2>&1 if [ $? -eq 1 ] then echo $MY_NETCONFIG >> /etc/netconfig fi # # This checks for nodes in /dev for each network listener # and adds if required # echo "\tChecking/Adding /dev/$NETWORK..." if [ ! -c /dev/$NETWORK ] then if [ -c /dev/tcp ] then MAJMIN=/tmp/majmin ls -la /dev/tcp | nawk '{print $5 " " $6}' | sed "s/,//">$MAJMIN while read MAJ MIN do # # Create node for listener device # /sbin/mknod /dev/$NETWORK c $MAJ $MIN /usr/bin/chmod 666 /dev/$NETWORK done < $MAJMIN rm -f $MAJMIN fi fi # # Check to see if listen port is running. If not, start # nlsadmin -q $NETWORK if [ $? -eq 1 ] then echo "\tStarting $NETWORK listen deamon." nlsadmin -s $NETWORK > /dev/null 2>&1 if [ $? -ne 0 ] then echo "Error: starting $NETWORK port monitor" fi fi # # Add the net_spec to the /etc/uucp/Devices file # echo "\tChecking/Adding Device file for $NETWORK entry." grep "^$NETWORK" /etc/uucp/Devices >/dev/null 2>&1 if [ $? -eq 1 ] then echo "Adding $NETWORK to Devices file." echo $NETWORK"Device,eg "$NETWORK" - - TLI \D tcp" \ >>/etc/uucp/Devices fi done < $ENDPOINTS rm -f $ENDPOINTS echo "UUCP set-up completed..." echo " " echo "REMEMBER - This script did not set-up the /etc/uucp/Systems" echo " nor /etc/uucp/Permissions files. You must set" echo " these up by hand." Section 4: Reference Material This section lists the reference material that we used during our investigation. NCR System 3000 NCR UNIX SVR4 Administrator Guide: Advanced Tasks Release 2.00 (Source: NCR Corporation, D1-2266-B) UNIX Communications Facilities Managing UUCP and Usenet (Source: O'Reilly & Associates - A NUTSHELL HANDBOOK) Using UUCP and USENET (Source: O'Reilly & Associates - A NUTSHELL HANDBOOK) NCR System 3000 UNIX SVR4 MP User's/System Administrator's Reference Manual (Vol 1-5) (Source: NCR Corporation, D1-0373-B) NCR System 3000 SVR4 Online Manual Pages (man) NCR 3600 Global Support Center 05/05/93 REVISION - A 24