BACKGROUND

The subject agency currently operates from three geographically dispersed offices, two of which are satellite locations whose local systems communicate with the central office via the Internet.  In each office, one or more Windows 2000 workstations are networked to one of our Uni-FI^TM Ultra160 UNIX servers (one of which is AMD Opteron powered—it's a speedy little bugger), running SCO OpenServer Release 5 (OSR5) and Samba for Windows connectivity.

Each office's server is the local Windows log-in server and master browser, and also provides Windows printing services.  The main office's server acts as the Windows primary domain controller and domain master browserfor the entire agency, and is also the central data repository.  Windows drive letter mappings that are established when a user logs in provide varying degrees of access to insurance data, and also institute Mozilla roaming profiles.  We laid out this system with the basic premise that insurance agencies make money by writing policies and servicing their clients, not by managing and troubleshooting computers.  Therefore, a lot of effort has been expended to make this system secure, easy to use and reasonably fool-proof.

Day-to-day agency management is performed with Redshaw Elite, which is host-based, vertical software that was developed some 25 years ago to run on Wang MVP minicomputers.  During the 1980's, Redshaw became an insurance industry standard and thousands of agencies ran their operations on it.  Around 1990, the software was ported to UNIX (originally SCO UNIX 3.2), using Kerridge Computer's idiosyncratic KCML interpreter to execute the Wang MVP BASIC programs that make up the package.  An officially supported OSR5 implementation was never produced, although the UNIX 3.2 version of KCML can be run in the OSR5 environment.

At the time of its UNIX port, it was thought that Redshaw would eventually fade away and various Microsoft-based equivalents would take over.  Hence significant development came to a halt in the mid-1990's.  Although any number of Windows-based agency management packages are now available, Redshaw is still in common use, remarkable considering that it is an old character-based app.  The most-often cited reason for this is that being host-based and character-oriented, Redshaw is a friendly and stable package with modest resource requirements —nothing runs on the client except a terminal emulator—and that i t performs at a level which makes the Windows equivalents look like sumo wrestlers trying to compete in Olympic pole vaulting.

This is not to say that Redshaw is computer nirvana for overworked insurance agents.  For one thing, there's that screwball KCML interpreter to consider—it se ems to have been designed by Lucifer himself, what with dongle protection, the unique and obtuse Wang MVP BASIC dialect, and a very strange system interface.  Also, Redshaw's data storage methods emulate the old Wang MVP "platter" setup, which grossly under-utilizes the capabilities of modern UNIX filesystems, especially in the area of the maximum amount of live data that can be accessed in a Redshaw session.  And, of course, ongoing development no longer exists.

More seriously, Redshaw is not network-aware, a natural consequence of its age.  It is possible for a remote client to Telnet into the server and start a session.  However, Redshaw knows nothing about NFS or other standard UNIX network services, and only understands locally attached printers.  The latter limitation is particularly onerous, as Redshaw cannot talk to lpd (li ne printer daemon) printers, thanks to the odd method by which the KCML interpreter interacts with the lp subsystem.  The result is that while it is possible for a remote client to run Redshaw over the Internet, it is not possible to send printer output back to that client using orthodox methods.

Up until recently, remote printing from Redshaw wasn't an issue with our client, as only one of the two satellite offices was in operation, and it was staffed only by appointment.  If the agent at that office needed hardcopy, s/he would print to one of the printers controlled by the Redshaw host in the main office and then have someone there fax over the results—naturally a cumbersome and inconvenient procedure, and not practical with certain types of forms (e. g., auto insurance ID cards).

When our client indicated that they were going to staff the first satellite office full time and were planning to open another location, Redshaw's remote printing problems suddenly became a major malfunction, and a solution had to be devised.

"rlp01">REMOTE LINE PRINTING

Ironically, part of the solution to our client's remote printing problem already existed at the main office—it just wasn't immediately apparent.  There, printers are attached to the local subnet and are driven through the standard OSR5 lp subsystem.  The network interface is handled by a custom driver named nlpcatd, which I had concocted some years ago during a fit of annoyance caused by a particularly frustrating battle with OSR5's built-in HPNP (Hewlett-Packard Network Printing).

Prior to writing my own code, I had perused this site (and a few others) seeking a solution that didn't require HPNP.  Many that I investigated involved the use of modified printer interface scripts that put Kevin Smith's handy netcat utility to work sending packets to the printer s.  I was reluctant to adopt this approach, as the use of custom printer interface scripts can open the door to hard-to-solve coding errors, as well as possible loss of functionality due to someone substituting a different script for the modified version.  Also, it was clear that the result would not be particularly portable to non-SCO systems.  Did I mention security issues that could arise with using a filter like netcat to print to a printer over the Internet?  After mulling over this stuff for a while, I decided to head off in another direction.

My analysis of the situation identified three requirements:

• Achieve transparent operation without regard to how printers are exposed on the network.  Operation should be the same whether a printer is networked through internal hardware, is a parallel port model attached to a print server device (e.g., a Hewlett-Packard JetDirect), or is a unit controlled by the lpsubsystem of another UNIX or Linux server.  Implied in this requirement was that operation should work over the Internet as well as on the local subnet, assuming that suitable routing existed.
  
  
  

• Prevent unauthorized connections to printers.  Obviously, security is always a major concern on anything that is exposed to the Internet.  My security approach would be two-fold: authenticate incoming connections to printers against a list of authorized clients, and restrict TCP port usage to the registered or dynamic range.   The latter would obviate the need to relax firewall packet filtering rules, thus minimizing the likelihood of an intrusion through a privileged port.
  
  
  

• Eliminate the need to modify lp subsystemfiles.  Many of the methods described in other articles have involved the modification of printer interface scripts to redirect output to programs like netcat and thus on to the network.  As I said before, I felt that the package would be more portable if it could be made to work with whatever interface scripts were provided with the standard operating system installation.
  
  

The RLP (Remote Line Printer) client/server subsystem that will be described herein addresses each of the above items.

I have been running various incarnations of RLP on our main office file and print server (currently OSR 5.0.6 with Samba 2.2.12) since mid-2000 without any significant incidents.  I have even used the latest version of RLP to print stuff on my clients' printers from here in my office (in once case, I sent a client an invoice by printing it on his printer from my office—thereby saving the cost of an envelope and stamp).  Based on this experience, I believe I have developed a workable arrangement that any reasonably competent UNIX administrator can implement on his/her OSR5 machine(s), or with a little modification, on Linux or other UNIX hosts.

In this first article, I will address the driving of printers that are directly exposed to a network and that listen for data on a particular TCP port—this describes many networked printers, both those with built-in networking and those that are attached to an external print server.  The next article will describe the scheme I contrived for driving a printer that is under the control of another UNIX or Linux server, without involving lpd.  Although RLP does not use it, you should obtain a copy of netcat and learn how it works.  You will discover netcat to be a very useful network diagnostic tool (I've used it to debug router problems, among other things), as well as a handy device for getting acquainted with some of the interesting aspects of communicating through a network.  You should also obtain a copy of Jeff Liebermann's print server port number list, which information will be required in order to configure your system to use RLP.  All of this will be explained in due course.

DISCLAIMERS

Before continuing, here are some weasel words to entertain you.

While I have no reason at this time to suspect that there are any fatal flaws in what I am about to present, I guarantee nothing.  Furthermore, before you get all excited about setting up your own RLP subsystem and linking all your friends' and family's printers to your home network, please be certain that you fully understand the security implications of exposing your system (and theirs) to the Internet.  If you choose to implement anything described in this article, you do so at your own risk.  I take no responsibility for anything that might go wrong, explode, start fires, annoy your dog, bankrupt your business or otherwise ruin your day.

OSR5 PRINTING

In order to better implement RLP, you should know something about how OSR5 runs your printers.

Conventional OSR5 printing involves the use of the lp subsystem to communicate with one or more printers hardwired to EIA-232 (serial) and/or Centronics (parallel) ports on the host machine.  Printing is initiated by writing something to lp's standard input or by passing one or more filenames to be printed as command line arguments to lp.  In either case, lp willhandle all of the subterranean mumbo-jumbo required to drive the target printer and report back with a job ID, such as hp2300a_1147.  In more academic terms, lpprovides a layer of abstraction between the user application and the physical device on which printed output is to appear.  Hence the application doesn't need to know anything about the way the printer is hooked up to the server in order to print.

Interposed between lp and the target printer is a file called an interface script, in which the incantations required to control the printer are contained (incidentally, an interface script is not a driver).  When a print request is submitted, the statements in the interface script will be executed to process command line options passed to lp as part of the print request and to arrange for the data flow to find its way to the target printer.  OSR5 ships with a variety of interface scripts (called models) that support common printer types, the appropriate script being selected at the time the printer is configured into the system.

Also configured during printer installation is the device to which the output will be sent, defined by filesystem names such as /dev/lp0 or /dev/tty1a14.  In OSR5, actual communication with the device is normally handled by a filter called lp.cat, which is executed by the interface script.  lp.cat writes on its standard output, normally directed to the device file associated with the target printer.  However, lp.cat's output can be redirected, such as to the local subnet.  This is the basis for printing to network attached printers.

As mentioned before, what started me on the road to RLP was trouble with the HPNP component of the standard OSR5 printing software.  HPNP is a cantakerous conglomeration of code that will often fail to performdue to its reliance upon SNMP (Simple NetworkManagement Protocol, with Stupid often being substituted for Simple).  SNMP is not universally implemented in printers and print servers, and unless changes are made to the HPNP operation to account for this, non-SNMP aware printers may not respond to HPNP at all, and, of course, won't print.

All in all, my take on standard OSR5 network printing via HPNP is that it is a poorly designed arrangement, a Rube Goldberg-ish mishmash that was apparently concocted by an inebriated gorilla wielding a crowbar and sledge hammer.  In my opinion, the whole mess flies in the face of good UNIX practice.

IT's ALL IN THE PLUMBING

With some of the above information digested, I will now turn to specifics.

The data flow that occurs when a job is submitted to an RLP controlled network printer looks something like this:

The steps shown in blue are standard OSR5 lp subsystem operations, while those in red are added by implementing RLP.

Recall that lp.catmerely writes on its standard output, which means that in the above scheme , it has no idea that it is not actually talking to a printer device.  In other words, as far as the lp subsystem is concerned, absolutely nothing that it knows about has changed in any way, shape or fashion.  What has changed is what happens to the data stream after it leaves lp.cat.  Here it goes to a fifo instead of to a real device like /dev/lp0.  This is the key to rerouting the data stream onto the network.

A short digression: a fifo (First In, First Out)or named pipe is nothing more than a conduit for data.  Using an obvious plumbing analogy, something delivers water to a pump at one end of the fifo, the pump pushes it through, and something else sucks the water out of the other end and delivers it to yet another location.  If the pump runs out of water and stops pumping, suction will stop and wait.  Conversely, if the pipe fills up because suction has stopped, the pump will likewise stop and wait.

The "pump" in the above analogy is lp.cat and the "suction" is provided by nlpcatd.  As data flows through the fifo, nlpcatd will transfer it on to the network and to the target printer.  Mechanisms that are part of the TCP protocol will assure that nlpcatd sends data to the printer only as fast as it can accept it (a procedure called flow control).  If the printer goes off-line for any reason, such as because it has run out of paper, nlpcatd will patiently wait until someone shows up to refill the paper tray and place the printer back into service.  Ditto if the network connection is temporarily broken.  When all data has been sent, nlpcatd will disconnect from the printer and the cycle will repeat.

SETTING UP LOCAL RLP

Setting up RLP on a typical OSR5 system is straightforward.  You will need to gather some information about each RLP controlled printer, and then perform some administrative tasks to get everything working.  The information you will need is as follows:

• lpsubsystem destination name.  This is the name by which the lp susbsystem "knows" the printer, and may be any name that makes sense to you.  The scheme I like to use is <model><suffix>, where <model> is a synopsis of the make and model of the printer, and <suffix>is a single letter of the alphabet.  For example, if there are two Hewlett-Packard LaserJet 2300 printers, the first would be designated hp2300a and the second hp2300b.  A Mannesman-Tally 6050 impact line printer would be named mt6050a.  On OSR5, the lp subsystem imposes a 14 character limit on destination names, and allowable characters are A-Z, a-z, 0-9 and the underscore.  I recommend that you do not use uppercase letters.  In paragraphs that follow, I will refer to the lp subsystem destination name as < lp_dest>.
  
  
  

• Host name.  The host name is also something that you think up, subject to the limits imposed by the operating system.  The naming convention I use is rp00 for the first defined printer, rp01for the second, etc.  If the printer or the host server that controls it is not in the local domain, use a fully qualified domain name, such as server.somewhere.com.  In any case, I do not suggest using the lp destination name as a host name, because it is possible to create an lp destination name that is incompatible with the host naming rules that the operating system enforces.  In paragraphs that follow, I will refer to the host name as <host> .
  
  

• IP address.  Each networked printer must have a unique IP address, which you usually assign when you configure the printer for the first time.  For private, non-routable subnets, like a office LAN, the IP address will be something like 172.16.xyz.yyy or 192.168.xyz.yyy.  I generally work backwards with printer IP addresses: for example, on our office system, rp00 is 192.168.100.254, rp01 is 192.168.100.253, and so forth.  If a printer is to be exposed to the Internet (that is to say, connected directly to a gateway to the Internet), it will need a routable, public IP address, which you can get from your Internet service provider.  This is not a recommended setup, since most networkable printers have little or no built-in security.  You don't want the neighborhood script kiddie sending suggestive remarks or risquè pictures to your printer, right?  :-)
  
  
  

• TCP port number.  The majority of networked printers in use today operate by listening for connections on a specific TCP port  and transcribing any incoming data into hardcopy (don't confuse a TCP port with a hardware port on a computer—they're two entirely different things).  There is no universal standard for assigning TCP ports to network printers, so you will need to consult this list or contact the manufacturer of your printer to determine the correct port numbers.  Note that RLP cannot print to a printer that doesn't work as I just described.  If your printer is in that category you can stop reading right here.
  
  
  

• Service name.  A service name is a menmonic that is used to refer to a TCP port number.  For example, smtp (Simple Mail Transport Protocol) is the service name that refers to TCP port 25 (through which E-mail arrives and leaves).  You will need to associate service names with the TCP ports on which your printers are listening.  For example, an H-P JetDirect 300x print server, which is equipped with one parallel port, listens on TCP port 9100, to which I would assign the service name hpjd0.  H-P's 500x print server is fitted with three parallel ports and listens on TCP ports 9100, 9101 and 9102.  Logical (to me, at any rate) service names would be hpjd0, hpjd1 and hpjd2.  Obviously, you can pick any service names you want, as long as they are unique—check /etc/services to verify that you are not creating duplicates.  In paragraphs that follow, I will refer to this name as <service>.
  
  

With the above information at hand, you should proceed as follows:

• Place a copy of nlpcatdinto any convenient location on your system, such as /usr/local/bin.  Be sure nlpcatd is owned by bin:lp and has rwsr-s--- permissions (chmod 6750 nlpcatd will do it).  You should also obtain a copy of  nlpcatd's configuration file nlpcatd.conf and use it as a model for your own version.
  
  

• Define a fifo for each RLP controlled printer.  The OSR5 command to do so is: