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

Stark, Jens Jens.Stark at seeg.sharp-eu.com
Tue Aug 22 04:54:14 PDT 2006

Johannes wrote:

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

[Again, my complete post is personal opinion, not official company policy]

Indeed, it is - so let's concentrate on different issues.
>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.

On this, we can agree.

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

I never said anything that should lead people to believe that.
I can assure you that my opinion on SuSE in general is high - we just have =
different opinions on ONE topic, which would not even be worth mentioning i=
f we had clearer standards in place. Can we agree on that one ? =

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

Matter of definition - but again, not worth any further discussion.

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

[I keep myself from discussing this - it will not really bring us anywhere]

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

History. Let me apologize for bringing it up and be done with it ? :)

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

So SuSE did the right thing - no problem there, as this IS indeed the defau=
lt behaviour...

>> Any user able to add his own binary/compiled drivers is not usually
>> a support problem.

>Why not?
>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).

Sorry. My limited scope in this area. My usage scenarios usually involve tr=
ained EDP staff,
which might or might not have a Linux expert on staff. We also usually rele=
ase PPDs, not binary drivers, so my experience is a bit biased. =

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

...which require a bit more training...

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

As soon as there is a standard, if there is one, we will know what to train=
So far, we go with the majority and consider a default configuration.

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

Stop right there. These support engineers are often highly trained experts =
in THEIR field.
They are not, and will never be, SuSE Linux support engineers. =

I would not ask any SuSE supporter to (as an example) do something as simpl=
e as to remove the cause for a paper jam or to work on fine tuning a high e=
nd color laser. When I changed fields from computing and networking to mult=
ifunction machines, I expected slower technical progress in that field. Com=
mon misconception - things change rapidly here, the stress on support engin=
eers to keep up with new models is considerable. Someone trained on any Lin=
ux distribution from 2000 will easily be able to support a current one. The=
 changes from a Y2K MFP to today's model are drastic - similar to changing =
from Windows 3.11 to XP Pro - or to stay within the Linux world, from SLS t=

About 8 years ago, MFPs were not even networkable. Nowadays (and we are sti=
ll talking about the same people), these beasts usually are. They print, sc=
an, fax, store documents - all within a network context. Someone who "grew =
up" on clutches, polygon motors and developers, plus glass plates, mirrors,=
 motors and all this stuff is now supposed to know about printing in Window=
s, Mac OSX and possibly some others, too. Also new for them were topics lik=
e TCP/IP, working with FTP, LDAP, SSL, X.509 certificates, data security, a=
uthentication on SMB servers (often the original), electronic mail and mail=
 servers, the peculiarities of Ethernet, printer autodiscovery, snmp and ma=
ny other topics. All this in addition to their day job, so to speak. In a r=
apidly evolving environment. =

I would not want to ask them to support every single Linux distro there is.=
 Okay - there is some bias towards certain distros (SuSE in Germany, others=
 in other countries), but as a manufacturer, you should be able to support =
them all. So you hope that nobody makes your life more difficult than possi=
ble.  =

So please understand their situation - it is as if I would claim that peopl=
e producing Linux distros just sit there, waiting for packages to appear, t=
o copy them together and burn CDs :)

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

IF it becomes a trend worth following from a commercial point of view.
How much business would we lose if we just didn't care ? =

>> >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 ! =


You are very welcome :)


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

This appears to be the better approach...

>> >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 ! :)


Absolutely. We just have the best interest of our employers in mind.
I am worried about what to tell people to learn, you are worried about prov=
iding a safe environment for your users. Users, however, just want it to wo=
The last group is one thing we have in common, so their interests should al=
ways be top priority. And I believe that the people who provide distros and=
 the people who manufacture printing hardware will find a way to please the=
 majority of users - and us.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.linux-foundation.org/pipermail/printing-summit/attachment=

More information about the Printing-summit mailing list