Re: apsfilter doesn't work on server

[Christian Ullrich <chris@xxxxxxxxxxxxx>]

* Christian Ullrich wrote on Tuesday, 2002-01-15:

> * Michael Loßin wrote on Tuesday, 2002-01-15:
> 
> > On 15-Jan-02 Christian Ullrich wrote:
> 
> > Which spooler do you use on those?
> 
> BSD lpd on the Server, LPRng on the client.
> 
> > Please try to use LPRng on server *and* client machines, since
> > the old BSD-style lpd has some problems with remote printing.
> 
> I'll try that ASAP.

Warning: The following is _very_ detailed. It took me three hours
to do it all and write it down. If there is _any_ information 
missing, please do not hesitate to ask.

Just as a reminder: The server is FreeBSD 4.4-RELEASE, the client
is SuSE Linux 7.3, using LPRng 3.7.4. The printer in question, 
connected to the server by parallel cable, is an HP LaserJet 1200,
which is PostScript Level2 capable, although it also supports PCL.
The problem in question is that, while printing on the server 
works just fine, printing from the client seems to bypass apsfilter.
The symptoms are:
- Text is printed with "staircase effect".
- PostScript is printed flawlessly.
- Anything else is not printed at all.

The following is an account of my adventures tonight. Steps 1 to
18 took place on the server, 19, 20 and 21 on the client.

1. I updated selected parts of the installed ports, nothing to do
   with printing or graphics or such things (but I thought I should
   include it here).

2. I moved /etc/printcap and /etc/apsfilter out of the way.

3. I moved all files in /usr/bin and /usr/sbin with names starting 
   with "lp" out of the way, provided they looked like parts of
   BSD lpd: /usr/bin/{lp,lpq,lpr,lprm} and /usr/sbin/{lpc,lpd}

4. I rebuilt LPRng-3.7.6 from the ports collection and installed it
   as it was built, without messing with the build directory.

5. I verified the settings in /usr/local/etc/rc.d/lprng.sh and found
   them to be in good order.

6. I built apsfilter-7.2.1, with the following options enabled:
   - A4 - A4 papersize
   - GS_NO_X11 - Postscript for non-PS printer, no X11
   - GS_PDF_CRYPT - print encrypted PDF files using gs
   - PSUTILS - for pseudo duplex printing + paper handling
   - A2PS - ASCII files in different styles/orientation
   - DVIPS - TeX DVI files
   - HTML2PS - HTML documents
   - TROFF - Troff documents
   - BZIP2 - print bunzip2 compressed documents
   On the first attempt to "make install" apsfilter, I was told that
   the file /usr/local/etc/apsfilter existed. It was a symbolic link
   to /etc/apsfilter, which I had renamed in step 2. I removed the 
   link and installed again. This time it worked fine.

7. I started the SETUP script and accepted the ownership of
   root.daemon for the spool directory /var/spool/lpd .

8. I configured a printer as follows:
   - Printer Driver Selection            [PS]
   - Interface Setup                     [parallel], via /dev/lpt0
   - Paper Format                        [a4]
   - Printing Quality                    [medium]
   - Color Mode                          [gray]
   - Print Resolution in "dots per inch" [600x600]
   - Default Printing Method             [ascii]

9. I printed a test page. Preparation took no time at all, printing,
   however, lasted 4:33. It is a complex page, after all, and the 
   HP 1200 seems to be slightly underpowered.
   
10. I installed that configuration under the name "ascii" and finished
    the SETUP script for the time being.
   
    This is the generated printcap (comments stripped):
   
    ascii|PS;r=600x600;q=medium;c=gray;p=a4;m=ascii:\
        :lp=/dev/lpt0:\
        :if=/etc/apsfilter/basedir/bin/apsfilter:\
        :sd=/var/spool/lpd/ascii:\
        :lf=/var/spool/lpd/ascii/log:\
        :af=/var/spool/lpd/ascii/acct:\
        :mx#0:\
        :sh:
	  
11. I started LPRng and found this line in syslog:

    Jan 15 20:41:02 ser1 checkpc[73259]: ascii: Checkwrite: fcntl F_SETFL 
                of '/dev/lpt0' failed - Operation not supported by device
				
	Similar output was generated by calling "checkpc -f". But sending
	data to the printer was never the problem, so I'm currently not
	much concerned about it.
	
12. I tried to print a simple text file ("lpr -Pascii /etc/printcap"),
    but lpq said this:
	
	Status: cannot open '/dev/lpt0' - 'Permission denied', attempt 2, 
		sleeping 20 at 20:48:37.238

    I removed the job ("lprm 337")
	
13. I checked the permissions on /dev/lpt0: root.daemon 660.

14. Trying to find out what user LPRng's lpd runs as, I read a lot
    of documentation in the build directory, only to find that it
	apparently setuid()'s itself to daemon.daemon, which ought to 
	work.
	
15. In order to test if this made it work, I changed the permissions
    on /dev/lpt0 to root.daemon 666, killed and restarted lpd, and
	tried again to print the text file. It worked, and the output 
	looked fine. The F_SETFL error message appeared again.
	
16. A cursory glance at the source code showed that LPRng perhaps
    does not -- as written in the LPRng-HOWTO -- set both uid and
	gid to daemon, but only the UID. In my case, it would then
	run as daemon.wheel, which can't possibly work.
	A less cursory glance at the output of "lpd -D4" showed that
	lpd does at least look up the correct GID of 1 for the
	daemon group.

17. I tested this idea:
    - chown chris.chris /dev/lpt0; chmod 660 /dev/lpt0
	  (myself, to make sure that neither user nor group match)
	  - "permission denied"
	- chown chris.daemon /dev/lpt0
	  (may be the correct group)
	  - "permission denied"
	- chown daemon.chris /dev/lpt0
	  (may be the correct user)
	  - worked.
	So lpd sets the documented uid, but another gid.
	
	Unfortunately, ps apparently can't find out the effective gid
	of a process, so I had to settle for the real one, which is
	0 (wheel). But that didn't tell me anything, of course.
	
	- chown chris.wheel /dev/lpt0
	  (the suspected gid of 0)
	  - worked.
	Obviously, lpd succeeds only in changing the uid, but fails
	at the gid (if it tries at all, that is).
	
	I set the ownership to daemon.wheel to make at least that work.
	
18. I checked the LPRng changelog. Lo and behold, it mentions that
    very bug as fixed in 3.7.6. Unfortunately, that is the version
	I installed. Let's blame it on a wrong fix. About time the LPRng
	port gets updated, the current release is 3.8.4.
	
19. Now for the client. Using SuSE's YaST configuration tool,
    I configured a simple network printer:
	
	ascii|remote printer on ser1:\
        :sd=/var/spool/lpd/ascii:\
        :rm=ser1:\
        :rp=ascii:\
        :bk:sh:mx#0:
		
20. "lpq -Pascii" on the client showed that the printer status was
    accessible.
	
21. "lpr -Pascii /etc/printcap" from the client produced the usual
    staircased text. Even an "ASCII only" apsfilter configuration
	on the server didn't work, and still doesn't. Because the printer
	stopped blinking, I'm sure that it got the text file directly,
	without apsfilter in between.

I'm out of ideas. What about you out there?

-- 
Christian Ullrich		     Registrierter Linux-User #125183

"Deliver."