Black Box 4

home *** CD-ROM | disk | FTP | other *** search

/ Black Box 4 / BlackBox.cdr / bbsfiles / waf165b7.arj / NETWORK.DOC < prev next >

Wrap

Text File | 1992-03-20 | 51.5 KB | 1,402 lines

Waffle/DOS Networking Manual - Version 1.65 (C) Copyright 1992 Darkside International, All Rights Reserved. TABLE OF CONTENTS Introduction I Quick Overview II Setting up your system III Functions of the Networking Programs V Directories Used The UUCICO Program VI UUCICO command line options VII Format of the systems file VIII Running UUCICO in master role - Dialing out IX Running UUCICO in slave mode - Answering X UUCP error messages XI Tunable parameters in the static file Support Programs XII Using UUCP to transfer files XIII The UUX program - sending execution requests XIX Inspecting the spool queue with UUQ XX Beyond mail and news Miscellaneous XXI Waffle's Filename Munging XXII Limitations and paranoia QUICK OVERVIEW o Scope This document is not complete. It describes the operation of Waffle, and its connection to the outside world; What it does NOT describe is how to obtain a UUCP connection, or how to configure a Unix system to accept connections. Solving these problems is left as a exercise to the reader and cohorts. (You might start by reading the INTRO.DOC file, though). o Features of this package Waffle provides Unix-to-PC or PC-to-PC communications using the UUCP "g" protocol, transmitting mail or news or binary files. Programs are included for sending or receiving UUCP mail, and for reading or posting Usenet News. Depending on the configuration, they can be run for a single user or as a dialup BBS. Your system can act as an intermediate host, passing mail and news on to other sites. A scheduler is provided to automate the process of polling other sites. Waffle has the ability to retrieve or place files on other Unix systems, including public anonymous UUCP archives. Networking is fully integrated with the package, which was designed for this express purpose. o About UUCP Flow UUCP is a "store and forward" system. This means that messages will not be transmitted to their destination immediately unless you are sending to one of your neighbors. The message may pass through several systems; this is slower but it also distributes costs over the net. If you plan on sending large amounts of traffic, as a courtesy you should check with the intermediate sites to see if this is going to cause any problems. Another limitation is that you may need to know the exact path your message must travel before you can send it. Ways of working around this problem include using the domain-named system, or by routing through a site that can operate as a smarthost. o How the programs fit together You will probably receive mail or news from a Unix or Waffle host. You must have someone on the other end configure their system to recognize yours; it is not done automatically. Part of this configuration is letting UUCP know about your host, and part involves determining which newsgroups you are to receive. When properly set up, mail or news will be transmitted by having your UUCICO talk to their UUCICO, or vice versa. UUCICO will place incoming files into a spool directory matching the name of the neighboring system. After this is finished, UUXQT is run; it will check these spool directories for recently arrived traffic, and pass any arrived data to the appropriate programs. Under normal circumstances UUXQT will call RMAIL or RNEWS for processing. SETTING UP YOUR SYSTEM o Static file configuration Waffle's networking programs all read the common Waffle static file, which defined by the WAFFLE environment variable. It is normally C:\WAFFLE\SYSTEM\STATIC. Parameters not recognized by a program are ignored. With a few exceptions documented in this file, all parameters used by these programs are described in the STATIC.DOC file. o Choose a UUCPNAME To operate as a UUCP node, you must choose a UUCPNAME for your site. If you are connecting to the outside world, make sure that the name is not already in use; in particular it should be unique to the first seven characters. The name is defined in the static file as "uucpname" and may contain lowercase characters, digits, dots, or dashes; it must also begin with an alphanumeric character. Only fully qualified and registered domain names may contain dots. We strongly suggest that the name be seven or fewer characters, because some versions of Unix UUCP will either truncate or reject your sitename. o Communications Driver If you have a high speed modem, you should probably use a FOSSIL driver for communications. There is further information on this topic in the file DOS.DOC included with this package, under the header "SETTING UP THE MODEM". FUNCTIONS OF THE NETWORKING PROGRAMS There are several programs in the /waffle/bin directory that are used when networking under the DOS version of Waffle. Each of these commands is further described in further sections; this is just a quick overview. o UUCICO - Unix to Unix Copy In Copy Out The program that performs UUCP transfers. It will dial a neighbor and transfer any files that are queued for that system. Alternatively, it can be run when a remote host calls your system. Proper pronunciation is you.you.kai.ko, you.you.psycho, or you.you.see.i.see.oh, depending on upbringing. (oh boy) o UUXQT - Unix to Unix eXeQuTe Handles commands requested by the remote host. Most of the time these are "rnews", to receive Usenet news, and "rmail", receive UUCP mail. UUXQT may be run at any time, but it is usually run after a connection to process newly arrived files. o UUCP - Unix to Unix CoPy A program to allow the SYSTEM 0PERATOR to use UUCP as a mechanism for transferring files. This will not invoke the transaction; it will merely queue it for the next uucico session. It is not required for Waffle operation, but it is sufficiently groovy to warrant inclusion herein. o UUX - Queue an outgoing execution request UUX is used to queue outgoing mail or news messages for transmission by UUCICO, and is usually called by RNEWS or RMAIL. It can also be used to request remote execution of various Unix commands on other systems, for example printing a file on a remote printer. o UUQ - Display contents of spool queue Pending transactions may be displayed with the UUQ command. It will also report on any problems it finds regarding missing files, etc. o BATCH - Prepare and send outgoing Batched newsfeeds This program may be run if you are batching a newsfeed for another site. It will determine what files it needs to send from the /spool/batch directory, pack them together, and queue for delivery. How often this should be run depends on how much news your system handles, and how often you connect to other sites. o WAFFLE - Integrated mailer and newsreader Run either as a BBS, or an integrated mailer and newsreader. When using the system as a single user UUCP node, Waffle is generally invoked by the LOGIN batch file. Sites wishing to omit the Login/Password sequence at the beginning should investigate the "waffle online username" startup syntax in the MANUAL.DOC file. DIRECTORIES USED The SPOOL directories Incoming or outgoing UUCP work and data files are placed in the spool directory. If you have a lot of traffic, make sure there is enough free space "give" on the disk to handle it. Normally, three files get placed in the directories for outgoing jobs, or one file if using the UUCP.EXE program. Two files arrive for most incoming jobs. o /spool - spool directory Directory through which incoming and outgoing messages pass. Outgoing messages stay queued until the remote system is contacted. Incoming messages will stay the short time between arrival and processing. This directory will have a number of subdirectories, which should be manually created. They are: o /spool/batch - batch directory Lists of files for the batcher (batch.exe) are stored here. This is only needed if you batch outgoing news. o /spool/lost - Lost files If a file collision is detected, the old file will be moved into /spool/lost. This usually happens because of an interrupted transfer. This directory should be checked from time to time for things that have become lost to mysts of tyme. It is safe to delete files that show up here. o /spool/outbox - The "OUTBOX" Messages queued for delivery to other systems are kept in this directory until they are spooled. The filenames are of format /spool/outbox/name.number, e.g. "darkside.1". These aren't needed and may could deleted on a regular basis. Right now they are just used to occasionally monitor outgoing traffic and to check to see if things are working fine. o /spool/public - UUCP home directory The uucppublic directory. This is where ~/ refers to in UUCP requests. This is generally the directory used for transferring binary files between your DOS system and a remote Unix system, using the "uucp" command. Files will arrive here from a neighboring Unix system if the C shell command "uucp file your_site\!~/file" is executed on the remote system. You can use this command to UUCP binary files over. Files may also be pulled by the remote unix system if using a command such as "uucp your_site\!~/file /usr/spool/uucppublic", which will transfer a file on the DOS system to the public directory on the Unix system. The name of this directory can be changed by altering the "permits" file in the uucp directory. o /spool/unbatch - unbatch directory The unbatch directory is needed if you are accepting incoming batches from your feeds. Temporary files will be kept here, between decompression and unbatching. UUCICO COMMAND LINE OPTIONS -b <speed> Speed of connection. If not present, UUCICO will either use the speed present in the Systems file, or attempt to determine the speed of the incoming connection. -d <device> Device of incoming connection. Examples are -d1 for COM1, or -d2 for COM2, etc. -g <grade> Set grade for file transfers. Grades are single characters that give 'priority' of a job. See the section on GRADES for more information. Currently this is implemented for incoming only. -i Ignore carrier detect for this connection. This option is required on serial lines that do not support carrier detect, DCD. -k <size> Specify a packet size for the "g" protocol. Refer to the section regarding this located near the end of this manual before attempting. -n <name> Set your uucpname temporarily. Can be used if a neighbor expects your uucpname to be truncated to seven characters. -o Override time limitations in systems file. Previously, uucico -s any or -s all would respect the times and uucico -s site would override. -p <permit> Use permit. -r <num> Role, where -r0 signifies dialin and -r1 or above signifies dialout. When the -r parameter is greater than 1, this causes uucico to retry the call that number of times or until connection is succesful. The default is -r1. -s <system> Name of the system to poll. This may also be "all" to poll all systems, or "any" to poll systems that have work queued. Multiple sites may be specified in the -s parameter. For example, uucico -sozone,lugnut. The -s is required with outgoing calls, and must be left off with -r0. -t <sec> The number of seconds to wait for a response in an expect/send sequence. For most purposes the default of 30 is sufficient, but over long distance connections or instances where the modem on the other side takes many rings to answer, this can be adjusted upward. -u <account> Account name. -v <debug> Visual debug level, similar to -x except controls output displayed on screen. Replaces the -q parameter from 1.64 uucico. -x <debug> Setting debug level. Default is 0. Set to 2 if having problems with expect/send dialing sequences, or 4 to solve most other problems. Higher settings tend to be nitty gritty. Functionality available with the -a and -w parameters from previous versions of UUCICO can be found in the section on PERMITS. SYSTEMS FILE FORMAT, /waffle/uucp/systems Sample contents: ozone Any g Use2400 toWaffle 245xxxx uuelf dungeon6 lugnut Any g Use2400 toUnix 1916xxxxxxx uucp uucp Fields, in order, are: 1. Remote system's UUCP name. In this case we talk to two systems, "ozone" and "lugnut". Each of your neighbors should have an entry here, even if they call you. 2. Times to call. Valid entries are described later in this manual; usually it is "Never", "Any", or "Evening". 3. Protocol to use. Must be g. 4. Name of dialer. The corresponding entry in the "dialers" file will be used (which includes baud rate.) 5. Name of connection script. The corresponding script in the "scripts" file is performed after the dialers script has finished. 6. Phone number to call (for \T). When a \T is encountered in the "dialers" script, this number is inserted. 7. Login name to use (for \L). 8. Password to use (for \P). Presence of a system in the systems file may not be enough to allow a connection. *YOUR* system must also be in their "Systems" file (for HDB varieties of UUCP) or in their "L.sys" file (for normal flavors of Unix UUCP). In particular, this is probably the problem if you receive an "RLOGIN" message. If there are multiple entries for a single system in the systems file, UUCICO will try each one in turn until one is successful. After that, the remainder will be skipped. Note that these multiple entries MUST be consecutive in order for this feature to work. This allows the use of "backup numbers" in case one is busy or inoperable. NEW DIALERS FILE FORMAT, /waffle/uucp/dialers Sample contents: Use2400 Default 2400 "" AT&D2 OK ATDT\T CONNECT \m\c Use9600 Default 9600 "" AT&D2 OK ATDT\T CONNECT \m\c Fields, in order, are: 1. Name of dialer, in this case, "Use2400" is the first dialer shown. It doesn't matter too much what you call dialers, but all dialers listed in your "SYSTEMS" file should be contained in this file. 2. Device to use. "Default" or "Any" will use the "device" line in the static file. If you want to specify a device, "1" through "4" are valid entries, as are "COM1" through "COM4". 3. Speed of connection. 4. Fields 4 and above are the connection script (expect/send sequences) for talking to the modem. A \T goes at the location to substitute the phone number. NEW SCRIPTS FILE FORMAT, /waffle/uucp/scripts Sample contents: toUnix in:--in: \L word: \P toWaffle NEW:--NEW: \d\L word: \P Fields, in order, are: 1. Name of script. 2. Fields 2 and above contain the login script to login to the remote system (expect/send sequences). These are process after the DIALERS file is. The \L goes at the location to insert the login name, and \P where to send the password. VALID TIME ENTRIES Entries in the "Times to call" field (the second field) in the systems file can be of the following possibilities: Any Allow calls anytime. This is what should be used for most configurations. Evening Call only during the evening, which is equivalent to weekdays 5pm to 8am, plus Saturday and Sunday. Never Do not allow calls at all. <day> Call only on specified days, where <day> may be any one of Su, Mo, Tu, We, Th, Fr, Sa, or any combination thereof. Wk A synonym for Monday through Friday, which is used in the same manner as <day>. "Any", "Wk", or "<day>" may be may be modified by specifying a legal time range, given in minutes from midnight. For example, "0800-1700" is 8am to 5pm, and "1800-0700" is 6pm to 7am. These time ranges are not enforced when a system name is explicitly specified in the UUCICO startup command line. Some examples of valid time fields: MoWeFr calls ok on Mon, Wed, or Fri Wk1700-0800,SaSu equivalent to "Evening" TuTh1700-0800,Wk2300-0800 allow calls between 11pm and 8am weekdays, except on Tuesday or Thursday, which are 5pm to 8am Any2200-0000 calls ok between 8pm and midnight CONFIGURATION OF EXPECT/SEND SEQUENCES Both the "DIALERS" and "SCRIPTS" connection scripts have the same format. They consist of pairs of expect/send sequences. Dashes in the scripts indicate alternate send sequences, as illustrated with the second example. An explanation of the sample DIALERS script: "" ATV1&D2 OK ATDT\T CONNECT \m\c The fields of this script, in order: Expect "" Expect nothing. This is just a placeholder to force the next item to be sent. Send AT&V1D2 Can also send a Hayes initialization, or Telebit register settings, etc. Expect OK modem sends us OK. Send ATDT\T Dial number. The \T is replaced by the phone number found in the "SYSTEMS" file. Expect CONNECT If "BUSY" or "NO CARRIER" results, it will exit with "Never got CONNECT" message. Send \m\c The \m turns on carrier checking. After a CONNECT is received, the modem should have carrier on. The \c prevents a trailing CR from being sent. An explanation of the sample SCRIPTS script: in:--in: \L word: \P The fields of this script, in order: in:--in: Expect a login: prompt. If we don't receive one in a reasonable time, send whatever lies between the -'s (in this case, nothing, which is really "nothing followed by a carriage return". All strings are followed by carriage returns unless terminated with a \c - see below). If the alternate had to be sent, wait for "in:" again, ad infinatum. Note, for Waffle as it is supplied you would have to wait for the "Login or NEW:" string instead of login:. You can abbreviate the expect to "NEW:". Send \L Sends our login name ("username"), as found in the "SYSTEMS" file. If you know this should work but does not, try appending a carriage return \r to the end (I understand this may be the case with some System V's). Expect word: Look for the string "Password:" or "password:". Send \P Send our password, as found in the "SYSTEMS" file. Notes o Blank lines and lines beginning with # are comments. o An entry may be continued on the next line by placing whitespace at the beginning of each extra line. The line length allowed is quite long. o Special characters in Expect/Send sequences. Some of these are only relevant to "send" sequences, such as \c or \d. \b Send or expect a backspace ^H. \c Omit normal CR after the end of a send string. \d Delay. Useful for long distance systems, where dialing may timeout because of the time it takes to startup a connection. Also use when remote system is losing some of your characters. Each \d sleeps two seconds. \n Send or expect a linefeed ^J. \r Send or expect a carriage return ^M. \s Send or expect a space character. \t Send or expect a tab ^I. \\ Send or expect the backslash character. \T Send telephone number (found in systems file). \L Send login name (found in systems file). \P Send password (found in systems file). \m Turn on carrier checking for the duration of the scripts (do this usually after a CONNECT.) \M Turn off carrier checking. Carrier checking is still turned on after the connection is complete. \K Send a break. Same as "BREAK". Preferred, actually. o Control characters not present above may be specified as octal constants, of the form \000; up to three digits may be given. For example, ESC is \033, and ^E is \005 or \5. o If a send string consists of "BREAK", a break is sent over the modem. This is often necessary in systems that use breaks to cycle modem speed, such as some Xenix implementations. In this case, a expect/send sequence might consist of in:-BREAK-in:-BREAK-in: or something similar; on not finding the "login:", it cycles to the next modem speed. Similarly, the "EOT" keyword will send an EOT-newline twice. o To change parity within the expect/send scripts, send the P_EVEN, P_ODD, and P_NONE (or P_ZERO) keywords to the modem. Do not use any of the above unless it is necessary. UUCP requires a 8 bit, no parity, 1 start bit connection to function; the line will thus be set to 8N1 before starting the G protocol. These options are provided to enable access through terminal servers which need specific parity settings. In most cases they will not be necessary even if you are dialing a system with even parity. RUNNING UUCICO IN MASTER ROLE - DIALING OUT Running in "master role" refers to using UUCICO to initiate a transaction with a remote Unix system. Uucico dials a phone number, negotiates through any login sequence (such as username, password, etc) and connects to the remote uucico. The two systems then exchange names, and agree on various protocol questions. Example: uucico -s uunet Poll uunet. UUCICO will send them any files that are queued. After this is completed, uunet will send any files they have queued for us. uucico -s abc,xyz Call systems abc and xyz. uucico -s all Calling all systems.. There are several schemes to connect to your neighbors by dialing out. o Call all systems, usually on a regular basis Place in your POLL.BAT file lines something like uucico -s system1 uucico -s system2 If one of the systems is BUSY, the connection will have to wait until the next polling time. o Call neighbors only when they have work queued uucico -s any The main difficulty with this method: If the neighbor has traffic queued for you but does not call you, it may be quite some time before it is delivered. o Create null requests in the spool queue Have something place blank POLL.CMD files in the directories for each system you want to poll. This will cause traffic to be queued even if there would normally be no traffic in the queue. rem > C:\SPOOL\ozone\POLL.CMD rem > C:\SPOOL\oxide\POLL.CMD uucico -s any After a successful connection, any POLL.CMD command file will be removed. This last statement can thus be repeated until all the POLL.CMD files have been, and therefore all systems have been connected to. You can use "-s any" in conjunction with the -rX option, to retry X number of times. RUNNING UUCICO IN SLAVE ROLE - ANSWERING Set up an account in Waffle with the following parameters: User: uucp Password: (some password) Access: -2 Shell: #exit 40 At minimum, UUSHELL.BAT should contain: uucico -r0 uuxqt You should assign an individual account for each site that will be polling your system; using a single account for all incoming UUCP connections is a security problem. In most cases the account name should match your neighbor's machine name, or have a 'uu' placed before it (eg, machine "elf" uses account "uuelf"). For a UUCP connection dialing in, Waffle will attempt to determine the incoming speed by either checking the COMM port or the FOSSIL driver. If your FOSSIL driver does not support this (for instance, the X00 driver), you must use the -b2400 option in the command line. The remote Unix system should put an entry for your system in their L.sys file, containing an expect/send sequence something similar to NEW:--NEW:--NEW: uucp word: xanadu8 ^^ account ^^ password as their "chat script", with the account and password you have assigned. Assign unique accounts & passwords to each of your UUCP neighbors if you can. Set the access to these accounts to -2 to prevent their appearance in the caller log and to disable time limit checking. Among the interesting things we've heard that people have done with the UUSHELL.BAT file are placing a command between the uucico and uuxqt to send the modem an "AT H1" sequence to take the phone offhook; this is useful for sites with large newsfeeds or mail volume. UUCP ERROR MESSAGES Problems on the remote host or with your configuration will sometimes result in a useful error message. Usually, however, it will merely result in things "not working", meaning an error message that isn't comprehensible, or one of the systems dropping the connection. Some of the more common, useful error messages are: Can't Tango - Reason:, where the reason is one of RLCK The remote system has a lock in place for your system. Either it is trying to call you, or it hasn't reset itself from a dropped connection. Try again in 5 minutes or so. RLOGIN The remote system is refusing to allow your system to connect to it. Often this is a result of your system not having an entry in their "Permissions" or similar access control file. Please note that if you receive a RLOGIN message, IT IS ALMOST ALWAYS A CONFIGURATION PROBLEM ON THE REMOTE SYSTEM. You must contact the administrator of that system to fix the problem. RCB Their system will call yours; this feature of UUCP is not used very often. RBADSEQ Sequence numbers do not match. Waffle doesn't support sequence numbers, and most UUCP implementations do not either. The remote system must change its configuration for you. RYou are unknown to me Your system is not in their "systems" file. Occurs because of a number of reasons: o You are attempting an unauthorized connection, and should be spanked. Or you just aren't in their "systems" file. o Your system name is not being understood by their system; possibly it is being truncated or misspelled. o Line noise has occurred during the handshaking sequence. Failures on file reception (we are on the receiving end): RN2 The system you have requested a file from cannot find the file, or permission is denied. Failures on file transmission (we are on the sending end): SN2 Target file can't be created. Usually, this is due to a permissions problem. SN4 Problem creating the workfile. CN5 The system you have sent a file to is having problems moving a file into its final location. TUNABLE PARAMETERS IN THE STATIC FILE In addition to those described above, there are several more tunable parameters available as "advanced options". They are not required in the static file, and most people won't need them. uu.alive Time before UUCICO generates a fatal timeout, and terminates connection. By default this is 90 seconds. uu.between Similar to uu.retrytime, but used between multiple entries for the same host in the systems file. By default this is 10 seconds. uu.debug Default debug level, equivalent to the -x command line option. Included here mainly for debugging purposes. uu.delay Timeout delay during g protocol transfers. For heavily loaded hosts, possibly in combination with low speed links, setting this higher is sometimes necessary. You should not change this unless you are experiencing repeated **timeout errors. The default is 16 seconds, which is long. uu.driver Which COMM driver uucico will use. Valid choices are "native" and "fossil". This line must come AFTER any "driver" statement in the static file. UUCICO will also recognize a "driver" statement if present; the uu.driver is intended to override this if necessary. Refer to DOS.DOC for more information. uu.drops Strings that when received from the modem, cause premature termination of chat scripts. Underscores in these are converted to spaces. The default setting is BUSY NO_CARRIER NO_DIALTONE. uu.errors Number of errors before aborting a uucico session. Normally set to 200, set this higher if you are transferring very large files over a noisy link. uu.exit Program exit status ("errorlevel") for successful transactions; this means at least one completed connection. uu.fail Exit status for failure, meaning either a configuration problem or no connections were successful. Both uu.exit and uu.fail are intended for interfacing with other programs. uu.grade Default grade at which transfers are performed. The -g parameter will override this. By default, no grades are set, and all files queued will be transferred. uu.handshake Time, in seconds, to wait for responses during the uucico handshake sequence. Raise this if you get "Startup timed out waiting for remote system" because of a loaded machine on the other end of the connection. By default, this is set to 30. uu.locked Speed at which to lock the modem<->computer connection. Used for some high speed connections. uu.retries Default number of retries when polling. Normally 1, this can also be overridden with the -r command line option. uu.retrytime Time to wait in seconds between retries. By default this is 10 seconds, which is long enough for most modems to reset for the next call. uu.time For expect/send sequences, the default timeout before aborting or sending an alternate. Equivalent to -t. uu.visual Debug level for screen output. By default this is the same as uu.debug, and vice versa. uu.windows Maximum number of windows for G protocol. Normal settings are 3 or 7. By default this is 7. If you have very noisy lines, setting to 3 may be more efficient. USING UUCP TO TRANSFER FILES o Transferring files The UUCP.EXE program allows files to be transmitted to and from any neighboring Unix or Waffle system, via the DOS command line. To "push" a file from DOS to the remote Unix machine: uucp filename.here unix!~/filename.there To "pull" a file into DOS off the remote unix machine: uucp unix!~/filename.there filename.here In both these examples, "unix" refers to the name of the remote Unix machine, "filename.here" refers to a DOS filename, and "filename.there" refers to the file on the Unix machine. You may also issue UUCP commands from the Unix machine in a similar manner; you may have to specify a full directory path in some instances (behavior is slightly different). o Command line options available These must be specified before the remainder of the command; for example "uucp -C -j foo.bar them!~/foo.bar". -C Copy file into a temporary file located in the spool directory. This is useful if you intend to delete the original before the actual transfer occurs. -j Print job number as it is queued. -u Specify the sender's username. By default, this is set to "uucp", which is sufficient ok for most purposes. Example "-uroot". o Caveats when using the UUCP.EXE program Currently Waffle will only allow you to transfer remote files into the /spool/public directory, or any of its subdirectories. Files being "pushed" over must still exist at the time of transfer, or the action will fail. On Unix systems generally you will use the /usr/spool/uucppublic directory in the same manner as /spool/public. Using other than the ~/ directory (~/ is a shorthand for "home directory") will usually result in a permission problem. Uucico must be run with the -w option to fully activate these features, to override Waffle's security. Multiple hops are not supported by the UUCP command. Transferring to directories other than ~/ is not guaranteed. Do not use the -a option with normal connections. It is intended for use only with special anonymous UUCP-only accounts. The -a will prevent unauthorized mail or news from being injected into the network from unscrupulous parties. THE UUX PROGRAM - SENDING EXECUTION REQUESTS UUX is used to request execution of a command on a remote Unix system. Most requests are either rnews or rmail, and UUX is automatically invoked by RMAIL and RNEWS. An arbitrary command may be executed on a remote node by using the syntax uux camden!lpr < filename Prints "filename" on remote UUCP node "camden". Note that camden must allow remote execution of lpr; by default it does not. You can request than any command be executed; more often than not, however, the request will be denied unless steps have been made to specifically allow it. Command line options available are -b Set binary mode on file transfers. By default, translation to Unix carriage return format is done; the -b option overrides this. -i Take input from specified file, which MUST be on the same device (it may be in a different directory however.) The file is renamed into the spool queue, and thus vanishes from its original location. This option is for performance; it will avoid copying the file. -j Print job number as it is queued. -p Force the use of standard input. Normally, standard input is not read from unless there is redirection or piping involved. -u Specify the username of the sender. With Waffle this is usually "-u%A"; it is not required. -v Verbose mode; includes some extra debug info. An example is "uux -j camden!lpr < file.txt". Static file configuration options uux.exit and uux.fail are the success and failure codes returned, and by default are zero and one respectively. THE UUXQT PROGRAM - PROCESSING INCOMING JOBS The UUXQT program is responsible for determining how to process incoming traffic. Options available at the command line are: -c Selectively execute commands. This is useful when you want to delay the processing of news: uuxqt -crmail processes incoming mail only. Jobs other than rmail's can then be processed later. -f Set disk space requirements for running UUXQT, if you need "slack space" for any reason. The syntax is -f(disk)=(bytes), for example, uuxqt -fD=200000 Will require drive "D:" to have at least 200K space available before processing any incoming jobs. Multiple disks may be handled by multiple -f's. Use of this option will usually require manual intervention if the free disk space should fall below any requirements you've set. By default, there are no requirements. -s The -s(site) option to UUXQT permits received jobs to be processed for only a single site, regardless of whether there are other sites with jobs waiting. The default is to process jobs from all sites. -v Run in verbose mode, slightly more information. UUXQT deletes jobs after they are successfully completed. If you are having trouble with an individual job, it may be useful to feed the job manually into RNEWS or RMAIL to see what the problem is; it may be necessary to delete the job altogether. Exit codes returned to DOS by UUXQT are 0 Normal exit. 1 An error in the configuration. 2 Disk space requirements in -f exceeded. Note that failure of a job to execute is not considered an error, as this will happen occasionally during normal operation. "...one of the main causes of the fall of the Roman Empire was that, lacking zero, they had no way to indicate successful termination of their C programs..." Unknown, quoted by Robert Firth. INSPECTING THE SPOOL QUEUE WITH UUQ UUQ tells us what is currently queued for all the systems with which there exists pending traffic. A typical response from a system that has multiple connections: uuwest: 4 jobs queued -------------------------------------------------------------- 0817 root 26 Jan 17:19 583 rmail vid@darkside.com 0818 uucp 26 Jan 17:25 1449 rmail uuwest!alex 0819 usenet 26 Jan 20:31 50190 rnews 0820 usenet 26 Jan 20:32 10441 rnews yahoo: 1 job queued -------------------------------------------------------------- 0816 uucp 25 Jan 23:02 2241 rmail yahoo!gestapo You may also specify a system for which you want to look at traffic, the syntax for this is "uuq uuwest". Passthrough traffic will also be displayed. However, incoming jobs that have not been processed by UUXQT will NOT be displayed. Command line options available to UUQ are: -d Delete a job from the spool queue. Give the job number as an argument. For example, uuq -d5150 results in the message Job 5150 (uuwest) deleted. If the -u option is given as well, only jobs created by that user can be deleted. -s View job information for a specific host. By default, information is displayed for all hosts. Note "uuq vox" is equivalent to "uuq -svox". -t Includes totals at bottom of columns. Shown are the total number of files and total bytes queued. -u Restrict display of files to a specific user, for example, the command uuq -udan will only show full details on jobs created by the user "dan". For jobs owned by other users, the owner and command are not shown. LOGGING AND DEBUG LEVELS For really advanced users only. o /waffle/admin/uucico Waffle UUCICO writes to the /waffle/admin/uucico as it proceeds. Under normal circumstances, only a modicum of information will be written there -- this is when the debug level is 4 or less. The -x switch, or 'uu.debug:' static file parameter control how much information is written to the log. -x0 Minimal information. Not recommended. -x1 -x2 -x3 Logs individual file transfers and statistics. * This is the recommended level. -x4 Includes "interfile" messages, and also detail of the connection scripts. This is the highest setting to use under normal usage. And with regards to the packet engine: -x5 Information about certain interesting packet driver events. -x6 A trail of all packets sent or received, their numbers and types. -x7 Includes a dump of the "g" protocol packet headers. -x8 Includes a raw dump of all data transferred. This causes the UUCICO logfile to grow enormous. -x9 Far too much information to be useful. When running, if anything above -x5 is displayed to the screen, throughput will suffer considerably due to the high overhead of screen I/O. Use -v4 to cut this down. o /waffle/admin/uulog File transfers that don't match Waffle's idea of news or mail batches are written to the UULOG file. Example: 03-Jan-92 00:36 lugnut | ACCEPTED | S C:/PUBLIC/WAF165.ZIP 03-Jan-92 00:38 ozone | ACCEPTED | R ~/read.me This is particularly useful if you provide anonymous UUCP. Denied transfers are also logged in this file. THE PERMITS FILE The permits file is checked in the order 1. The -p flag given on the command line. 2. A permit matching the system name. 3. The "default" permit. You shouldn't have to change the permits file unless you're doing strange things (poweruser stuff). Options available in the permits file. Note, not all of these are fully implemented. /system The system name associated with this permit. Can be wildcarded as /system=known or /system=any. /commands Commands that can be executed by uuxqt for this permit. (This isn't implemented, and may change..) /account Account that may use this permit. Can be wildcarded as /account=any. /download UUCP sending directory for files other than D.* or X.*. A subdirectory of the "spool" directory unless a full pathname is given. /upload UUCP receiving directory. See /download. /time Times that incoming connections are permitted. Mainly for anonymous UUCP. The format is the same as that of the /waffle/uucp/systems time field. /speed Minimum speed permitted for this system when dialing in. BEYOND MAIL AND NEWS The UUXQT program will execute RMAIL or RNEWS as appropriate, which is all that is normally required for most UUCP connections. However, certain custom applications may require additional commands to be executed (by using UUX on the remote system.) The "uuxqt:" variable in the static file specifies what commands can be executed by UUXQT. The default is set to uuxqt : rmail rnews If an additional command is needed, for instance a command to print a file on the DOS printer, add an entry to this line: uuxqt : rmail rnews lpr Whenever one of these commands is encountered by UUXQT, it will execute the command in the "bin" directory with the same name; "lpr" would execute C:\WAFFLE\BIN\LPR.EXE. GRADES This section describes behavior when the -g option is used with UUCICO to transfer only subsets of files. The reason to do this is usually to restrict news transfers to certain hours due to cost. RMAIL jobs can thus be transferred during the day, and both RMAIL and RNEWS jobs at night. Grades are single characters, and are part of the filenames kept in the spool directories. DOS does not differentiate between case in filenames so we have chosen a different approach to this than Unix. But, when you give a grade as a parameter to UUCICO, case is then significant to the Unix system. When a grade is set, only files of that grade are transferred. If you want to transfer multiple grades during a single session, specify multiple grades in the -g parameter. For example, take the common situation where we want to use grades to restrict news transmissions until afterhours, to save money. Either set 'newsgrade' in the static file to N, or modify /waffle/extern/_system to have -gN on the "news" line. newsgrade : N Similarly, set the 'mailgrade' to C, or modify the _system file to have -gC on the "mail" line. mailgrade : C When polling, use the appropriate command line In daytime, uucico -ssystem -gC At night, uucico -ssystem -gCN You might add the static file parameter 'uu.grade' to default to transfer only mail, the cheapest. uu.grade : C Under normal circumstances, grades are not used, and files will not have grades attached to them. We reserve the right to change this behavior (making grades mandatory); if you are writing software that depends on the filenames in the spool directories make sure that it can handle grades properly. Grades are part of the job number, so if you want to delete a graded job, include the grade as part of the UUQ -d(job). WAFFLE'S FILENAME MUNGING This section is included for informational purposes, and for those writing any bizarre gateway software. Files are placed in a directory beneath the spool directory underneath /spool named for the corresponding system. Files for a system "elf" would thus be in /spool/elf. Outgoing files are assigned numbers from the SEQF file in an incremental fashion. These files are not munged in any fashion. For example, Job 3061 queued for elf would appear as: /SPOOL/ELF/3061.DAT Data file /SPOOL/ELF/3061.XQT UUCP job control file /SPOOL/ELF/3061.CMD Call file Incoming files are munged because the Unix filenames do not fit DOS naming conventions. A Unix UUCP filename may look something like D.systemXm2L1 or D.systemBC0312; there are a variety of other formats that are possible as well. For conversion, the prefix is moved to the end of the filename, and the system name is stripped off. An extra byte is added to prevent collisions due to DOS's handling (or lack thereof) of mixed case filenames. D.ozoneBC0312 -> /SPOOL/OZONE/0BC0312.D X.ozoneBC0312 -> /SPOOL/OZONE/0XC0212.X You will notice a leading "0" before the filename. This is a bitmask of the alphabetic case of the remaining characters. In this example below, the bitmasks are "4" and "6" respectively: D.ozoneB7n72 -> /SPOOL/OZONE/4S7N72.D X.ozoneX7pt0 -> /SPOOL/OZONE/6X7PT0.X To construct the bitmask, give all lowercase characters a value of 1 and all uppercase or numeric value 0; do not include the hostname when forming the bitmap. Also use only the last five characters when constructing the bitmask. When taken together, the the numeric value of the bitmask is the value of the leading byte. If this exceeds 9, use the letters A through Z as necessary. One nice thing about this is that the leading byte will often equal zero, particularly in the common case where the filename is completely numeric or uppercase. SETTING NONSTANDARD PACKET SIZES For really advanced users only. Under some circumstances, performance may be increased by using a larger packet size. This is particularly true with V.32 and also certain "half channel" modems. The default -k size is 64. Valid -k sizes are powers of two: 64, 128, 256, etc. The maximum allowed currently is 512. Even then, use 256. Note that the site with the lowest -k setting will get its way. Thus both sides must set -k in order for it to be enabled. If you do use -k, set uu.windows to 3. Do this for several reasons: o Error handling will be faster since whenever an error occurs, only 3 packets (3 * 256 = 768 bytes) instead of 7 (7 * 256 = 1792) need to be retransmitted. o The interrupt buffers will probably overflow causing untold misery. Throughput is reduced to a negligible trickle, and you will start to hate yourself. Also, if you use a FOSSIL driver, be sure to adjust those buffers high enough that overruns do not occur. o Performance increase of 7 over 3 becomes less relevant with larger packet sizes. Some important caveats before you jump ahead: o You CANNOT use this option with traditional Unix UUCP's (they may even accept the larger packet size and then crash.) However, you can -k with other Waffle systems. o Do not use this if you are talking Telebit<->Telebit. Instead, enable spoofing as described in the TELEBIT.DOC file. o This has only been tested Waffle<->Waffle. DECUS UUCP for VAX/VMS is rumoured to support these larger packet sizes. For those who play with this feature, we'd like to know your results. LIMITATIONS AND PARANOIA UUCICO will not operate in "standalone" mode. It does not know how to answer the phone (and never will), so you must have a frontend program. For those who insist on attempting to multitask under DOS, please don't. You have better things to do with your time. Run your BBS on SCO Xenix.. you'll be much happier. The following 1.64 command line parameters were deleted in 1.65; it is important to update any BAT files as appropriate: -a Anonymous is no longer used. To support anonymous UUCP, read the section regarding the PERMITS file. -q Quiet mode has been replaced by the -v Visual debug level. -w Trusted is no longer used. Functionality can be found in the PERMITS file. -- dell@vox.darkside.com (C) Copyright 1992 Darkside Int'l