![[ TABLE OF CONTENTS ]](../gx/indexnew.gif)
![[ FRONT PAGE ]](../gx/homenew.gif)
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.
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.
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.
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.
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.
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