AW: [Desktop_printing] Role of CUPS and error handling

Robert L Krawitz rlk at
Thu Mar 30 05:40:21 PST 2006

   Date: Thu, 30 Mar 2006 15:03:58 +0200 (CEST)
   From: Johannes Meixner <jsmeix at>

   On Mar 29 08:38 Robert L Krawitz wrote:
   >    From: Johannes Meixner <jsmeix at>
   >    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,
   > also.
   > 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
   > you.
   > 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
   requests ;-)

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
   CUPS web-interface.

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[64]/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
other problems.

Robert Krawitz                                     <rlk at>

Tall Clubs International  -- or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lpf at
Project lead for Gutenprint   --

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton

More information about the Printing-summit mailing list