AW: [Desktop_printing] Role of CUPS and error handling
Robert L Krawitz
rlk at alum.mit.edu
Thu Mar 30 05:40:21 PST 2006
Date: Thu, 30 Mar 2006 15:03:58 +0200 (CEST)
From: Johannes Meixner <jsmeix at suse.de>
On Mar 29 08:38 Robert L Krawitz wrote:
> From: Johannes Meixner <jsmeix at suse.de>
> On Mar 27 10:09 Michael Sweet wrote (shortened):
> > The main issue is that, out of the box, SuSE's web interface can't
> > work because there is no lppasswd set.
> Out of the box the cupsd must meet our general security policy. We
> have a perfect dilemma: You demand your defaults and we demand our
> general security policy but both contradict each other.
> From the standpoint of doing technical support for Gutenprint, I find
> that this raft of distribution-specific printer administration
> mechanisms causes no end of grief. I suspect that this is a headache
> for any companies that want to distribute their own printer drivers,
> The usual scenario is "I'm trying to set up Gutenprint using tool xxxx
> and it doesn't work quite right". We don't have the resources to try
> to debug all of the vendor tools (and yes, it's not uncommon that
> those tools at least contribute to the problem -- see my comment the
> other day about seeing multiple identical PPD files, when they should
> have been distinguished by language). At the same time, I don't think
> that most distribution vendors want to do tech support for prerelease
> versions of Gutenprint, or for the Epson Kowa drivers, or what have
> The upshot is that it's the end user who gets whipsawed here, unable
> to get support from anybody, because it's an integration problem that
> crosses organizational boundaries. That's not good for any of us.
When users test prerelease versions of Gutenprint they are root on
their system (i.e. no workstation user in a company where the
workstation was set up by an admin) and they are not unexperienced
users (because unexperienced users should not try prerelease
versions). When those users fail to set up a queue because they
don't know how to use lpadmin or the CUPS web-frontend of the
distibution which they have installed on their computer, I have no
idea how to really help those users. Don't think that I don't know
such users. I started to work at Suse in the support department and
I have a nice collection of several thousand answered support
Some people use prerelease versions of Gutenprint because they have no
choice for the printer they have. Gimp-Print 4.2.7 is about 2 years
old by this point. Blame us for our dilatory release process if you
like, but sometimes people don't have much choice.
> Let me say that I have more than just a little sympathy for SUSE
> maintaining its security policy. Security's difficult enough without
> trying to accommodate every quirk of every service. However, I don't
> think it's helpful for vendors to say "CUPS as configured out of the
> box doesn't meet our security needs, so we're just going to wash our
> hands of the problem and write our own custom interface".
> There's a variety of possible solutions here, everything from vendors
> (and KDE and GNOME, for that matter) agreeing to standardize on a
> common interface to CUPS to the distribution vendors appointing
> liaisons to each project that will handle tech support issues related
> to their distributions. But the current situation needs to be fixed.
> The summit is an ideal place to start working on that.
Regarding the whole posting:
I am afraid but I do not understand well what you exactly mean.
For me it looks as if you mix up printer config tool problems and
problems because of defaults in particular CUPS installations.
The problem here is that there's a standard CUPS interface (the web
interface). On most distributions it works, but on some it doesn't,
and it's very hard to know what does work and what doesn't. This
makes for confusion when trying to support users.
Regarding config tool:
Our default printer config tool YaST existed before we switched
to CUPS as our default printing system.
I assume you agree that we should not have simply dropped YaST
printer config and just forward the user to the CUPS web-interface.
No, I'm not suggesting that.
In particular not during the time when we supported both
LPRng/lpdfilter and CUPS.
We had even an automated migration from LPRng/lpdfilter to CUPS
and vice versa in YaST until Suse Linux 9.1
I hope you agree and understand that a smooth step by step move
from LPRng/lpdfilter to CUPS is better than leaving the user alone
how to switch his existing old config to a new printing system.
Furthermore YaST can set up a queue for many local connected
printer models in a full-automated way:
When a model is autodetected, a matching PPD file is
searched and if found YaST set up a queue.
Many local connected printer models are set up full-automated.
I hope you agree and understand that this is more user-friendly
than what the CUPS web-interface (CUPS 1.1.x) can do.
Finally YaST is translated into many languages. Much more than the
SUSE has never had a problem with i18n. I was using that as an
example (from a different distribution, as it happens).
Of course we kept YaST and did a smooth step by step move from a
LPRng/lpdfilter-only config tool via a LPRng/lpdfilter-and-CUPS
config tool to a CUPS-only config tool, for the history see
What exactly do you mean with "common interface to CUPS"?
A user interface to CUPS that works on all out of the box CUPS
YaST uses the CUPS API to set up queues.
Since Suse Linux 9.1 YaST uses only PPDs to set up queues (do not
confuse YaST with the Red Hat tool),
Exactly -- the proliferation of vendor-supplied tools, each of which
uses a different mechanism, creates chaos.
This means when you install any third-party software which installs
its PPDs into /usr/share/cups/model/ and which installs its filters
into /usr/lib/cups/filter/ it should work out-of-the-box with
If in the current YaST something is done regarding queue setup
which is not in full compliance how CUPS (1.1.x) is designed
to work, please tell me!
It is a crucial feature since Suse Linux 9.1 that YaST and other
config tools (e.g. CUPS web front-end) are synchronized, see
With "synchronized" I mean that you can use YaST and other
config tools in random order to add and/or change queues.
I know that YaST does not really support same PPDs in different
languages (i.e. YaST ignores the LanguageVersion entry).
That's a problem for us, since we have 18 languages. Certainly it's
possible to use --disable-translated-cups-ppds when configuring
Gutenprint; the result is that users get only English PPD files. If
you're ignoring the language version, then you're not completely
implementing the spec.
Usually it helps to toggel in YaST the manufacturer/model selection
to the plain PPD-file selection which lists the PPD files according
to the NickName entries but if the NickName is the same for PPDs
in different language, one cannot distinguish them.
We simply don't have the resources to handle all of the
distribution-specific exceptions. As I said, I run SUSE myself but I
don't use YaST to do printer administration.
Regarding defaults of a CUPS installation:
We let cupsd run as non-root in compliance how CUPS (1.1.x)
is designed to work.
If other config tools fail to work when CUPS runs in a
non-CUPS-default but CUPS-compliant mode, then there is a problem
in those other config tools. I am not talking about the CUPS
tools. Both lpadmin and the web-frontend work perfectly as CUPS is
designed to work: lpadmin works out-of-the-box when it is run as
root on localhost and the CUPS web-frontend works perfectly after
root has set up a user to be CUPS admin (via "lppasswd").
Your posting sounds a bit as if you want to get rid of any other
printer config tool except the CUPS tools and as if you want
that it is forbidden to run CUPS in any non-CUPS-default mode.
>From other postings of you I assume that I am wrong because
I think that you like the freedom of choice.
I do like freedom of choice, but I want to have a set of instructions
I can give users that will work on *any* CUPS installation unless the
end user has made an explicit decision to do something to the contrary.
Please have in mind what I wrote in my previous posts:
As far as I understand this discussion, it is about to agree
on a common standard but obviously any standard is ignored
when the common standard requires stuff which is not acceptable
by the policies or design guidelines or whatever guidelines
of the various parties (CUPS, the Linux distributors, KDE, Gnome).
As I said, I sympathize with your position on this, but it causes
Robert Krawitz <rlk at alum.mit.edu>
Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lpf at uunet.uu.net
Project lead for Gutenprint -- http://gimp-print.sourceforge.net
"Linux doesn't dictate how I work, I dictate how Linux works."
More information about the Printing-summit