This high-level facility should be able to operate over diverse hardware types, have a checksumming and retry capability for reliable transmission, a spooling mechanism to keep requests from getting lost if a system is temporarily down, and a way to acknowledge the completion of requests. At the very least, it must be able to transfer files and do remote program execution.
You may not realize it, but this high level facility is probably already at hand. UUCP meets all of the requirements quite well. Its chief cost comes in the few days of programmer time it takes to interface with XNS or IP/TCP in most implementations. This owes to the interfacing scheme of XNS and IP/TCP, which requires that access be made through custom library routines. For XNS, one can specify a device named xns in UUCP's L-devices and L.sys files for connection with systems communicating over XNS. In doing this, though, one should not place an exclusive use lock on the xns device, nor should one apply RS232-type ioctls (such as for setting the baud rate).
Once UUCP is configured, network servers can be developed. Since a single printer is generally shared among several systems, one often develops a printer server first. This and other servers can be often be simple shell scripts.
Assume the standard UNIX printer spooler, lpr, is used to actually drive the printer and that the system connected directly to the printer is called bigiron. On those systems not connected directly to the printer, one could remove the standard lpr program and replace it with a shell script to do remote spooling. The following script is typical:
cat $* | uux bigiron!lprIf a list of files is supplied as an argument when the script is invoked, $* will expand to this list of files and they will be concatenated. If no arguments are supplied, $* will expand to a null string and standard input will be read. There are several features that could be added. One might be to tell lpr to print the name of the account invoking the script on the banner page (without such a script, the account name uucp would be printed on the banner page instead).
There are also other ways to make use of remote printers via UUCP. The uux program, for instance, is UUCP's own way of doing remote execution. Its first argument, a dash (-), tells uux to read its standard input (piped from cat) to EOF and then supply it as standard input to the remotely executed program. The second argument (bigiron!lpr) indicates which system to use for the remote execution and what program to execute. Under uux syntax, the system name (bigiron) should appear to the left of the exclamation mark (!) and the program to execute (lpr) should appear to the right.
To maintain security, the remote system will only allow certain commands to be invoked by uux. This list of legal commands appears in different places in different implementations. In most, the list is contained in a file in the /usr/lib/uucp directory called L.cmds, L-cmds, or uuxqtcmds. In others, it is compiled into /usr/lib/uucp/uuxqt, which is a program that a binary licensee must patch in order to change.
It should be noted that UUCP can communicate between computers from different manufacturers with different processors running different versions of UNIX. When a program is remotely executed (invoked) the binary that's used comes from the machine doing the actual work. This allows, say, a M68010 system to remotely execute a program on a VAX.
With the current proliferation of laser printers, troff is becoming commonly available. A server under UUCP can be used to invoke troff on a system connected to a remote printer, even when the text to be troffed resides locally. Thus, a troff server patterned after the lpr printer server is needed. It must have additional smarts built in, however, to deal with troff flags. This is handled by the script listed in Figure 1.
opts=""
system=bigiron
while [ "$1" != "" ]
do
case "$1" in
-*)
opts="$opts $1"
shift
;;
*)
# troff a list of files
cat $* | uux - $system!troff $opts
exit 0
;;
esac
done
# troff from standard input
uux - $system!troff $opts
exit 0
Figure 1 -- An example of a server that can be used to
invoke troff on a remote system.
A network mail server is already built into UUCP and mail. To send mail to someone, the account name and the name of the system it is on must be supplied. Thus, to send mail to an account called jill on the system called onyx, the following commands could be used. Under csh:
mail onyx\!jillUnder the Bourne shell:
mail onyx!jill
This sort of approach is fine for a set of five or 10 accounts where all the pathways are known and easy to remember. If one must communicate with 100 accounts distributed over a dozen workstations and a few VAXen, it's almost impossible to keep track of what system an account is on. (It is usually possible to track account names by using, say, a person's first name. If several people have the same first name, then the first letter of their last names can be part of their account names.)
What is needed is a mail server that knows where any given account is located. One could then send mail to jill and the server would know to send mail to onyx!jill. There is already the capability to do this on any UNIX implementation that has Mail, sendmail, or delivermail. With straight 4.1BSD, 2.9BSD, 4.2BSD, or a system with "Berkeley enhancements", one of these is probably available. To be sure, issue the command:
% ls -l /bin/Mail* /usr/*/Mail \
/usr/lib/*sendmail /etc/delivermail*
With sendmail or delivermail,
aliases can be added to the file /usr/lib/aliases. These
aliases are usable by everyone on the system. The syntax calls the name given
to Mail and a colon (:), to be followed by a tab and the name
to actually use. Thus, for our previous example, add the line:
jill: onyx!jillWith this in place, mail can be sent to Jill by as simple a command as:
% mail jill
With Mail, aliases can be provided by similarly editing the file /usr/lib/Mail.rc (or the file .mailrc in your home directory if you wish to limit the effects to your own account). For example, adding the line:
alias jill onyx!jillwill allow one to send mail to jill with the command:
% Mail jillNote the capital M. Even on some systems that do not have Mail, this last example will work with a program called mail rather than Mail. To see if a system's mail program has this capability, issue the command:
% mail -u oopsIf the error message "oops" is not a user of this system returns, then the system has the ability to alias mail destinations.
We've only scratched the surface. Many other UUCP servers can be developed as needed. One might create a "wall server", for instance, to invoke the wall program on a network of systems. This would allow the wall command to broadcast its standard input to all people logged into a network, meaning it could be used for making company-wide announcements. (Since wall is in the /etc directory, either list it as /etc/wall in UUCP's L.cmds file or link it to /bin/wall.) For less urgent announcements, a server can be created for using the 4.2BSD msgs or System V news programs.
How many other uses can UUCP servers be put to? The possibilities are limited only by imagination.