Re: apsfilter doesn't work on server

[Michael Loßin <phallobst@xxxxxx>]

On 15-Jan-02 Christian Ullrich wrote:
> 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..6: LPRng 3.7.6 and apsfilter 7.2.1 installation]

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

Since you are using LPRng (and SETUP calls checkpc), this
is okay -- just a quick reminder.

The original BSD-lpd used root.daemon, but LPRng usually
has daemon.daemon (or lp.lp), but checkpc corrects that.

> 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.

The test page is already PostScript, no there's nothing to
prepare... :^)

BTW: This shows something slightly confusing in SETUP:
Although the printing method is "ascii", we print a
PostScript page anyway... Maybe we change to a text-only
test page for this case in the future.


[10: printcap entry is okay]

> 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.

LPRng CHANGES file:

| Release LPRng 3.7.7 Fri Sep 14 15:54:48 PDT 2001

| checkpc whooped its cookies when running checkpc -f and
| the device is /dev/null (lp=/dev/null).   Apparently I
| cannot set /dev/null to use blocking IO...  Sigh...  So I
| do not count 'changing non-blocking IO to blocking IO'
| as an error.

Apparently the same thing happens here with /dev/lpt0 under
BSD (fcntl with F_SETFL is used to set blocking IO).

> 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")

Too bad checkpc can't set the permissions, since the device
might also be /dev/null (which must not be changed).

But maybe it should check if the device is sufficiently
accessible...

> 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-17: but it doesn't 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.

LPRng CHANGES file:

| Version LPRng-3.8.1 - Thu Nov 15 16:08:41 PST 2001

| Grrr... left in a line of code when I was doing some testing of the
| setuid functions in Win32 and screwed up the setuid stuff.

Life's a bitch :^)

> 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.

Did it show the status of the queue on the client or on the
server? (Both are called "ascii"...)

> 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?

Same with me... :(

There's of course the possibility to do all filtering
on the client, but that's not what you (and we) want.

I don't know if the debug output from LPRng ("lpr -D1 ..."
or -D2, -D3, ...) is helpful, but you could check if there
are suspicious lines.

Does LPRng need a ":filter=..." line in /etc/printcap instead
of (just) ":if=..."? AFAIK the "if" filter is the default,
but maybe adding ":filter=/etc/apsfilter/basedir/bin/apsfilter:\"
helps.


Maybe those people with a *working* printer server could
post their settings, spooler config etc. I have no idea what
goes wrong here...


Michael