-*- Mode:Text -*- The system in this directory lets you execute remote Unix commands from an Explorer, and lets Explorers spool print requests to printers attached to Unix machines. Additionally, Unix machines may execute Lisp commands by using the /usr/ucb/rsh command or the rexec(3) C function. It is not currently possible to spool print requests from a Unix machine to a printer attached to an Explorer, but this code has the appropriate hooks in place for such a server to be implemented. DEFSYSTEM.LISP - Defines the NETWORK-SERVICES system. POSTSCRIPT-PRINTER.LISP - Re/Defines methods for PostScript Printers for LPD. PRINTER-SERVICE.LISP - Defines the UNIX LPD daemon protocol. SERVER.LISP - Redfine some of the PRINTER server code. REXEC-SERVICE.LISP - Defines the REXEC and RSH UNIX protocols. TCP-MEDIUM.LISP - Lets the TCP-STREAM medium to specify a local port. TCP-STREAM.LISP - Defines the UNIX Translating Stream. UDP-STREAM.LISP - Allow the UDP-STREAm medium to use UNIX streams. UTILITIES.LISP - Some useful functions for use with these protocols. REXEC and RSHELL: ================= NET:REXEC - Performs a remote execute (UNIX REXEC funtion) to a remote host. The protocol is defined in the REXECD manual entry on the UNIX machines. For this to work, you must make these additions to the Service Lists in the TI namespace: Machines with a TCP address -> (:EXEC :TCP-STREAM :UNIX-EXEC) Machines with a CHAOS address -> (:EXEC :CHAOS-STREAM :CHAOS-EXEC) NET:RSHELL - Performs a remote shell (UNIX RSH function) to a remote host. The protocol is defined in the RSHD manual entry on the UNIX machines. For this to work, you must make these additions to the Service Lists in the TI namespace: Machines with a TCP address -> (:SHELL :TCP-STREAM :UNIX-SHELL) The normal protocol for EXEC and SHELL requires a certain amount of security to validate the request. Part of this validation procedure uses passwords and equivalent hosts. This is not part of the normal operating system for the TIs so these protocols by default look for this information in the following files (which should be in the home directory of the concerned user): PASSWORD.REMOTE - Should contain one line which is the password that has to be given for someone to REXEC to this machine as this user. If not present, no attempt to REXEC will work. HOSTS.REMOTE - This file should contain a number of lines of the form: Each tells that the given USER can log onto this Lisp machine from the given HOST as the concerned user. If this file is not present then it is assumed that no users can log in as the concerned user. Note that the above files are local to each Lisp machine. There is one more feature for these protocols. The variable *REMOTE-LOG* can enable logging of all remote requests made to this machine, along with the information passed over in the request and the time of the request. If the variable is a pathname, then logging is enabled. If it is NIL then no logging is performed. The information about the REXEC and RSH protocols was found on the UNIX machines by using MAN on REXECD and RSHD. There are a few differences between the protocol here and the "official" protocol. Most notably, the server for the EXEC and SHELL services do not require that the UIDs or passwords be 16 characters or less. There is also no limit on how long the command can be. (However, the client sides DO enforce the 16 character limit by truncating the strings). In addition, the UNIX version of the protocol will start by only sending the port number of stderr and then wait for that connection to be made before the rest of the information is sent. The clients on the TIs do not wait, all the information is sent in one lump. The Chaosnet version of the protocol is a little different in that the vital parameters for the connection (stderr port and so forth) come across in the initial contact string and are not part of the actual stream connection that gets set up. In addition, since the SHELL protocol is based on a security scheme, and the Explorers don't have a notion of security, there is no Chaos version of the SHELL protocol. Known Bugs The biggest bug is that I still seem to need to abort connections with the UNIX machines to to force them to close. This cannot be right, but I can't get it to work any other way (unless I want to let the connection sit around long enough to time out). There must be something that the UNIX side is waiting for before closing the connection that I am not sending. LPD - Spooling Prints to a Unix Server: ======================================= When this code is installed properly, calling PRINT-FILE with the appropriate :PRINTER-NAME argument (or having the default printer set correctly) will transparently spool your file (be it text or bitmap) to the unix printer. The TI printer code has been seriously modified to know about the posibility of the printers not being attached to an Explorer. You must some things to the TI namespace. For each host which has a printer attached to it: Machines with a TCP address: (:LPD :TCP-STREAM :UNIX-LPD) Machines with a CHAOS address: (:LPD :CHAOS-STREAM :CHAOS-LPD) As an example, the entry for a Laserwriter attached to a Unix machine would look something like: :PRINTER "some_laserwriter" :HOST "some_unix_host" :TYPE :POSTSCRIPT-PRINTER :REMOTE-NAME "some_laserwriter" You don't need to specify :BAUD-RATE, etc because the unix host knows all of that already. In addition to having the appropriate code loaded and data entered on the TI end of things, the Unix host must be told that it can accept print requests from your Explorer - this is a security "feature". The names of all of your Explorers should be listed in /etc/hosts.equiv - this will make your hosts be known as "trusted hosts" to the Unix machine. On some versions of Unix, there may be another file which additionally lists hosts which are allowed to make print requests - talk to your Unix system administrator.