AW: [Desktop_printing] Role of CUPS and error handling
ptykodi at tykodi.com
Thu Mar 30 06:01:21 PST 2006
I believe that your current posting is an excellent prelude to the upcoming
printing summit because for me it captures in a single posting what I
believe is the single most important issue, which needs to be addressed in
the Linux printing space.
That issue would be the tenet that Linux is first and foremost about choice.
For me, I believe that currently the focus on openness and choice has
greatly obscured the desire on the part of the majority of the Linux end
user community to have a simple path for telling the OS (and by extension
associated software components) that a printer is being defined to the
As I have interpreted your posting, you are explaining in significant detail
how SuSE has provided a series of independent component software products to
its community of users in support of their wish to define and use a printer.
You also seem to be suggesting that SuSE has supporting documentation to
show that in all cases SuSE has diligently followed the software provider's
recommendations for installation steps whenever possible.
The result in my opinion is that Linux printing currently mirrors our world
Depending upon any individual person's level of user permission, Linux
skill, printing hardware, backend selection (i.e. parallel, serial, USB,
firewire, network, etc.), and printing related software selections the
following is probably true:
- YaST might work or it might not
- CUPS configuration tools might work or they might not
- Other spooler configuration tools might work or they might not
- Linux system security settings might allow you to configure a printer or
they might not
When Linux Printing support is then compared to the printing support in
other prevalent desktop OS's (Apple & Microsoft OS Products) a major
difference is typically noticed almost immediately by the end users I
encounter. The other OS vendors have taken steps to improve the possibility
an attempt to install a printer will most always succeed. The end users I
encounter typically suggest to me that they like having the printer setup
odds skewed in their favor.
My comments are specifically targeted at the process of getting the initial
printer definition created under Linux correctly and not the follow on
configuration of the driver and filters to provide the result needed by any
particular user (to me a much different issue).
So for me the question regarding Linux printing and its acceptance by a much
broader cross section of users would be - Does the community of Linux
Distribution providers and printing software component developers believe
that skewing the printer installation process towards a high level of
success would be good thing for their software and for Linux as a whole?
TCS - Tykodi Consulting Services LLC
E-mail: ptykodi at tykodi.com
> Date: Thu, 30 Mar 2006 15:03:58 +0200 (CEST)
> From: Johannes Meixner <jsmeix at suse.de>
> Subject: Re: AW: [Desktop_printing] Role of CUPS and error handling
> To: desktop_printing at lists.osdl.org
> Message-ID: <Pine.LNX.4.58.0603301239010.10962 at wotan.suse.de>
> Content-Type: TEXT/PLAIN; charset=US-ASCII
> 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
> 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
> 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 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
> 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