[Printing-summit] [lsb-discuss] Printer/driver testing andcertification

Stark, Jens Jens.Stark at seeg.sharp-eu.com
Mon Aug 21 06:17:13 PDT 2006


Johannes wrote: (shortened)

>> So my requirement would basically be :
>> "Whatever tools are offered for printer setup/maintenance in a system
>> supporting CUPS, the CUPS web interface and the CUPS command line
>> interface must work out of the box and provide full functionality.". =


>A company policy may simply forbid it.
>The "company" can be a distro which must use special restrictions
>by default to protect their customers or it is the company where
>an end-user works which enforces special restrictions how the
>workstations are set up.

One reason to boycott a distro :)
This has been reiterated over and over again - and it's up to the customer =
to decide on the level of security he wants. "Security features" BREAKING f=
eatures without AMPLE warning are a BUG. Most users who care enough to fix =
this might as well use an editor and "repair" the cupsd.conf file by themse=
lves - by disabling all security whatsoever. We all know that SuSE's positi=
on on this is not GENERALLY accepted - and I wii refrain from using the N w=
ord here :)
The minimal complaint is that it is badly documented and creating a support=
 nightmare.
(Having a FAQ on the CUPS main page for one's distro alone would make me th=
ink :) )

If the CUSTOMER breaks it - HIS problem. But this one comes pre-broken from=
 the distributor, even if the manufacturer provided working goods. I will e=
laborate further down, please be patient :)

>Please don't get me wrong.
>I am not against a common specification but I want to make it
>very clear to you that a common specification is dead before
>it is made public if it doesn't allow special policies or
>restrictions.

A good policy will not break existing functionality. "Thinking for/Protecti=
ng the customer for his own good" is synonymous for "patronising" in my boo=
k. Educate, if needed. Offer the choice. Do not castrate. IF you need added=
 security, ask the people who provide the software on how to work together =
on this.

>> Let me add a second one: "In a system runbning CUPS, all printer
>> configuration and setup info must reside within CUPS."

>Since CUPS 1.2 this is impossible (according to what you mean
>with "all printer configuration" - e.g. full functional web
>interface for admin stuff) because according to what I remember
>what Michael Sweet recommended the RunAsUser-mode can be "replaced"
>by SELinux or AppArmor settings and those are outside of CUPS.

>[different not-all-in-cups scenarios]

Maybe I was a bit ambiguous. :)

What I meant to say was :
"Configuration data in CUPS should ONLY be in CUPS. Do not mirror it in you=
r own config file/database."

Yes, I basically speak AGAINST SuSEconfig style approaches (SuSEconfig only=
 being ONE example) for CUPS. Yes, it might make things easier in a number =
of ways, but please understand that ANYthing non-cups makes printer support=
 much more difficult. Any user able to add his own binary/compiled drivers =
is not usually a support problem. But imagine a support engineer called to =
a corporate site with people using CUPS. As I mentioned before, these peopl=
e will NOT usually be trained to work with one specifioc distro. They will =
expect vanilla CUPS to work. And looking at their job scope, they will spen=
d most of their time doing non-Linux stuff and we can be glad if they know =
about CUPS at all. If you break vanilla CUPS for ANY reason (yes, there are=
 one or two worth discussing), you make printing much more difficult to sup=
port. Sorry - but in my book, Mike Sweet makes the rules on how printing is=
 supposed to work. Think of his decisions what you want, but I'd rather not=
 bother with non-standard CUPS. And he is making a living from corporate pr=
inting.  =

A manufacturer cannot afford to discuss exemptions with far too many distri=
butions. System administration and configuration is one of the major points=
 where distros differ. May of them take rather good and clever decisions. F=
rom their point of view. If there was one "best" solution, most rational pe=
ople would use it. (Sorry, there are almost no rational decisions in life..=
.) The manufacturers have their OWN point of view. They say (basically) "Wi=
ndows is more or less Windows, so Linux should be basically Linux".

>By the way 1:
>Both the Gnome and KDE printer admin tools had/have the problem
>that they couldn't work as root on localhost and therefore they
>simply failed for CUPS 1.1 when it runs in RunAsUser-mode (which
>is one allowed mode to run CUPS 1.1).

This is called "broken" :)

[...]
>If there was a LSB specification about CUPS 1.1, it might have
>been more clear that RunAsUser-mode is either an allowed mode
>or a forbidden mode (e.g. only for debugging purpose).
>If RunAsUser-mode was not allowed according to LSB we wouldn't
>have used it by default because we want to be LSB compliant.

Definitely a good point ! =


>By the way 2:
>Some weeks ago - just when Suse Linux 10.1 was finished - my brain
>seems to have had some some free-time and I found the right solution
>how we should have implemented our default-RunAsUser-mode:
>We should have changed the CUPS web pages so that the [Admin] link
>would have pointed to an additional intermediate page (made by us)
>which explains the RunAsUser-mode to the user and on this page
>there would have been a link to the actual admin page.
>This would have made sure that every user of the CUPS web interface
>knows about our default-RunAsUser-mode because it didn't help to
>have it documented in our release-notes and in our manual and in
>our support database (and it wouldn't have helped to have it
>documented in the CUPS documentation).
>I have no idea why I didn't find this simple solution before.
>Now (i.e. after 10.1) it is ultimatively too late :-(

AAAARGH! Pity. Would have solved everything for everybody ! :(



>Both "by the ways" are examples what to have in mind when a
>common specification is set up.

>1.
>Explicitely list the allowed (and known forbidden) possibilities.

>2.
>Advise how to implement special defaults / special policies
>and special restrictions.

YEP ! :)

Best,
   Jens
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.linux-foundation.org/pipermail/printing-summit/attachment=
s/20060821/2dfee28b/attachment.htm


More information about the Printing-summit mailing list