[cups] cups-lpd performance and scalability?

Mon Aug 24 07:21:34 PDT 2015

In regard to: Re: [cups] cups-lpd performance and scalability?, Rick...:

> I have not used cups-lpd in the past, but am thinking of using it with 
> PaperCut in the future.

Hi Rick!

We're actually using the *other* managed printing solution from ITC --
GoPrint.  ITC bought GoPrint last year, so now they have two products
that do virtually the same thing.  I'll be interested to see what their
product offerings look like in a couple more years...

> I plan to use a Windows print server for authenticated (Kerberos and NTLM2) 
> printing from Windows clients.
>
> I plan to use a Linux CUPS print server for authenticated (IPPS)
> printing from OS X and Linux.

We've been using a Linux LPRng server (and the LPD protocol) for spooling
from both Windows and Mac systems for years and years -- ever since we
deployed GoPrint on our campus.  I've been trying to get us off LPRng and
on to cups for a long time.

It's not that we don't care at all about authenticated printing, but
in the model we're using, "authentication" happens when the student
uses their ID card at a print release station, so charging happens
against the ID of whoever releases the jobs, not whatever username is
in the job control file.  I understand that there could still be
shenanigans with spoofed data in a job and it's pretty easy to spoof
the username for things like deleting held jobs, etc.  That hasn't
really presented us with any problems, though.

> That leaves unauthenticated printing (authentication would be provided by the 
> PaperCut popup client).  I am thinking about using cups-lpd for that for 
> Windows, OS X, and Linux.
>
> I am happy to hear from Michael that the scary performance notes in the 
> cups-lpd documentation have been addressed.  Perhaps the documentation could 
> be updated.

I was going to offer to provide a patch for that, if it turned out the
man page was just way out of date.  After seeing Michael's response,
I don't really know what I should change, though.

It would be nice to see some real world numbers from someone that's
already using cups-lpd, but it's such a "stop gap" that I imagine most
sites have gotten rid of the need for it long ago.

> The other problem with cups-lpd is that unless I am mistaken it will
> allow LPD clients to bypass any authentication requirements for all
> queues on the server.

I understand that might be a big problem for some environments, but
because of the release model we're using, it's pretty much a non-issue
in my particular environment.  We don't care who submitted the print job;
we only care who's ID card was scanned at the release station where the
jobs were released.

>  I am thinking of dedicating a separate server for
> this purpose.

As part of the trouble we're having with Mac clients, we've already set up
a separate server for Mac printing.  That gives me some room for
experimenting with different things, like newer cups, cups-lpd, etc.

> I have not had any problems submitting print jobs from Yosemite to our RHEL 6 
> CUPS 1.4.2-67 server.  (Note that Red Hat package version numbers bear little 
> relation to the version numbers for the source of the packages.)

Agreed about the versioning, and it's very interesting to hear that you're
not having problems with the slightly newer version.  Since I went through
the work of setting up a clone of our RHEL 5.x print server last Friday
to try using it as a separate server for just Macs, it may be worth it
for me to re-kickstart it as RHEL 6 (or 7), to see if we can replicate
your success.

> Finally, I am surprised to hear that you have you are switching your Windows 
> printing to IPP.

We're switching *from* LPD, so IPP is still a step up.  Our campus print
server has been Linux-based and stuck on LPRng for a long, long time.

>  I have heard that Microsoft's support for IPP is not 
> "mainstream" and will not be as robust as their support for their native 
> protocols.  Also, if you are using "version 4" or "class" print drivers
> (which seem to be a vast improvement over "version 3" drivers) OS X
> clients will be unable to print to your server because of "print job
> format" incompatibility.

You completely lost me on this last bit.  Are you talking specifically
about a Windows-based print server?

Thanks much for your response!  You've given me several good data points
to consider.

Tim

> On 8/22/15, 7:32 PM, Tim Mooney wrote:
>> 
>> All-
>> 
>> I've downloaded the cups mailing list archives and spent quite a bit of
>> time grepping them for anything related to cups-lpd, but I don't see where
>> the question I have about cups-lpd scalability has been addressed before.
>> 
>> Because of the problems we've run into with Macs running Yosemite not
>> being able to submit print jobs to our cups 1.3.7 print server via IPP,
>> as described in these threads:
>>
>>          http://www.cups.org/pipermail/cups/2015-August/027009.html
>>          http://www.cups.org/pipermail/cups/2015-August/027012.html
>> 
>> We're therefore exploring enabling cups-lpd, so Macs and any other systems
>> that can't do IPP 1.1 can submit print jobs to our cups 1.3.7 server.
>> 
>> The cups-lpd PERFORMANCE section has some pretty dire warnings about
>> cups-lpd not scaling, though.  However, web searches I've done for
>> "cups-lpd performance" have turned up
>>
>>          https://bugzilla.redhat.com/show_bug.cgi?id=132949
>> 
>> which leads to this CUPS STR:
>>
>>          http://www.cups.org/str.php?L804
>> 
>> That implies that a lot of the original cups-lpd performance issues were
>> resolved in the 1.2 series when cupsGetDests() was improved.
>> 
>> Does that mean that the performance warnings in the cups-lpd man page
>> are (somewhat) out of date?
>> 
>> Does anyone have any idea how cups-lpd scales, when used in a mixed
>> IPP and LPD protocol environment?  We've converted our Windows labs to
>> use IPP exclusively, so the majority of jobs submitted to our print server
>> would be via IPP.  If cups-lpd is still a poor performer, though, we don't
>> want to enable it and cause problems for IPP job submittal too.
>> 
>> Thanks much for any information you can provide!
>> 
>> Tim
>

-- 
Tim Mooney                                             Tim.Mooney at ndsu.edu
Enterprise Computing & Infrastructure                  701-231-1076 (Voice)
Room 242-J6, Quentin Burdick Building                  701-231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164