[cups.bugs] problem with lpd reserve=on option

[Anonymous]

Michael Sweet wrote:
> Anonymous wrote:
> > ...
> > Why would the CUPS people deliberately choose the default of
> > reserve=no for this setting?????????? It had me stuffed for hours....
>
> First, because most network printers don't care about the source
> port - it was a shoddy excuse for security when LPR/LPD was
> developed, and it is a shoddy excuse for security now.
>
> Second, because users still insist on using LPD to talk to their
> printers, even when the (faster, more reliable, less error prone)
> printers support the socket or IPP methods, and since many users
> have more than 11 network printers the queues would get stuffed
> when they were all active (think traffic jam - only 11 jobs can
> get through at any given time)
>
> Third, the default setting is now "any" as of CUPS 1.1.21, so it
> will, by default, use a priviledged source port from 1 to 1023,
> which takes care of 99% of the remaining network printers and print
> servers that want a priviledged port but don't restrict it to the
> range of 721 to 731 defined in RFC 1179.
>
> Finally, the CUPS documentation has a whole section on LPD options.
>
> Michael Sweet, Easy Software Products           mike at easysw dot

Hi Michael
CUPS doesnt advertise itself as a network printer ONLY solution. Its quite legitimate to use CUPS to talk to a (legacy) LPD server on a NIX box.
Users have many reasons for maintaining these LPD streams (eg Accounting).
At any rate the job limit is 11 per network printer, not per user. You make it sound common to have more than 11 network printers. I disagree.
The *most* likely scenario is exactly one network printer. You deliberately stepped outside RFC 1179 because of performance issues.
This would be okay if you flagged this in some way, either with a run time failure or in big bold letters in the documentation. I had to refer to the "whole section on LPD options" to make a stab in the dark and fix this problem.
Nothing from the log files on the cups client indicated any problem with the ports being used. Most users would prefer a working system first and then address the performance issues later if they exist.
Proof of this logic is your modification of the default setting to 'reserve=any' in cups 1.1.21.

BTW If you have reserve=any does that mean the cups client will try to use a port in the range 1 to 1023?
Why dont you just try to follow the RFC first, then try alternatives in the case of failure?
If version 1.1.21 uses a port outside the RFC range while communicating to Mandrake 8 and its ilk, it will fail.

Adherance to any RFC, even if restrictive, helps massively in debugging.
It gives the user a frame work to test within. One of the many things I like about Linux is that almost all GNU inspired projects adhere to RFC's first and then give alternatives.

Also:
I looked for evidence of the originating port number in error_log on the cups client side and couldnt find it (loglevel=debug2).
Is it in there? Everything else seems to be!

Also:
When I create (using the command line lpadmin prog - the GUI should not be mentioned in polite company) the remote LPD printer, the printcap file that gets created bears little resemblance to the options passed to lpadmin.
If CUPS is running the whole (LPD backend) show, then why not create it to represent these options (eg rm= and rp=. I thought that this was actually causing a problem.
In the end I ignored the obvious differances between what I had specified and what was being published in /etc/printcap.

Last:
Thanks for the efforts of easysoft and for the cups product.
Something has to be done about the poor state of unix printing and its good to see there are people attempting it (especially after crap LPRNG).

Garth