AW: [Desktop_printing] Role of CUPS and error handling

Johannes Meixner jsmeix at suse.de
Thu Mar 30 05:03:58 PST 2006


Hello,

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,
> 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 ;-)

> 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.


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.

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.

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
http://en.opensuse.org/SDB:Printer_Configuration_from_SuSE_Linux_8.1_on
http://en.opensuse.org/SDB:Printer_Configuration_from_SuSE_Linux_8.2_on
http://en.opensuse.org/SDB:Printer_Configuration_from_SUSE_LINUX_9.0_on
http://en.opensuse.org/SDB:Printer_Configuration_from_SUSE_LINUX_9.1_on
http://en.opensuse.org/SDB:Printer_Configuration_from_SUSE_LINUX_9.2_on

What exactly do you mean with "common interface to 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), see
http://en.opensuse.org/SDB:Printer_Configuration_from_SuSE_Linux_8.2_on
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 YaST.

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
http://en.opensuse.org/SDB:Printer_Configuration_from_SUSE_LINUX_9.1_on
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).
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.


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.

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).
-------------------------------------------------------------------


Kind Regards
Johannes Meixner
-- 
SUSE LINUX Products GmbH, Maxfeldstrasse 5      Mail: jsmeix at suse.de
90409 Nuernberg, Germany                    WWW: http://www.suse.de/



More information about the Printing-summit mailing list