Taylor UUCP: Installing Taylor UUCP (original) (raw)
| [ < ] | [ > ] | | [ << ] | [ Up ] | [ >> ] | | | | | [Top] | [Contents] | [Index] | [ ? ] | | ------------------------------ | ------------------------------- | | ------------------------------ | ------------------------------- | -------------------------------- | | | | | ------------------------------ | ---------------------------------------------- | --------- | -------------------------------------- |
These are the installation instructions for the Taylor UUCP package.
| 3.1 Compiling Taylor UUCP | | | --------------------------------------------------- | | | 3.2 Testing the Compilation | | | 3.3 Installing the Binaries | | | 3.4 Configuring Taylor UUCP | | | 3.5 Testing the Installation | |
| [ < ] | [ > ] | | [ << ] | [ Up ] | [ >> ] | | | | | [Top] | [Contents] | [Index] | [ ? ] | | ------------------------------ | ------------------------------- | | ------------------------------- | ------------------------------- | -------------------------------- | | | | | ------------------------------ | ---------------------------------------------- | --------- | -------------------------------------- |
3.1 Compiling Taylor UUCP
If you have a source code distribution, you must first compile it for your system. Free versions of Unix, such as Linux, NetBSD, or FreeBSD, often come with pre-compiled binary distributions of UUCP. If you are using a binary distribution, you may skip to the configuration section (see section 3.4 Configuring Taylor UUCP).
Follow these steps to compile the source code.
- 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 byroot
). - Run the shell script
configure
. This script was generated using theautoconf
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 toconfigure
in the environment. Becauseconfigure
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 ifconfigure
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 ifconfigure
finds the BSDinstall
program, it will set this to `install -c'; otherwise, it will use`cp'.
Suppose, for example, you want to set the environment variable `CC'to `rcc'. If you are usingsh
,bash
, orksh
, invokeconfigure
as `CC=rcc configure'. If you are usingcsh
, 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'.
You can also pass other arguments toconfigure
on the command line. Use `configure --help' for a complete list. Of particular interest:
`--prefix=dirname'
The directory under which all files are installed. Default`/usr/local'.
`--with-newconfigdir=dirname'
The directory in which to find new style configuration files. Default`prefix/conf/uucp'.
`--with-oldconfigdir=dirname'
The directory in which to find old style configuration files. Default`/usr/lib/uucp'.
Ifconfigure
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. - Igor V. Semenyuk provided this (lightly edited) note about ISC Unix 3.0. The
configure
script will default to passing `-posix' togcc
. However, using `-posix' changes the environment to POSIX, and on ISC 3.0, at least, the default forPOSIX_NO_TRUNC
is 1. This can lead to a problem whenuuxqt
executesrmail
.IDA sendmail
has dbm configuration files named`mailertable.{dir,pag}'. Notice these names are 15 characters long. Whenuuxqt
compiled with the `-posix' executesrmail
, which in turn executessendmail
, the later is run under the POSIX environment too. This leads tosendmail
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 the `-posix' switch; instead, I rungcc
with `-D_POSIX_SOURCE', and add `-lcposix' to`LIBS'. - 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. (Reported by David Vrona).
- 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'. (Reported by Chris Lewis).
- You should verify that
configure
worked correctly by checking`config.h' and the instances of `Makefile'. - Edit `policy.h' for your local system. The comments explain the various choices. The default values are intended to be reasonable, so you may not have to make any changes.
You must decide what type of configuration files to use; for more information on the choices, see 3.4 Configuring Taylor UUCP.
You must also decide what sort of spool directory you want to use. If this is a new installation, I recommend `SPOOLDIR_TAYLOR'; otherwise, select the spool directory corresponding to your existing UUCP package. - 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 determined by the configure script.
If you have any other problems there is probably a bug in theconfigure
script. - Please report any problems you have. That is the only way they will get fixed for other people. Supply a patch if you can (see section 7.3 Patches), or just ask for help.
| [ < ] | [ > ] | | [ << ] | [ Up ] | [ >> ] | | | | | [Top] | [Contents] | [Index] | [ ? ] | | ------------------------------ | ------------------------------- | | ------------------------------- | ------------------------------- | -------------------------------- | | | | | ------------------------------ | ---------------------------------------------- | --------- | -------------------------------------- |
3.2 Testing the Compilation
If your system supports pseudo-terminals, and you compiled the code to support the new style of configuration files (HAVE_TAYLOR_CONFIG
was set to 1 in `policy.h'), you should be able to use thetstuu
program to test the uucico
daemon. If your system supports STREAMS based pseudo-terminals, you must compile tstuu.c with `-DHAVE_STREAMS_PTYS'. (The STREAMS based code was contributed by Marc Boucher).
To run tstuu
, just type `tstuu' with no arguments. You must run it in the compilation directory, since it runs `./uucp',`./uux' and `./uucico'. The tstuu
program 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. Thetstuu
program 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 tstuu
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'. There should be no errors in the log files.
You can test uuxqt
with `./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 (see section 5.6.4 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
andUUCICO_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 toroot
(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 you can not run tstuu
, or if it fails inexplicably, don't worry about it too much. On some systems tstuu
will fail because of problems using pseudo terminals, which will not matter in normal use. The real test of the package is talking to another system.
| [ < ] | [ > ] | | [ << ] | [ Up ] | [ >> ] | | | | | [Top] | [Contents] | [Index] | [ ? ] | | ------------------------------ | ------------------------------- | | ------------------------------- | ------------------------------- | -------------------------------- | | | | | ------------------------------ | ---------------------------------------------- | --------- | -------------------------------------- |
3.3 Installing the Binaries
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. For more information, see your system documentation for the strip
program.
Of course, simply installing the executable files is not enough. You must also arrange for them to be used correctly.
| [ < ] | [ > ] | | [ << ] | [ Up ] | [ >> ] | | | | | [Top] | [Contents] | [Index] | [ ? ] | | ------------------------------ | ------------------------------- | | ------------------------------- | ------------------------------- | -------------------------------- | | | | | ------------------------------ | ---------------------------------------------- | --------- | -------------------------------------- |
3.4 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; see5. Taylor UUCP 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 (see section 5.9 The Dialer Configuration 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 5.9 The Dialer Configuration 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
(see section 2.13 Invoking 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 5. Taylor UUCP Configuration Files for details on how to do this.
After writing the configuration files, use the uuchk
program to verify that they are what you expect; see 2.12 Invoking uuchk.
| [ < ] | [ > ] | | [ << ] | [ Up ] | [ >> ] | | | | | [Top] | [Contents] | [Index] | [ ? ] | | ------------------------------ | ------------------------------- | | ------------------------------- | ------------------------------- | -------------------------------- | | | | | ------------------------------ | ---------------------------------------------- | --------- | -------------------------------------- |
3.5 Testing the Installation
After you have written the configuration files, and verified them with the uuchk
program (see section 2.12 Invoking uuchk), you must check that UUCP can correctly contact another system.
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. The exact location of the log file depends upon the settings in `policy.h' when you compiled the program, and on the use of the logfile
command in the `config' file. Typical locations are `/usr/spool/uucp/Log' or a subdirectory under`/usr/spool/uucp/.Log'.
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 with thedebug
command (see section 5.6.4 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 default 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') (see section 4.4.2 Status Directory) will prevent too many attempts from occurring in rapid succession.
On older System V based systems which do not have the setreuid
system call, problems may arise if ordinary users can start an execution of uuxqt
, perhaps indirectly via uucp
oruux
. UUCP jobs may wind up executing with a real user ID of the user who invoked uuxqt
, which can cause problems if the UUCP job checks the real user ID for security purposes. On such systems, it is safest to put `run-uuxqt never'(see section 5.6.1 Miscellaneous config File Commands) in the `config' file, so thatuucico
never starts uuxqt
, and invokeuuxqt
directly from a `crontab' file.
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, the operating system you are running it on, 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.
| [ << ] | [ >> ] | | | | | | [Top] | [Contents] | [Index] | [ ? ] | | ------------------------------- | -------------------------------- | | | | | | ------------------------------ | ---------------------------------------------- | --------- | -------------------------------------- |
This document was generated by Ian Lance Taylor on _June, 5 2003_using texi2html