This is Info file uucp.info, produced by Makeinfo-1.55 from the input file /usr/src/gnu/libexec/uucp/doc/uucp.texi. This file documents Taylor UUCP, version 1.05. Copyright (C) 1992, 1993, 1994 Ian Lance Taylor Permission is granted to make and distribute verbatim copies of this manual provided the copyright notice and this permission notice are preserved on all copies. Permission is granted to copy and distribute modified versions of this manual under the conditions for verbatim copying, provided also that the section entitled "Copying" are included exactly as in the original, and provided that the entire resulting derived work is distributed under the terms of a permission notice identical to this one. Permission is granted to copy and distribute translations of this manual into another language, under the above conditions for modified versions, except that the section entitled "Copying" may be included in a translation approved by the author instead of in the original English.  File: uucp.info, Node: Top, Next: Copying, Prev: (dir), Up: (dir) Taylor UUCP 1.05 **************** This is the documentation for the Taylor UUCP package, version 1.05. The programs were written by Ian Lance Taylor. The author can be reached at `', or `c/o Cygnus Support, Building 200, 1 Kendall Square, Cambridge, MA, 02139, USA'. There is a mailing list for discussion of the package. To join (or get off) the list, send mail to `'. Mail to this address is answered by a person, not a program. When joining the list, please give the address at which you wish to receive mail; do not rely on the message headers. To send a message to the list, send it to `'. Jeff Ross has volunteered to maintain patches for UUCP releases. They may be obtained via anonymous FTP from ftp.fdu.edu, in the directory pub/taylor-uucp. * Menu: * Copying:: Taylor UUCP copying conditions * Introduction:: Introduction to Taylor UUCP * Overall Installation:: Taylor UUCP installation * Configuration Files:: Taylor UUCP configuration files * Protocols:: UUCP protocol internals * Hacking:: Hacking Taylor UUCP * Acknowledgements:: Acknowledgements * Index (concepts):: Concept index * Index (configuration file):: Index to new configuration files -- The Detailed Node Listing -- Taylor UUCP Overall Installation * Configuration:: Configuring Taylor UUCP * Compilation:: Compiling Taylor UUCP * Testing:: Testing Taylor UUCP * Installation:: Installing Taylor UUCP * TCP:: TCP together with Taylor UUCP Installing Taylor UUCP * Running uucico:: Running uucico * Using UUCP for mail and news:: Using UUCP for mail and news. * Trimming UUCP Log Files:: Trimming UUCP Log Files Using UUCP for mail and news. * Sending mail or news:: Sending mail or news via UUCP * Receiving mail or news:: Receiving mail or news via UUCP Taylor UUCP Configuration Files * Configuration File Format:: Configuration file format * Configuration File Overview:: Configuration File Overview * Configuration Examples:: Examples of configuration files * Time Strings:: How to write time strings * Chat Scripts:: How to write chat scripts * config File:: The main configuration file * sys File:: The system configuration file * port File:: The port configuration files * dial File:: The dialer configuration files * Security:: Security issues Examples of Configuration Files * config File Examples:: Examples of the main configuration file * Leaf Example:: Call a single remote site * Gateway Example:: The gateway for several local systems The Main Configuration File * Miscellaneous (config):: Miscellaneous config file commands * Configuration File Names:: Using different configuration files * Log File Names:: Using different log files * Debugging Levels:: Debugging levels The System Configuration File * Defaults and Alternates:: Using defaults and alternates * Naming the System:: Naming the system * Calling Out:: Calling out * Accepting a Call:: Accepting a call * Protocol Selection:: Protocol selection * File Transfer Control:: File transfer control * Miscellaneous (sys):: Miscellaneous sys file commands * Default sys File Values:: Default values Calling Out * When to Call:: When to call * Placing the Call:: Placing the call * Logging In:: Logging in Hacking Taylor UUCP * System Dependence:: System Dependence * Naming Conventions:: Naming Conventions * Patches:: Patches  File: uucp.info, Node: Copying, Next: Introduction, Prev: Top, Up: Top Taylor UUCP Copying Conditions ****************************** This package is covered by the GNU Public License. See the file `COPYING' for details. If you would like to do something with this package that you feel is reasonable, but you feel is prohibited by the license, contact me to see if we can work it out. Here is some propaganda from the Free Software Foundation. If you find this stuff offensive or annoying, remember that you probably did not spend any money to get this code. I did not write this code to make life easier for developers of UUCP packages, I wrote it to help end users, and I believe that these are the most appropriate conditions for distribution. All the programs, scripts and documents relating to Taylor UUCP are "free"; this means that everyone is free to use them and free to redistribute them on a free basis. The Taylor UUCP-related programs are not in the public domain; they are copyrighted and there are restrictions on their distribution, but these restrictions are designed to permit everything that a good cooperating citizen would want to do. What is not allowed is to try to prevent others from further sharing any version of these programs that they might get from you. Specifically, we want to make sure that you have the right to give away copies of the programs that relate to Taylor UUCP, that you receive source code or else can get it if you want it, that you can change these programs or use pieces of them in new free programs, and that you know you can do these things. To make sure that everyone has such rights, we have to forbid you to deprive anyone else of these rights. For example, if you distribute copies of the Taylor UUCP related programs, you must give the recipients all the rights that you have. You must make sure that they, too, receive or can get the source code. And you must tell them their rights. Also, for our own protection, we must make certain that everyone finds out that there is no warranty for the programs that relate to Taylor UUCP. If these programs are modified by someone else and passed on, we want their recipients to know that what they have is not what we distributed, so that any problems introduced by others will not reflect on our reputation. The precise conditions of the licenses for the programs currently being distributed that relate to Taylor UUCP are found in the General Public Licenses that accompany them.  File: uucp.info, Node: Introduction, Next: Overall Installation, Prev: Copying, Up: Top Introduction to Taylor UUCP *************************** General introductions to UUCP are available, and perhaps one day I will write one. In the meantime, here is a very brief one that concentrates on the programs provided by Taylor UUCP. Taylor UUCP is a complete UUCP package. It is covered by the GNU Public License, which means that the source code is always available. It is composed of several programs; most of the names of these programs are based on earlier UUCP packages. `uucp' The `uucp' program is used to copy file between systems. It is similar to the standard Unix `cp' program, except that you can refer to a file on a remote system by using `system!' before the file name. For example, to copy the file `notes.txt' to the system `airs', you would say `uucp notes.txt airs!~/notes.txt'. In this example `~' is used to name the UUCP public directory on `airs'. `uux' The `uux' program is used to request the execution of a program on a remote system. This is how mail and news are transferred over UUCP. As with `uucp', programs and files on remote systems may be named by using `system!'. For example, to run the `rnews' program on `airs' passing it standard input, you would say `uux - airs!rnews'. The `-' means to read standard input and set things up such that when `rnews' runs on `airs' it will receive the same standard input. Neither `uucp' nor `uux' actually do any work immediately. Instead, they queue up requests for later processing. They then start a daemon process which processes the requests and calls up the appropriate systems. Normally the system will also start the daemon periodically to check if there is any work to be done. The advantage of this approach is that it all happens automatically. You don't have to sit around waiting for the files to be transferred. The disadvantage is that if anything goes wrong it might be a while before anybody notices. `uustat' The `uustat' program does many things. By default it will simply list all the jobs you have queued with `uucp' or `uux' that have not yet been processed. You can use `uustat' to remove any of your jobs from the queue. You can also it use it to show the status of the UUCP system in various ways, such as showing the connection status of all the remote systems your system knows about. The system administrator can use `uustat' to automatically discard old jobs while sending mail to the user who requested them. `uuname' The `uuname' program by default lists all the remote systems your system knows about. You can also use it to get the name of your local system. It is mostly useful for shell scripts. `uulog' The `uulog' program can be used to display entries in the UUCP log file. It can select the entries for a particular system or a particular user. You can use it to see what has happened to your queued jobs in the past. `uuto' `uupick' `uuto' is a simple shell script interface to `uucp'. It will transfer a file, or the contents of a directory, to a remote system, and notify a particular user on the remote system when it arrives. The remote user can then retrieve the file(s) with `uupick'. `cu' The `cu' program can be used to call up another system and communicate with it as though you were directly connected. It can also do simple file transfers, though it does not provide any error checking. These eight programs just described, `uucp', `uux', `uuto', `uupick', `uustat', `uuname', `uulog', and `cu' are the user programs provided by Taylor UUCP. `uucp', `uux', and `uuto' add requests to the work queue, `uupick' extracts files from the UUCP public directory, `uustat' examines the work queue, `uuname' examines the configuration files, `uulog' examines the log files, and `cu' just uses the UUCP configuration files. The real work is actually done by two daemon processes, which are normally run automatically rather than by a user. `uucico' The `uucico' daemon is the program which actually calls the remote system and transfers files and requests. `uucico' is normally started automatically by `uucp' and `uux'. Most systems will also start it periodically to make sure that all work requests are handled. `uucico' checks the queue to see what work needs to be done, and then calls the appropriate systems. If the call fails, perhaps because the phone line is busy, `uucico' leaves the requests in the queue and goes on to the next system to call. It is also possible to force `uucico' to call a remote system even if there is no work to be done for it, so that it can pick up any work that may be queued up remotely. `uuxqt' The `uuxqt' daemon processes execution requests made by the `uux' program on remote systems. It also processes requests made on the local system which require files from a remote system. It is normally started by `uucico'. Suppose you, on the system `bantam', want to copy a file to the system `airs'. You would run the `uucp' command locally, with a command like `uucp notes.txt airs!~/notes.txt'. This would queue up a request on `bantam' for `airs', and would then start the `uucico' daemon. `uucico' would see that there was a request for `airs' and attempt to call it. When the call succeeded, another copy of `uucico' would be started on `airs'. The two copies of `uucico' would tell each other what they had to do and transfer the file from `bantam' to `airs'. When the file transfer was complete the `uucico' on `airs' would move it into the UUCP public directory. UUCP is often used to transfer mail. This is normally done automatically by mailer programs. When `bantam' has a mail message to send to `ian' at `airs', it executes `uux - airs!rmail ian' and writes the mail message to the `uux' process as standard input. The `uux' program, running on `bantam', will read the standard input and store it, as well as the `rmail' request itself, on the work queue for `airs'. `uux' will then start the `uucico' daemon. The `uucico' daemon will call up `airs', just as in the `uucp' example, and transfer the work request and the mail message. The `uucico' daemon on `airs' will put the files on a local work queue. When the communication session is over, the `uucico' daemon on `airs' will start the `uuxqt' daemon. `uuxqt' will see the request to run, and will run `rmail ian' with the mail message as standard input. The `rmail' program, which is not part of the UUCP package, is then responsible for either putting the message in the right mailbox on `airs' or forwarding the message on to another system. Taylor UUCP comes with a few other programs that are useful when installing and configuring UUCP. `uuchk' The `uuchk' program reads the UUCP configuration files and displays a rather lengthy description of what it finds. This is useful when configuring UUCP to make certain that the UUCP package will do what you expect it to do. `uuconv' The `uuconv' program can be used to convert UUCP configuration files from one format to another. This can be useful for administrators converting from an older UUCP. Taylor UUCP is able to read and use old configuration file formats, but some new features can not be selected using the old formats. `uusched' The `uusched' script is just provided for compatibility with older UUCP releases. It starts `uucico' to call, one at a time, all the systems for which work has been queued. `tstuu' The `tstuu' program is a test harness for the UUCP package; it can help check that the package has been configured and compiled correctly. However, it uses pseudo-terminals, which means that it is less portable than the rest of the package. If it works, it can be useful when initially installing Taylor UUCP.  File: uucp.info, Node: Overall Installation, Next: Configuration Files, Prev: Introduction, Up: Top Taylor UUCP Overall Installation ******************************** These are the installation instructions for the Taylor UUCP package. * Menu: * Configuration:: Configuring Taylor UUCP * Compilation:: Compiling Taylor UUCP * Testing:: Testing Taylor UUCP * Installation:: Installing Taylor UUCP * TCP:: TCP together with Taylor UUCP  File: uucp.info, Node: Configuration, Next: Compilation, Prev: Overall Installation, Up: Overall Installation Configuring Taylor UUCP ======================= You will have to decide what types of configuration files you want to use. This package supports a new sort of configuration file; see *Note Configuration Files::. It also supports V2 configuration files (`L.sys', `L-devices', etc.) and HDB configuration files (`Systems', `Devices', etc.). No documentation is provided for V2 or HDB configuration files. All types of configuration files can be used at once, if you are so inclined. Currently using just V2 configuration files is not really possible, because there is no way to specify a dialer (there are no built in dialers, and the program does not know how to read `acucap' or `modemcap'); however, V2 configuration files can be used with a new style dial file (*note dial File::.), or with a HDB `Dialers' file. Use of HDB configuration files has two known bugs. A blank line in the middle of an entry in the `Permissions' file will not be ignored as it should be. Dialer programs, as found in some versions of HDB, are not recognized directly. If you must use a dialer program, rather than an entry in `Devices', you must use the `chat-program' command in a new style dial file; see *Note dial File::. You will have to invoke the dialer program via a shell script or another program, since an exit code of 0 is required to recognize success; the `dialHDB' program in the `contrib' directory may be used for this purpose. The `uuconv' program can be used to convert from V2 or HDB configuration files to the new style (it can also do the reverse translation, if you are so inclined). It will not do all of the work, and the results should be carefully checked, but it can be quite useful. If you are installing a new system, you will, of course, have to write the configuration files; see *Note Configuration Files::. You must also decide what sort of spool directory you want to use. If you will be using only these programs for UUCP, I recommend `SPOOLDIR_TAYLOR'; otherwise select the spool directory corresponding to your existing UUCP package. The details of the spool directory choices are described at somewhat tedious length in `unix/spool.c'.  File: uucp.info, Node: Compilation, Next: Testing, Prev: Configuration, Up: Overall Installation Compiling Taylor UUCP ===================== 1. Take a look at the top of `Makefile.in' and set the appropriate values for your system. These control where the programs are installed and which user on the system owns them (normally they will be owned by a special user `uucp' rather than a real person; they should probably not be owned by `root'). 2. Run the shell script `configure'. This script was generated using the `autoconf' program written by David MacKenzie of the Free Software Foundation. It takes a while to run. It will generate the file `config.h' based on `config.h.in', and, for each source code directory, will generate `Makefile' based on `Makefile.in'. You can pass certain arguments to `configure' in the environment. Because `configure' will compile little test programs to see what is available on your system, you must tell it how to run your compiler. It recognizes the following environment variables: `CC' The C compiler. If this is not set, then if `configure' can find `gcc' it will use it, otherwise it will use `cc'. `CFLAGS' Flags to pass to the C compiler when compiling the actual code. If this is not set, `configure' will use `-g'. `LDFLAGS' Flags to pass to the C compiler when only linking, not compiling. If this is not set, `configure' will use the empty string. `LIBS' Libraries to pass to the C compiler. If this is not set, `configure' will use the empty string. `INSTALL' The program to run to install UUCP in the binary directory. If this is not set, then if `configure' finds the BSD `install' program, it will set this to `install -c'; otherwise, it will use `cp'. `INSTALLDATA' The program to run to install UUCP data files, such as the man pages and the info pages. If this is not set, then if `configure' finds the BSD `install' program, it will set this to `install -c -m 644'; otherwise, it will use `cp'. Suppose you want to set the environment variable `CC' to `rcc'. If you are using `sh' or `bash', invoke `configure' as `CC=rcc configure'. If you are using `csh', do `setenv CC rcc; sh configure'. On some systems you will want to use `LIBS=-lmalloc'. On Xenix derived versions of Unix do not use `LIBS=-lx' because this will bring in the wrong versions of certain routines; if you want to use `-lx' you must specify `LIBS=-lc -lx'. If `configure' fails for some reason, or if you have a very weird system, you may have to configure the package by hand. To do this, copy the file `config.h.in' to `config.h' and edit it for your system. Then for each source directory (the top directory, and the subdirectories `lib', `unix', and `uuconf') copy `Makefile.in' to `Makefile', find the words within `@' characters, and set them correctly for your system. 3. Igor V. Semenyuk provided this (lightly edited) note about ISC Unix 3.0. The `configure' script will default to passing `-posix' to `gcc'. However, using `-posix' changes the environment to POSIX, and on ISC 3.0, at least, the default for POSIX_NO_TRUNC is 1. This means nothing for uucp, but can lead to a problem when uuxqt executes rmail. IDA sendmail has dbm configuration files named `mailertable.{dir,pag}'. Notice these names are 15 characters long. When uuxqt compiled with `-posix' executes rmail, which in turn executes sendmail, the later is run under POSIX environment too! This leads to sendmail bombing out with `'error opening 'M' database: name too long' (mailertable.dir)'. It's rather obscure behaviour, and it took me a day to find out the cause. I don't use `-posix', instead I run `gcc' with `-D_POSIX_SOURCE', and add `-lcposix' to `LIBS'. 4. On some versions of BSDI there is a bug in the shell which causes the default value for `CFLAGS' to be set incorrectly. If `echo ${CFLAGS--g}' echoes `g' rather than `-g', then you must set `CFLAGS' in the environment before running configure. There is a patch available from BSDI for this bug. (From David Vrona). 5. On AIX 3.2.5, and possibly other versions, `cc -E' does not work, reporting `Option NOROCONST is not valid'. Test this before running configure by doing something like `touch /tmp/foo.c; cc -E /tmp/foo.c'. This may give a warning about the file being empty, but it should not give the `Option NOROCONST' warning. The workaround is to remove the `,noroconst' entry from the `options' clause in the `cc' stanza in `/etc/xlc.cfg'. (From Chris Lewis). 6. You should verify that `configure' worked correctly by checking `config.h' and the instances of `Makefile'. 7. Edit `policy.h' for your local system. The comments should explain the various choices. The default values are intended to be reasonable, so you may not have to make any changes. 8. Type `make' to compile everything. The `tstuu.c' file is not particularly portable; if you can't figure out how to compile it you can safely ignore it, as it is only used for testing (to use STREAMS pseudo-terminals, tstuu.c must be compiled with `-DHAVE_STREAMS_PTYS'; this is not automatically determined at the moment). If you have any other problems there is probably a bug in the `configure' script. 9. Please report any problems you have. That is the only way they will get fixed for other people. Supply a patch if you can (*note Patches::.), or just ask for help.  File: uucp.info, Node: Testing, Next: Installation, Prev: Compilation, Up: Overall Installation Testing Taylor UUCP =================== This package is in use at hundreds, perhaps thousands, of sites, and has been running at `airs.com' for several years. However, it will doubtless fail in some situations. Do not rely on this code until you have proven to yourself that it will work. You can use the `uuchk' program to test your configuration files. It will read them and print out a verbose description. This program should not be made setuid, because it will display passwords if it can read them. If your system supports pseudo-terminals, and you compiled the code to support the new style of configuration files, you should be able to use the `tstuu' program to test the `uucico' daemon (if your system supports STREAMS based pseudo-terminals, you must compile tstuu.c with `-DHAVE_STREAMS_PTYS', at least at the moment; the STREAMS based code was contributed by Marc Boucher). To run `tstuu', just type `tstuu' with no arguments while logged in to the compilation directory (since it runs `./uucp', `./uux' and `./uucico'). It will run a lengthy series of tests (it takes over ten minutes on a slow VAX). You will need a fair amount of space available in `/usr/tmp'. You will probably want to put it in the background. Do not use `^Z', because the program traps on `SIGCHLD' and winds up dying. It will create a directory `/usr/tmp/tstuu' and fill it with configuration files, and create spool directories `/usr/tmp/tstuu/spool1' and `/usr/tmp/tstuu/spool2'. If your system does not support the `FIONREAD' call, the `tstuu' program will run very slowly. This may or may not get fixed in a later version. The program will finish with an execute file named `X.SOMETHING' and a data file named `D.SOMETHING' in the directory `/usr/tmp/tstuu/spool1' (or, more likely, in subdirectories, depending on the choice of `SPOOLDIR' in `policy.h'). Two log files will be created in the directory `/usr/tmp/tstuu'. They will be named `Log1' and `Log2', or, if you have selected `HAVE_HDB_LOGGING' in `policy.h', `Log1/uucico/test2' and `Log2/uucico/test1'. You can test `uuxqt' by running the command `./uuxqt -I /usr/tmp/tstuu/Config1'. This should leave a command file `C.SOMETHING' and a data file `D.SOMETHING' in `/usr/tmp/tstuu/spool1' or in subdirectories. Again, there should be no errors in the log file. Assuming you compiled the code with debugging enabled, the `-x' switch can be used to set debugging modes; see the `debug' command for details (*note Debugging Levels::.). Use `-x all' to turn on all debugging and generate far more output than you will ever want to see. The `uucico' daemons will put debugging output in the files `Debug1' and `Debug2' in the directory `/usr/tmp/tstuu'. After that, you're pretty much on your own. On some systems you can also use `tstuu' to test `uucico' against the system `uucico', by using the `-u' switch. For this to work, change the definitions of `ZUUCICO_CMD' and `UUCICO_EXECL' at the top of `tstuu.c' to something appropriate for your system. The definitions in `tstuu.c' are what I used for Ultrix 4.0, on which `/usr/lib/uucp/uucico' is particularly obstinate about being run as a child; I was only able to run it by creating a login name with no password whose shell was `/usr/lib/uucp/uucico'. Calling login in this way will leave fake entries in `wtmp' and `utmp'; if you compile `tstout.c' (in the `contrib' directory) as a setuid `root' program, `tstuu' will run it to clear those entries out. On most systems, such hackery should not be necessary, although on SCO I had to su to `root' (`uucp' might also have worked) before I could run `/usr/lib/uucp/uucico'. You can test `uucp' and `uux' (give them the `-r' switch to keep them from starting `uucico') to make sure they create the right sorts of files. Unfortunately, if you don't know what the right sorts of files are, I'm not going to tell you here. If `tstuu' passes, or you can't run it for some reason or other, move on to testing with some other system. Set up the configuration files (*note Configuration Files::.), or use an existing configuration. Tell `uucico' to dial out to the system by using the `-s' system switch (e.g. `uucico -s uunet'). The log file should tell you what happens. If you compiled the code with debugging enabled, you can use debugging mode to get a great deal of information about what sort of data is flowing back and forth; the various possibilities are described under the `debug' command (*note Debugging Levels::.). When initially setting up a connection `-x chat' is probably the most useful (e.g. `uucico -s uunet -x chat'); you may also want to use `-x handshake,incoming,outgoing'. You can use `-x' multiple times on one command line, or you can give it comma separated arguments as in the last example. Use `-x all' to turn on all possible debugging information. The debugging information is written to a file, normally `/usr/spool/uucp/Debug', although the default can be changed in `policy.h' and the `config' file can override the name with the `debugfile' command. The debugging file may contain passwords and some file contents as they are transmitted over the line, so the debugging file is only readable by the `uucp' user. You can use the `-f' switch to force `uucico' to call out even if the last call failed recently; using `-S' when naming a system has the same effect. Otherwise the status file (in the `.Status' subdirectory of the main spool directory, normally `/usr/spool/uucp') will prevent too many attempts from occurring in rapid succession. Again, please let me know about any problems you have and how you got around them. If you do report a problem, please include the version number of the package you are using, and a sample of the debugging file showing the problem (debugging information is usually what is needed, not just the log file). General questions such as "why doesn't uucico dial out" are impossible to answer without much more information.  File: uucp.info, Node: Installation, Next: TCP, Prev: Testing, Up: Overall Installation Installing Taylor UUCP ====================== You can install the executable files by becoming `root' and typing `make install'. Or you can look at what `make install' does and do it by hand. It tries to preserve your old programs, if any, but it only does this the first time Taylor UUCP is installed (so that if you install several versions of Taylor UUCP, you can still go back to your original UUCP programs). You can retrieve the original programs by typing `make uninstall'. Note that by default the programs are compiled with debugging information, and they are not stripped when they are installed. You may want to strip the installed programs to save disk space. See your system documentation for strip for more information. However, simply installing the executable files is not enough. You must also arrange for them to be used correctly. * Menu: * Running uucico:: Running uucico * Using UUCP for mail and news:: Using UUCP for mail and news. * Trimming UUCP Log Files:: Trimming UUCP Log Files  File: uucp.info, Node: Running uucico, Next: Using UUCP for mail and news, Prev: Installation, Up: Installation Running uucico -------------- By default `uucp' and `uux' will automatically start up `uucico' to call another system whenever work is queued up. However, the call may fail, or you may have put in time restrictions which prevent the call at that time (perhaps because telephone rates are high) (*note When to Call::.). Also, a remote system may have work queued up for your system, but may not be calling you for some reason (perhaps you have agreed that your system should always place the call). To make sure that works get transferred between the systems withing a reasonable time period, you should arrange to periodically invoke `uucico'. These periodic invocations are normally caused by entries in the `crontab' file. The exact format of `crontab' files, and how new entries are added, varies from system to system; check your local documentation (try `man cron'). To attempt to call all systems with outstanding work, use the command `uucico -r1'. To attempt to call a particular system, use the command `uucico -s SYSTEM'. To attempt to call a particular system, but only if there is work for it, use the command `uucico -C -s SYSTEM'. A common case is to want to try to call a system at a certain time, with periodic retries if the call fails. A simple way to do this is to create an empty UUCP command file, known as a "poll file". If a poll file exists for a system, then `uucico -r1' will place a call to it. If the call succeeds, the poll file will be deleted. The file can be easily created using the `touch' command. The name of a poll file currently depends on the type of spool directory you are using, as set in `policy.h'. If you are using `SPOOLDIR_TAYLOR' (the default), put something like this in your `crontab' file: touch /usr/spool/uucp/SYS/C./C.A0000 In this example SYS is the system you wish to call, and `/usr/spool/uucp' is your UUCP spool directory. If you are using `SPOOLDIR_HDB', use touch /usr/spool/uucp/SYS/C.SYSA0000 For example, I use the following crontab entries locally: 45 * * * * /bin/echo /usr/lib/uucp/uucico -r1 | /bin/su uucpa 40 4,10,15 * * * touch /usr/spool/uucp/uunet/C./C.A0000 Every hour, at 45 minutes past, this will check if there is any work to be done, and, if there is, will call the appropriate system. Also, at 4:40am, 10:40am and 3:40pm this will create a poll file file for `uunet', forcing the next check to call `uunet'.  File: uucp.info, Node: Using UUCP for mail and news, Next: Trimming UUCP Log Files, Prev: Running uucico, Up: Installation Using UUCP for mail and news. ----------------------------- Taylor UUCP does not include a mail package. All Unix systems come with some sort of mail delivery agent, typically `sendmail' or `MMDF'. Source code is available for some alternative mail delivery agents, such as `IDA sendmail' and `smail'. Taylor UUCP also does not include a news package. The two major Unix news packages are `C-news' and `INN'. Both are available in source code form. Configuring and using mail delivery agents is a notoriously complex topic, and I will not be discussing it here. Configuring news systems is usually simpler, but I will not be discussing that either. I will merely describe the interactions between the mail and news systems and UUCP. A mail or news system interacts with UUCP in two ways: sending and receiving. * Menu: * Sending mail or news:: Sending mail or news via UUCP * Receiving mail or news:: Receiving mail or news via UUCP  File: uucp.info, Node: Sending mail or news, Next: Receiving mail or news, Prev: Using UUCP for mail and news, Up: Using UUCP for mail and news Sending mail or news via UUCP ............................. When mail is to be sent from your machine to another machine via UUCP, the mail delivery agent will invoke `uux'. It will generally run a command such as `uux - SYSTEM!rmail', where SYSTEM is the remote system to which the mail is being sent. It may pass other options to `uux', such as `-r' or `-g'. News also invokes `uux' in order to transfer articles to another system. The only difference is that news will use `uux' to invoke `rnews' on the remote system, rather than `rmail'. You should arrange for your mail and news systems to invoke the Taylor UUCP version of `uux' when sending mail via UUCP. If you simply replace any existing version of `uux' with the Taylor UUCP version, this will probably happen automatically. However, if both versions exist on your system, you will probably have to modify the mail and news configuration files in some way. Actually, if both the system UUCP and Taylor UUCP are using the same spool directory format, the system `uux' will probably work fine with the Taylor `uucico' (the reverse is not the case: the Taylor `uux' requires the Taylor `uucico'). However, data transfer will be somewhat more efficient if the Taylor `uux' is used.  File: uucp.info, Node: Receiving mail or news, Prev: Sending mail or news, Up: Using UUCP for mail and news Receiving mail or news via UUCP ............................... As noted in *Note Sending mail or news::, mail is sent by requesting a remote execution of `rmail'. To receive mail, then, all that is necessary is for UUCP to invoke `rmail' itself. Any mail delivery agent will provide an appropriate version of `rmail'; you must simply make sure that it is in the command path used by UUCP (it almost certainly already is). The default command path is set in `policy.h', and it may be overridden for a particular system by the `command-path' command (*note Miscellaneous (sys)::.). Similarly, for news UUCP must be able to invoke `rnews'. Any news system will provide a version of `rnews', and you must ensure that is in a directory on the path that UUCP will search.  File: uucp.info, Node: Trimming UUCP Log Files, Prev: Using UUCP for mail and news, Up: Installation Trimming UUCP Log Files ----------------------- You should also periodically trim the log files, as they will otherwise continue to grow without limit. The names of the log files are set in `policy.h', and may be overridden in the configuration file (*note config File::.). By default they are are `/usr/spool/uucp/Log' and `/usr/spool/uucp/Stats'. You may find the `savelog' program in the `contrib' directory to be of use. There is a manual page for it in `contrib' as well.  File: uucp.info, Node: TCP, Prev: Installation, Up: Overall Installation TCP together with Taylor UUCP ============================= If your system has a Berkeley style socket library, or a System V style TLI interface library, you can compile the code to permit making connections over TCP. Specifying that a system should be reached via TCP is easy, but nonobvious. If you are using the new style configuration files, see *Note Configuration Files::. Basically, you can just add the line `port type tcp' to the entry in the system configuration file. By default UUCP will get the port number by looking up `uucp' in `/etc/services'; if `uucp' is not found, port 540 will be used. You can set the port number to use with the command `port service XXX', where XXX can be either a number or a name to look up in `/etc/services'. You can specify the address of the remote host with `address A.B.C'; if you don't give an address, the remote system name will be used. You should give an explicit chat script for the system when you use TCP; the default chat script begins with a carriage return, which will not work with some UUCP TCP servers. If you are using V2 configuration files, add a line like this to `L.sys': SYS Any TCP uucp HOST.DOMAIN chat-script This will make an entry for system SYS, to be called at any time, over TCP, using port number `uucp' (as found in `/etc/services'; this may be specified as a number), using remote host `HOST.DOMAIN', with some chat script. If you are using HDB configuration files, add a line like this to Systems: SYS Any TCP - HOST.DOMAIN chat-script and a line like this to Devices: TCP uucp - - You only need one line in Devices regardless of how many systems you contact over TCP. This will make an entry for system SYS, to be called at any time, over TCP, using port number `uucp' (as found in `/etc/services'; this may be specified as a number), using remote host `HOST.DOMAIN', with some chat script. The `uucico' daemon can also be run as a TCP server. To use the default port number, which is a reserved port, `uucico' must be invoked by root (or it must be set user ID to root, but I don't recommend doing that). Basically, you must define a port, either using the port file (*note port File::.) if you are using the new configuration method or with an entry in Devices if you are using HDB; there is no way to define a port using V2. If you are using HDB the port must be named `TCP'; a line as shown above will suffice. You can then start `uucico' as `uucico -p TCP' (after the `-p', name the port; in HDB it must be `TCP'). This will wait for incoming connections, and fork off a child for each one. Each connection will be prompted with `login:' and `Password:'; the results will be checked against the UUCP (not the system) password file (*note Configuration File Names::.). Of course, you can get a similar effect by using the BSD `uucpd' program. You can also have `inetd' start up `uucico' with the `-l' switch, which will cause it to prompt with `login:' and `Password:' and check the results against the UUCP (not the system) password file (you may want to also use the `-D' switch to avoid a fork, which in this case is unnecessary). This may be used in place of `uucpd'.  File: uucp.info, Node: Configuration Files, Next: Protocols, Prev: Overall Installation, Up: Top Taylor UUCP Configuration Files ******************************* This chapter describes the configuration files accepted by the Taylor UUCP package if compiled with `HAVE_TAYLOR_CONFIG' defined in `policy.h'. The configuration files are normally found in the directory NEWCONFIGDIR, which is defined by the `Makefile' variable `newconfigdir'; by default NEWCONFIGDIR is `/usr/local/conf/uucp'. However, the main configuration file, `config', is the only one which must be in that directory, since it may specify a different location for any or all of the other files. You may run any of the UUCP programs with a different main configuration file by using the `-I' option; this can be useful when testing a new configuration. When you use the `-I' option the programs will revoke any setuid privileges. * Menu: * Configuration File Format:: Configuration file format * Configuration File Overview:: Configuration File Overview * Configuration Examples:: Examples of configuration files * Time Strings:: How to write time strings * Chat Scripts:: How to write chat scripts * config File:: The main configuration file * sys File:: The system configuration file * port File:: The port configuration files * dial File:: The dialer configuration files * Security:: Security issues  File: uucp.info, Node: Configuration File Format, Next: Configuration File Overview, Prev: Configuration Files, Up: Configuration Files Configuration File Format ========================= All the configuration files follow a simple line-oriented `KEYWORD VALUE' format. Empty lines are ignored, as are leading spaces; unlike HDB, lines with leading spaces are read. The first word on each line is a keyword. The rest of the line is interpreted according to the keyword. Most keywords are followed by numbers, boolean values or simple strings with no embedded spaces. The `#' character is used for comments. Everything from a `#' to the end of the line is ignored unless the `#' is preceded by a `\' (backslash); if the `#' is preceeded by a `\', the `\' is removed but the `#' remains in the line. This can be useful for a phone number containing a `#'. To enter the sequence `\#', use `\\#'. The backslash character may be used to continue lines. If the last character in a line is a backslash, the backslash is removed and the line is continued by the next line. The second line is attached to the first with no intervening characters; if you want any whitespace between the end of the first line and the start of the second line, you must insert it yourself. However, the backslash is not a general quoting character. For example, you cannot use it to get an embedded space in a string argument. Everything after the keyword must be on the same line. A BOOLEAN may be specified as `y', `Y', `t', or `T' for true and `n', `N', `f', or `F' for false; any trailing characters are ignored, so `true', `false', etc., are also acceptable.  File: uucp.info, Node: Configuration File Overview, Next: Configuration Examples, Prev: Configuration File Format, Up: Configuration Files Configuration File Overview =========================== UUCP uses several different types of configuration files, each describing a different kind of information. The commands permitted in each file are described in detail below. This section is a brief description of some of the different types of files. The `config' file is the main configuration file. It describes general information not associated with a particular remote system, such as the location of various log files. There are reasonable defaults for everything that may be specified in the `config' file, so you may not actually need one on your system. There may be only one `config' file, but there may be one or more of each other type of file. The default is one file for each type, but more may be listed in the `config' file. The `sys' files are used to describe remote systems. Each remote system to which you connect must be listed in a `sys' file. A `sys' file will include information for a system, such as the speed (baud rate) to use, or when to place calls. For each system you wish to call, you must describe one or more ports; these ports may be defined directly in the `sys' file, or they may be defined in a `port' file. The `port' files are used to describe ports. A port is a particular hardware connection on your computer. You would normally define as many ports as there are modems attached to your computer. A TCP connection is also described using a port. The `dial' files are used to describe dialers. Dialer is essentially another word for modem. The `dial' file describes the commands UUCP should use to dial out on a particular type of modem. You would normally define as many dialers as there are types of modems attached to your computer. For example, if you have three Telebit modems used for UUCP, you would probably define three ports and one dialer. There are other types of configuration files, but these are the important ones. The other types are described below.  File: uucp.info, Node: Configuration Examples, Next: Time Strings, Prev: Configuration File Overview, Up: Configuration Files Examples of Configuration Files =============================== This section provides few typical examples of configuration files. There are also sample configuration files in the `sample' subdirectory of the distribution. * Menu: * config File Examples:: Examples of the main configuration file * Leaf Example:: Call a single remote site * Gateway Example:: The gateway for several local systems