unx43.htm

Unix Unleashed, Third Edition is written with the power user and system administrator in mind. This

<BR></P>

<P>The third field is the dialer port. This is a bit of an anachronism, but in the past, some modems required a separate dialer device to make the phone call. This was the special file that pointed to the dialer for that modem. If the modem is capable of 
dialing, this field is marked with a dash.

<BR></P>

<P>The fourth field is the speed of the device. This is also used for matching the Systems file. That way a site can indicate multiple speeds for connections through multiple devices.

<BR></P>

<P>The last field is the dialer token pairs. This specifies a specific dialer pattern, found in the Dialers file, and any arguments passed thereto. Normally, only a single pair (or single entry, if it gets no arguments) is found; however, if the system 
needs to go through a switch to reach the modem, a chat script may be expected.

<BR></P>

<P>My Devices file is rather small, and it looks like this:

<BR></P>

<PRE>ACU ttya - 9600 tb9600

Direct ttya - 9600 direct</PRE>

<P>I have only the single modem, a Telebit QBlazer at 9600 baud. It is attached to /dev/ttya and uses the tb9600 dialer script when I connect via UUCP. It is configured to allow me to use cu to talk to the modem.

<BR></P>

<H5 ALIGN="CENTER">

<CENTER><A ID="I17" NAME="I17">

<FONT SIZE=3><B>Dialers</B>

<BR></FONT></A></CENTER></H5>

<P>The Dialers file is used to initiate conversation with the modem. It ties the dialer specified in the Devices file to a chat script. It consists of three fields. The first is the name of the dialer script. This must match exactly with the dialer 
specified in the Devices file. Like with devices, all dialers are one line and are started in the first column. The #, or white space, in the first column indicates a comment.

<BR></P>

<P>The second field is a translation table for older communication devices.

<BR></P>

<P>The third field is the chat script needed to talk with the modem and to place the call. My machine came with several dialers already installed, including dialers for penril, ventel, micom, hayes, and telebit modems. I looked over my set of telebit 
dialers, listed below, and selected tbfast for my first dialer for my ACU.

<BR></P>

<PRE>tb1200    =W-, &quot;&quot; \dA\pA\pA\pTE1V1X1Q0S2=255S12=255S50=2\r\c\

<BR> OK\r \EATDT\T\r\c CONNECT\s1200

tb2400    =W-, &quot;&quot; \dA\pA\pA\pTE1V1X1Q0S2=255S12=255S50=3\r\c\

<BR> OK\r \EATDT\T\r\c CONNECT\s2400

tbfast    =W-, &quot;&quot; \dA\pA\pA\pTE1V1X1Q0S2=255S12=255S50=255\r\c\

<BR> OK\r \EATDT\T\r\c CONNECT\sFAST</PRE>

<P>I knew I wasn't connecting at 1200 or 2400 baud, so it seemed that the fast connection was the way to go. I quickly learned that this was wrong! By using cu to mimic the dialing of the UUCP number, I saw that the final message was not CONNECT FAST, but 

CONNECT 9600. I first considered altering tbfast, but instead opted to write my own dialer, tb9600, in case I need to make other changes.

<BR></P>

<P>Note that each of these dialers has a long, confusing list of numbers and characters as the first send sequence. These are the parameters that need to be set in the modem for the UUCP call to take place, in a language the modem understands. Although the 

hayes modem syntax is fairly common, some modems do not use it, so you'll need to check your modem's documentation to determine the correct settings.

<BR></P>

<P>In my efforts, I found that by sending just the string to the modem, I'd get an error, because I didn't yet have the modem's attention. To get its attention, I'd need to send AT to the modem and receive back OK. I placed this at the beginning of my chat 

script. Testing also revealed that the best modem settings were different from those above, so I added them to the chat script, as well. It ended up looking like this:

<BR></P>

<PRE>tb9600    =W-, &quot;&quot; AT OK-AT-OK \dA\pA\pA\pTE1V1X1Q0S2=255S12=255S50=6S58=2S68=2S7=80\r\c\

<BR> OK\r \EATDT\T\r\c CONNECT\s9600-\c-CONNECT\s9600</PRE>

<P>Basically, I am setting modem registers to match what I need. I also wait for CONNECT 9600 a bit longer than the time-out, so if I don't get it, I just sit a little while longer. This is the dialer I use for my UUCP connections.

<BR></P>

<H5 ALIGN="CENTER">

<CENTER><A ID="I18" NAME="I18">

<FONT SIZE=3><B>Dialcodes</B>

<BR></FONT></A></CENTER></H5>

<P>The Dialcodes file is an optional file that equates some string with a series of numbers to be dialed. Although UUCP is perfectly happy to have a sequence such as 1028801144716194550,,2354 to reach a distant computer in the city of London, for a human 
being glancing at the file it may not be obvious. So Dialcodes permits the human to tie a string, innerlondon, to a dialing sequence 102880114471.

<BR></P>

<P>Because I have only one number, I don't use a Dialcodes file, but if you call many places nationwide, it might be useful.

<BR></P>

<H5 ALIGN="CENTER">

<CENTER><A ID="I19" NAME="I19">

<FONT SIZE=3><B>Permissions</B>

<BR></FONT></A></CENTER></H5>

<P>System security is one of the most pressing issues in the computer industry, and in UUCP it is no exception. Originally, UUCP allowed any user to write to any directory on the remote system, as long as the user ID for UUCP had write permissions. 
Similarly, reading files was also possible. This had the ugly effect of enabling users to steal remote password files with a simple UUCP command, and if any accounts weren't protected with passwords, those systems were definitely compromised. Similarly, 
with incorrect permissions, a remote user could do significant damage by moving or destroying important files.

<BR></P>

<P>The way around this problem is to use the Permissions file. This mechanism ties remote systems and accounts to specific read, write, and execute permissions. There are 13 different Permissions file entries, each with the format Option=Value. They must 
all be on the same line, although these lines may be broken with a backslash. Multiple values for an option are separated by colons. The 13 options are LOGNAME, MACHINE, REQUEST, SENDFILES,  READ, WRITE, NOREAD, NOWRITE, CALLBACK, COMMANDS, VALIDATE, 
MYNAME, and PUBDIR.

<BR></P>

<P>The meaning of each option are described below.

<BR></P>

<P>LOGNAME refers to a specific login name used by the remote site to gain access. By specifying the LOGNAME, you can tie various options to the login call.

<BR></P>

<P>MACHINE refers to the machine name of the remote UUCP site. Specific permissions can be tied to a LOGNAME or to a MACHINE.

<BR></P>

<P>REQUEST is a yes/no flag indicating whether a remote machine can request files from your machine. The default is no. By permitting a remote system to request files, a command such as uucp mymach!myfile anotherfile can be executed from a remote machine. 

On a trusted network, that may be fine, but it is an invitation to trouble if set up on a link where you don't always know who is on the other end.

<BR></P>

<P>SENDFILES is another yes/no flag, but it is only tied to the LOGNAME. If set to yes, your system will send files to the remote system even if the remote system initiates the call. If you set the value to no, you will never send out files, and if you set 

it to call, you will send out files only when you have initiated the call.

<BR></P>

<P>READ specifies the directories from which uucico can access files for transfer. The default is /var/spool/ucppublic.

<BR></P>

<P>WRITE specifies the directories to which uucico may write files. Again, the default is /var/spool/uucppublic. These two options are designed to keep harm from uucp restricted to a public file system.

<BR></P>

<P>NOREAD and NOWRITE are exceptions to the other directories. For example, on a trusted network, you may want to set your directory open to reading, by setting READ=/home/james. However, you might have your own private directory that you don't want anyone 

to touch. To set this, you can have the options read READ=/home/james NOREAD=/home/james/.Private.

<BR></P>

<P>CALLBACK is another yes/no option. When set to yes, your system must call the remote system back before any transactions may take place. The default value is no. Be particularly careful using this option, because if both machines set CALLBACK to yes, 
they will never communicate. Also, if one system sets SENDFILES to call, and the other has CALLBACK as yes, the first system will never transfer files to the second. CALLBACK is definitely a security feature, because a remote site could always fake a 
machine name and steal a password, so by calling back you know with whom you are talking. It is also useful if one site has a particularly cheaper phone rate than the other.

<BR></P>

<P>COMMANDS is a very important option. The default is usually to permit rmail and rnews, the programs to receive mail and netnews. If set to ALL, any command that can be found in the local path of uuxqt will be executed. Because this often includes 
commands such as cat and rm, this is usually not recommended. The COMMANDS option is tied to a MACHINE name calling in.

<BR></P>

<P>VALIDATE is an option tied to the LOGNAME, and if set to yes, will validate the calling system's identity.

<BR></P>

<P>MYNAME is an option to provide another system name for the local name. This is useful if you need an alternate UUCP name.

<BR></P>

<P>PUBDIR is an option to specify a directory to be treated as the public directory for reading and writing. The default is /var/spool/uucppublic.

<BR></P>

<P>Although this may seem complicated, the default permissions are designed to keep a system secure, and it is only when you want to loosen permissions that you need to edit the Permissions file.

<BR></P>

<P>My Permissions file is rather simple, with a single entry:

<BR></P>

<PRE>MACHINE=netcomsv COMMANDS=rmail:rnews SENDFILES=yes</PRE>

<P>It enables the machine netcomsv to execute rmail and rnews, and it enables me to send files to them.

<BR></P>

<H5 ALIGN="CENTER">

<CENTER><A ID="I20" NAME="I20">

<FONT SIZE=3><B>Sysfiles</B>

<BR></FONT></A></CENTER></H5>

<P>Sysfiles is a special addition that allows the system to specify different Systems files for different services. It also allows for multiple Systems, Devices, and Dialers files, should these become long.

<BR></P>

<P>The format is simple. There are four keywords: service, systems, devices, and dialers. The format is always keyword=value. The service keywords can be uucico or cu, the two commands that access the UUCP files. The other three are files that replace the 

Systems, Devices, and Dialers files for that service. Each field is separated by a colon.

<BR></P>

<H5 ALIGN="CENTER">

<CENTER><A ID="I21" NAME="I21">

<FONT SIZE=3><B>Poll</B>

<BR></FONT></A></CENTER></H5>

<P>The Poll file is a list of times to poll a remote system. It is accessed by an administrative daemon to establish a fake request and force a UUCP call at a specific time. Its format is a system name followed by a tab, and a space-separated list of 
integers from 0 to 23, representing the hours of a 24-hour clock.

<BR></P>

<H4 ALIGN="CENTER">

<CENTER><A ID="I22" NAME="I22">

<FONT SIZE=3><B>Supporting Files</B>

<BR></FONT></A></CENTER></H4>

<P>UUCP creates many different files and file types. Briefly, they are work files, data files, status files, lock files, log files, and temporary files.

<BR></P>

<P>Work files are located in /var/spool/uucp/<I>machine name</I>, and are prefixed with the letter C. They are the workhorse for UUCP, because they list the specific files to be transferred, including the local and remote names, permissions, and owner. A 
request to send remote mail may look like this:

<BR></P>

<PRE>S D.dukeb3ae48e D.dukeb3ae48e james - D.dukeb3ae48e 0666 james

S D.netco0c7f621 X.dukeNb3ae james - D.netco0c7f621 0666 james</PRE>

<P>This indicates that two files are to be transferred.

<BR></P>

<P>The data files are kept in the same directory, but are prefixed with D. Even the files that specify remote execution are prefixed with D. In this request are two data files being transferred, one to become a data file on the remote machine, the other to 

become an execute file.

<BR></P>

<P>Execute files are identified by the prefix X. This prefix is sought by uuxqt, which is the program that actually runs the requested commands. These have their own format, indicating the command to be run and the input file to use.

<BR></P>

<P>Status files are kept in /var/spool/uucp/.Status, and have a specific format. There is a single status file per system, with six fields. The first is a type field, the second is a count field (used to indicate the number of retries, for example). The 
third field is a UNIX time to identify the last connection attempt. The fourth is the number of seconds before a retry attempt may be taken, the fifth is ASCII text to describe the status, and the sixth is the machine name. Status files are usually 
accessed by the uustat command.

<BR></P>

<P>Lock files are created when a call is attempted, and the lock files are in /var/spool/locks. These files contain the process ID of the uucico request that has locked the system.

<BR></P>

<P>Log files are kept in /var/spool/uucp/.Log. They are cleaned out daily by a daemon to prevent them from growing beyond control. Separate logs are kept for the uucico, uucp, uux, and uuxqt commands, each in a file named for the remote system. These are 
often accessed with the uulog command.

<BR></P>

<P>Finally, temporary files may be created by UUCP. These are in the directory with the work files and are prefixed with TM.

<BR></P>

<H4 ALIGN="CENTER">

<CENTER><A ID="I23" NAME="I23">

<FONT SIZE=3><B>UUCP Daemons</B>

<BR></FONT></A></CENTER></H4>

<P>There are four UUCP daemons that should be invoked on a regular basis. They are the admin daemon, the cleanup daemon, the polling daemon, and the hourly daemon. These are all started out of cron.

<BR></P>

<H5 ALIGN="CENTER">

<CENTER><A ID="I24" NAME="I24">

<FONT SIZE=3><B>The </B><B><I>admin</I></B><B> Daemon</B>

<BR></FONT></A></CENTER></H5>

<P>The admin daemon is a daemon that should be invoked at least once a day. It will give, by e-mail, a brief image of the state of UUCP, including a snapshot of the running processes and a listing of the job queue. It will also check the log files to see 
if there have been any attempts to transfer the passwd file.

<BR></P>

<H5 ALIGN="CENTER">

<CENTER><A ID="I25" NAME="I25">

<FONT SIZE=3><B>The </B><B><I>cleanup</I></B><B> Daemon</B>

<BR></FONT></A></CENTER></H5>

<P>The cleanup daemon is one of the hardest workers. It should be invoked daily, at a time when few users are likely to be on the system. It will back up all the log files and save them for three days. It will then make the current log files zero length. 
Other administrative files not discussed here are also backed up.

<BR></P>

<P>The cleanup daemon will invoke the uucleanup command. This command removes old jobs from the queue, based on a command line argument. On my system, I have stuck with the defaults, seven days until a delete, and one day until a warning.

<BR></P>

<P>The daemon then removes old files, empty subdirectories, and core files. When it finishes this, it sends e-mail to the UUCP administrator announcing what it has done.

<BR></P>

<H5 ALIGN="CENTER">

<CENTER><A ID="I26" NAME="I26">

<FONT SIZE=3><B>The </B><B><I>polling</I></B><B> Daemon</B>

<BR></FONT></A></CENTER></H5>

<P>This daemon quickly examines the Poll file to create polling requests for uucico. This is essentially touching a file in the spool directory. It should be executed hourly.

<BR></P>

<H5 ALIGN="CENTER">

<CENTER><A ID="I27" NAME="I27">

<FONT SIZE=3><B>The </B><B><I>hourly</I></B><B> Daemon</B>

<BR></FONT></A></CENTER></H5>

<P>The hourly demon should be invoked each hour. It just runs the uusched command, which examines the spool to find any queued jobs, and if it finds jobs, it runs uucico for that system. When it finishes, it runs uuxqt to execute any incoming jobs.

<BR></P>

<H3 ALIGN="CENTER">

<CENTER><A ID="I28" NAME="I28">

<FONT SIZE=4><B>Using UUCP</B>

<BR></FONT></A></CENTER></H3>

<P>Earlier in this chapter you were introduced to the commands uucp and uux, which are two of the most common commands for UUCP. There are two alternate commands, uuto and uupick, which ease the process.

<BR></P>

<P>The uucp command is the basic command for the transportation of files from one machine to another. The basic form allows for the specification of two paths to files, one being the original file, the other being the destination. uucp can take a number of 

arguments to help facilitate the transfer. By default, uucp will use the source file for originating the transfer. This means that if the source file is changed before the transfer is completed, the changed file will be sent. If that is not desired, the 
file can be copied to a temporary file for uucp, which is done by specifying the -C option. By default, uucp will also create the necessary destination directories, if it has permission to do so. This is the -d option and is turned off by -f. uucp also 
will assign a job ID to the transfer with the -j option. The -m option can be used to let the sender know when the job is complete (uucp will send a mail message to the requestor). The -g option enables the user to set the transfer grade (a single 
character from 0 to 9, A to Z, or a to z. 0 is highest, and z is lowest).

<BR></P>

<P>Similar to the -m option, the -n option followed by a user name will notify the user at the remote machine when the transfer is complete. Debugging information can be found with -x. To prevent an immediate start of uucico, use -r.