Subject: [netatalk-admins] PAP printing broke/fixed on RH 6.1

From: "Michael J. Flynn" <[email-masked]>
Date: Tue, 21 Dec 1999 22:17:34 -0500 (EST)

Hello-

I recently updated my RH 6.0 server to RH 6.1 and the printing was
broken. I look around for some answers on various FAQs about netatalk on
the net and found a solution. Since I was able to get the printing to
work again, I tend to think this is more of a lpr problem. Does anyone
have any ideas why I had to make this change? Are there settings I can
change in lpr so I can have the papd entry go back to it's original
entry? Thanks in advance for any tips.

This was the error message that was emailed to the root account on my
server:
> To: [email-masked]
> Subject: lp printer job "Banana Jr.:christmas_list.dtd"
> 
> Your printer job (Banana Jr.:christmas_list.dtd)
> was not printed because it was not linked to the original file

RPM of netatalk installed on my server is netatalk-1.4b2+asun2.1.3-2

Old papd entry for printer:
> HP DeskJet 600C:\
> :pr=lp0:op=root:pd=/etc/atalk/APLWNTR1.PPD

New papd entry for printer:
> HP DeskJet 600C:\
>         :pr=|/usr/bin/lpr -Plp0:\
>         :op=root:\
>         :pd=/etc/atalk/APLWNTR1.PPD

Laters

mike flynn - [email-masked]
The Company Store - http://www.magpage.com/~flynnmj/tcs.html

          Brought to you by <B>Team SPAM!</B> where we believe:
                   <I>"Information in the noise!"</I>

---

From: Jules Bean <[email-masked]>
Date: Thu, 23 Dec 1999 13:00:46 +0000 (GMT)

> entry? Thanks in advance for any tips.

AFAICT, the problem seems to be that lpd no longer listens on
/dev/printer, which is where papd sends its control messages.  I am unable
to work out why or when this change happened :-)

Jules
 
/----------------+-------------------------------+---------------------\
|  Jelibean aka  | [email-masked]         |  6 Evelyn Rd	       |
|  Jules aka     | [email-masked]              |  Richmond, Surrey   |
|  Julian Bean   | [email-masked]        |  TW9 2TF *UK*       |
+----------------+-------------------------------+---------------------+
|  War doesn't demonstrate who's right... just who's left.             |
|  When privacy is outlawed... only the outlaws have privacy.          |
\----------------------------------------------------------------------/

---

From: Mary Stracke <[email-masked]>
Date: Thu, 23 Dec 1999 10:56:50 -0500

Hi,

I've had a lot of problems with papd since I've switched to RH 6.1. 
At first, lpr didn't work at all, but that was fixed by upgrading to 
the newest lpr.  However, that didn't fix printing from the Macs.  In 
fact, printing now works erratically, fails most frequently with Macs 
running OS9.  Would you mind detailing how you got lpr back up and 
running.  I would be most grateful.

Mary Stracke

---

From: Sean /The RIMBoy/ <[email-masked]>
Date: Thu, 23 Dec 1999 10:46:00 -0600 (CST)

For the record, I have had RH boxes find lp on different /dev 's depending
on kernel / distro (on the same box).  lpd also seems to make a
difference. If it is working on /dev/lp1 and I upgrade (kernel or lpd) and
it stops, I switch it to /dev/lp0 and the problem corrects.  I cannot
figure out why this keeps changing.  It does stay stable until the next
time I upgrade one or the other.

My understanding is that /dev/printer should be a sym link to /dev/lpx.  I
would do

ls -la | grep /dev/printer

and see what it returns.  If it returns

/dev/printer 	blah	blah	 > /dev/lp1

or something to that effect, make a new link to /dev/lp0.  Or, do what I
do, skip /dev/printer and go straight for the device in your printcap.
fixing a 0 or 1 in printcap is easier (IMHO) than resetting the sym link
in /dev.  

> to work out why or when this change happened :-)

Sean...

Everything you know is wrong,
Just forget the words and sing along.    --Weird Al
===========================================================================
RIMBoy.com... Coming soon to a browser near you.
===========================================================================
Through the server, over the router, off the firewall... Nothing but 'Net!

---

From: "Michael J. Flynn" <[email-masked]>
Date: Thu, 23 Dec 1999 17:55:27 -0500 (EST)

> fixing a 0 or 1 in printcap is easier (IMHO) than resetting the sym link

Sean-

I took a look at the device files and /dev/printer is not a symbolic link
to an lp device. Doing a file on it also indicates that it is a socket
and not a character device. Have no idea why the file is a socket.

 [flynnmj@spam /dev]$ ls -ltr printer lp0
 crw-rw----   1 root     daemon     6,   0 May  5  1998 lp0
 srw-------   1 root     root            0 Dec 20 20:27 printer
 [flynnmj@spam /dev]$ file printer lp0
 printer: socket
 lp0:     character special (6/0)

Laters

---

From: Jules Bean <[email-masked]>
Date: Thu, 23 Dec 1999 23:55:07 +0000 (GMT)

> and not a character device. Have no idea why the file is a socket.

Because it's a socket that it's supposed to be!  Or at least, it's a
socket that papd expects it to be.  It's the socket by which papd says to
lpd 'Here you go, here's a new print job'.  On systems (like mine) where
lpd doesn't seem to listen on /dev/printer, this doesn't work, so I had to
shift to the 'lp=|lpr' approach.

If, on some distributions, /dev/printer is a link to one of the printer
devices, then that muddies the waters still further :-) It's no wonder
different people are seeing some different behaviours of papd..

Jules