problem with lpd reserve=on option

Anonymous anonymous at easysw.com
Thu Aug 25 22:44:13 PDT 2005


> Anonymous wrote:
>  > ...
> > 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.
>
> That is not my experience, and I have been doing UNIX printing since
> 1988.
>
>  > You deliberately stepped outside RFC 1179 because of
> > performance issues. This would be okay if you flagged this in some
>
> Not really performance, but usability.  When you have more than 11
> simultaneous jobs going, it is quite common for some jobs to be
> delayed for a very long time - this doesn't bog down the server,
> but *does* keep the job from printing which is an enormous problem
> for users who depend on printing.
>
> > ...
> > 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?
>
> Because in our experience our customers (the people that have paid
> for CUPS directly or indirectly) use more than 11 queues connected
> to printers and print servers which either want or do not want a
> privileged port.  Most do not require a privileged port, and of
> those that do less than 1% require a source port from 721 to 732.
>
>  > If version 1.1.21 uses a port outside the RFC range while communicating
> > to Mandrake 8 and its ilk, it will fail.
>
> Actually, no, since LPRng was used prior to CUPS, and LPRng does
> not depend on a privileged port.
>
> > 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.
>
> RFC 1179 is an informational RFC, not a standard RFC.  There is an
> enormous difference, and if you read it you'll notice that the
> author states that it merely documents the common implementation
> of the "LPD protocol" and does not define a standard.  Most network
> printers do not conform to the RFC (no copy support, no multi-file
> support, strange restrictions on the order of control commands and
> files, no formatting support, etc.), so the LPD backend has been
> developed and modified in order to work with the most devices
> possible out-of-the-box.
>
> > 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!
>
> You should see a debug message of the form:
>
>      [Job ###] Connected on ports ### (local ###)...
>
> > Also: When I create (using the command line lpadmin prog - the GUI
> > should not be mentioned in polite company) the remote LPD printer,
>
> Which GUI?  You mean the web interface?  Or ???
>
> > the printcap file that gets created bears little resemblance to the
> > options passed to lpadmin. If CUPS is running the whole (LPD backend)
>  > ...
>
> The printcap file that CUPS optionally creates is there solely for
> legacy applications that read it to get a list of available
> printers.  If you want the CUPS configuration file, look at
> /etc/cups/printers.conf, or use the appropriate commands or IPP
> requests.
>
> --
> ______________________________________________________________________
> Michael Sweet, Easy Software Products           mike at easysw dot com
> Printing Software for UNIX                       http://www.easysw.com





More information about the cups-devel mailing list