Bug#704238: Need to document the CUPS client's new server-version option
On Fri, 2013 Jun 21 15:44-0400, Michael Sweet wrote:
>
> My experience with large sites has been the opposite - most places
> I've worked with have departmental print servers with manually-added
> queues (either raw queues or the OS X-style local queue/PPD forwarding
> to the server). They typically do not run all of the clients through
> a single print server because of performance issues, and use local
> PPDs to avoid hitting the print server every time someone opens the
> print dialog...
My site is admittedly not that large; we haven't had any trouble
pushing everything through a single print server, running on a machine
alongside other services. Yet we've seen benefits in standardizing on a
client-only setup, as administration becomes easier when you don't have
to deal with cupsd and all its moving parts on every desktop. This is
why I filed
https://bugs.launchpad.net/bugs/302272
(Same reasoning as why it's better to have one central SMTP smarthost
and dumb forwarders on each desktop, rather than a number of independent
mail queues that could each fail in multiple ways.)
> > Beyond that, it almost sounds likes CUPS as a whole is scaling down
> > into a local-only print infrastructure, that networked printing
> > support is no longer a goal. Is that really where things are going?
>
> Not at all.
>
> cupsd itself hasn't changed all that much. We dropped support for
> CUPS browsing (serious performance and scaling problems for large
> networks, and a huge power drain in mobile devices) and our ad-hoc
> SLP/LDAP schema (serious deployment issues) in CUPS 1.6 in order to
> re-wire things to better support large and mobile networking.
>
> At the client level, we changed the focus from a static list of
> printers provided by a single server to a dynamic list of printers
> provided by multiple servers - definitely large network stuff. Right
> now the dynamic lookup happens only with DNS-SD, but future versions
> of CUPS will also look things up via SLP and LDAP using the standard
> schema (again, large network stuff).
>
> Other future work: check out the IPP Shared Infrastructure Extensions
> on pwg.org; this will likely be supported by cupsd and solves many of
> the network/security barrier issues common in large networks.
>
> So no, we aren't focused on local-only print - that's all we had
> previously. We are now tackling large network/Internet printing and
> network mobility, something CUPS has traditionally been very bad at
> (thus hacks like client.conf and CUPS browsing).
This is all good to hear---I was a bit worried that LPRng or the like
was going to be the way forward for networked printing on Linux :]
I'm certainly open to alternatives to client.conf; all I really want is
the option of a client-server setup with a client that's no more
complicated than a dumb SMTP forwarder.
> > Documenting these directives is helpful, but how are users going to
> > recognize that an IPP version incompatibility is the problem in the
> > first place?
>
> Presumably the admins telling them (or configuring their system) to
> use the server will instruct them accordingly. Or perhaps run server
> software newer than 4 years old?
Admins are users, too. Some are all-knowing, some barely have the time
or wherewithal to deal with the afterthought that is the print server---
especially if it's been working fine for years and still works fine when
they try to print from their desktop.
> > How would they know that they should care what version of CUPS is
> > running on the server, when it's working perfectly well with older
> > clients?
>
> Presumably the users will know what the admins are telling them, and
> the admins will read the documentation?
My office runs CUPS 1.3.8 on the server. Even if my admin had the time
to read through the 1.3.8 docs, I don't think he would have found
anything helpful in there.
> > Right now, all they get is a generic and/or spurious error message
> > that isn't even good for a Web search.
>
> We tried doing auto-version-detection and that didn't work.
That's unfortunate; it would have been the best solution.
> Getting a Bad Request in lpstat/lpq and retrying with a 1.1 request to
> display an error telling the user to fix their configuration (!?!?)
> isn't particularly useful IMHO, and is more likely going to have users
> asking why the f**k we don't just do a 1.1 request in the first place.
I had to use a *protocol analyzer* to diagnose that problem. I didn't
know that the default IPP version had changed in 1.6, let alone that
that had anything to do with the "Bad Request" error. You may not think
the extra lpstat/lpq logic would be useful, but then, you live and
breath CUPS and already know what's going on. I do not, and from my
perspective, the extra logic and specific error message would have been
useful enough to save me hours of time investigating the problem, and
get printing working on the Ubuntu test system many weeks sooner than it
ultimately did.
As for users asking why not a 1.1 request, the error message can include
a URL to a document explaining this whole mess. You've already had to
explain a few times here why the obvious solution of auto-downgrading
the protocol doesn't work---you may as well answer that whole family of
annoying questions once and for all.
Reply to: