[Printing-summit] [lsb-discuss] Printer/driver testing
jsmeix at suse.de
Tue Aug 22 03:43:04 PDT 2006
unfortunately it seems you made very clear that you won't accept
anything except "vanilla CUPS" i.e. you even won't allow anyone
who provides CUPS for someone else (e.g. a Linux distro but
perhaps also a big company who makes its own version of CUPS)
to use different defaults which implies that any other change
(e.g. a change in the code) is totally forbidden.
As this is against the ideas how free software should work,
any further discussion about this particular topic is futile.
I made clear that I expect from an reasonable standard
for free software that it allows changes but it must define
a standard-way how changes should be implemeted so that it is
clear for the user how a particular installation of a particular
free software works.
Unfortunately you posted wrong (or at least misleading)
information about our CUPS installation.
I am concerned whether or not it makes sense at all to discuss
such a topic (i.e. something which is related to policies)
in the public when it leads to wrong information about our CUPS
installation in the public which may let us and our company
look like idiots to unexperienced readers.
On Aug 21 15:17 Stark, Jens wrote (shortened):
> this one comes pre-broken from the distributor
Nothing was or is broken in our CUPS 1.1.
We use CUPS 1.1 as designed (but with different defaults).
> A good policy will not break existing functionality.
Our policy didn't break any functionality.
For a certain kind of functionality a different default was used
(digest authentication instead of basic authentication) which
means that there is no "root" access to the CUPS web frontend
by default but a "lppasswd" command is needed to activate it.
> "Thinking for/Protecting the customer for his own good" is
> synonymous for "patronising" in my book.
If a company policy requires "patronising", it will be done.
It doesn't help to be simply against whatever policy.
It only helps to learn how to deal with different policies.
> Do not castrate.
"Castration" is not reversible.
Our policy didn't break anything.
A deactivated functionality is not broken when it can be
> IF you need added security, ask the people who provide the
> software on how to work together on this.
RunAsUser is documented in the CUPS documentation as an
allowed way to run the cupsd and so we simply used it.
Also the digest authentication is documented in the CUPS
documentation as an allowed way to authenticate so we used it.
I am not aware of any information in the CUPS documentation
that RunAsUser or the digest authentication may have been
only there for very special purpose and should not be used
for normal printing operation.
And please have the history in mind.
Today we have CUPS 1.2 with nice SSL by default and a lot of
experiences about the problems with RunAsUser but when we made
our RunAsUser-decission (it was for Suse Linux 9.0) we made it
based upon what we had learned up to that time from the past
(i.e. from even longer ago).
> What I meant to say was :
> "Configuration data in CUPS should ONLY be in CUPS. Do not mirror
> it in your own config file/database."
This is exactly what YaST printer config does.
It works in full compliance to CUPS (if not, it is a bug in YaST).
It even works correctly if cupsd runs as non-root and/or
if digest authentication is used because it simply
runs as root on localhost.
> Yes, I basically speak AGAINST SuSEconfig style approaches
> (SuSEconfig only being ONE example) for CUPS.
SuSEconfig is not and was not used for CUPS because such
stuff would not be in full compliance to CUPS.
> Any user able to add his own binary/compiled drivers is not usually
> a support problem.
I was talking about unexperienced users who may download binary
drivers into their home directory (e.g. download binary drivers
form the web pages of printer manufacturers).
> But imagine a support engineer called to a corporate site
> with people using CUPS. As I mentioned before, these people
> will NOT usually be trained to work with one specifioc distro.
> They will expect vanilla CUPS to work.
There was never a problem to run the CUPS command line tools
"lpinfo" and "lpadmin" as root.
If authentication via CUPS web interface doesn't work out of the box,
a support engineer must know about CUPS digest authentication
via "lppasswd" because he cannot expect that "vanilla CUPS" runs
on the end-user's machine because digest authentication is a
perfectly allowed way to authenticate in CUPS.
> we can be glad if they know about CUPS at all
Then this "support engineer" is useless because he doesn't know
more than the end-user.
> If you break vanilla CUPS for ANY reason (yes, there are one or two
> worth discussing), you make printing much more difficult to support.
I assume "break vanilla CUPS" means "use different defaults".
Of course yes, various defaults make it more difficult.
But you seem to want that only "vanilla CUPS" is the one and
only allowed way to run CUPS which will definitifely fail
because run cupsd in CUPS 1.2 under whatever SELinux or AppArmor
or firewall or Solaris Zones restrictions is in compliance
to CUPS 1.2 so that the poor support engineer will now have
to know about "lppasswd" + SELinux + AppArmor + Solaris Zones.
> Mike Sweet makes the rules on how printing is supposed to work.
An one of his "rules" in CUPS 1.1. was the RunAsUser mode
and another "rule" is the digest authentication.
> System administration and configuration is one of the major points
> where distros differ.
Because this is the major work of distros (i.e. make the installation
and configuration stuff).
> >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" :)
Because this is/was really a bug and not just a different default.
> >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 ! :(
And this is a good example what I try to tell you all the time:
Instead of simply forbid any changes and/or any differences,
better let us think about how to deal with changes and differences
because they did happen they do happen and they will happen.
> >Both "by the ways" are examples what to have in mind when a
> >common specification is set up.
> >Explicitely list the allowed (and known forbidden) possibilities.
> >Advise how to implement special defaults / special policies
> >and special restrictions.
> YEP ! :)
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