"Linux Gazette...making Linux just a little more fun!"

We have an old Honeywell Bull Unix system. It uses some proprietary pr= int servers, which can't be updated, and cost $10k/yr to maintain. The Bu= ll system can't print to HP JetDirect servers, NetWare, or other Unix sys= tems. Enter Linux.

I'm still a newbie

It wasn't quite as easy as I thought. If it were, we wouldn't need Lin= ux. The Bull machine prints to BSD style remote print queues. But it woul= dn't print to Linux. OK, bring out tcpdump. Luckily using the tcpdump opt= ion host d2 and home, (the names of the Bull and Linux machines), cuts do= wn the traffic to just what we want to see. Tcpdump showed the Bull machi= ne trying to get access to the rsh port (514), not the remote printer por= t (515). However, it didn't show the contents of the packets, so we don't= know what it was trying to do. Tcpdump -w put the raw packets into a fil= e. Looking at them with a text editor (on a Win95 machine, SMB shared, an= other story), showed an error message: /usr/ucb/lpr, no such file or d= irectory.

First, create the directory with mkdir /usr/ucb

This meant it was coming in as a tty, looking for lpr in an old place = We needed a combination of ingredients. Putting a symbolic link from /usr= /ucb/lpr ->. /usr/bin/lpr solved one part. We had already looked at /v= ar/log/messages and seen that PAM was rejecting the remote host. Putting = the Bull machine in the /etc/hosts.lpd and /var/spool/lpd/.rhosts files a= llowed the remote machine in.

Rtfm, rtfm, rtfm

I have to add that many of these answers came from asking on the newsg= roups and mailing lists. I had read the printing howto, the Printing usag= e howto, the Linux System Administrators Guide, Network Administrators Gu= ide, man pages, ad nausium. One of the downsides of Linux being the most = thoroughly documented system is that there is more documentation to read.= I still haven't found out how to turn on printer accounting yet. There a= re some hooks built into the lpd, lpr system, but I don't see anything al= ready set up. Red Hat's printtool seems to use the /var/spool/lpd/<pri= ntername>/acct file in the printcap file as af=3D (which is the accoun= ting file), but then doesn't seem to use it for accounting. In fact, they= use it to find a .config file, containing user and password information = for SMB and NetWare queues. This prevents it from being used anywhere but= in the print spool directory. Aeleen Frisch's "Essential System Administ= ration", from O'Reilly, mentions that many systems use /var/adm. The Linu= x/Unix File Hierarchy Standard has a /var/account and /var/log directorie= s. it doesn=92t mention printer accounting specifically.

What, telnet to a printer?

HP JetDirect print servers, it turns out, act like remote Unix systems= . They have print queues, and you can even telnet to them. Telnet only gi= ves a configuration menu, not a real OS. So, to print directly to HP prin= ters, we use the Red Hat printtool to set each printer as a remote Unix m= achine. Now, the Bull machine prints to a Linux queue, which is defined a= s a remote queue on the JetDirect server. This allows the Bull machine to= print to laser printers around the LAN, instead of just the old serial p= rinters on the old proprietary servers.

An instant solution

While in the middle of putting up more servers, a communications line = went down. This was the line going to the proprietary servers. Instead of= using this as an excuse to put out more Linux servers, we chose to be pr= ofessional. This meant providing a quick solution. We put one of the crit= ical printers on a serial port of a win 95 box, shared it by SMB, then re= directed the Linux queue via smbprint. Of course, only Linux can both rec= eive the Bull print queue, and export an SMB queue; but the emphasis was = on providing a professional solution, rather than just advancing Linux. T= he rapidity of the solution made Linux look good anyway. We now have perm= ission to put up more Linux servers. It is in an atmosphere of profession= al competence, not radicalism. Linux looks better. We then replaced this = scenario with a dedicated Linux server, putting the printers on serial po= rts (ttySn) of an old 486 originally destined to be surplussed. JetDirect= boxes only handle parallel ports.

And now, make it smarter

In order to make it even more stable, we put in a script on the Bull m= achine, which sees if the print redirector is running. I sometimes use it= as a demo machine, and these units aren't on uninterruptable power suppl= ies. We are in a 160 year old building. Stable power is not a given. This= same idea could apply to different printers on JetDirect servers. If a p= rinter, server, network cable, hub, or anything else goes down, some prin= t queues could switch to a nearby printer, and keep on going. After all, = one of the reasons to use Linux is that it keeps on going under rough con= ditions.

#!/bin/sh

# shell script to find out what parts of the network are up.

# it would be run by cron every so often, for root.

# /etc/hosts.pup & /etc/hosts.pdown are identical,

# except for the IP address of pdirector.

# pprimary is the primary print redirector. psecond is the backup.

# /etc/hosts.pup has pdirector with the IP address of pprimary.

# /etc/hosts.pdown has pdirector with the address of psecond.

# Both pprimary and psecond are running 24x7, and have identical

# redirected print queues.

if { ping -c 1 pprimary >/dev/null }

then

cp /etc/hosts.pup /etc/hosts

else

cp /etc/hosts.pdown /etc/hosts

fi