On Thu, 2007-03-01 at 10:04 +0100, Ludwig Nussel wrote:

JP Rosevear wrote:

...

1) Detecting a local USB printer when plugged into the machine and prompting the user to configure it or automatically selecting a driver and configuring the printer [...] 2) Not needing root to configure a printer

Why do printers need a special case? It's just some piece of hardware that can be plugged in at run time. Ideally there is a (default) driver so it's possible to configure the hardware automatically in the background and the user won't notice. If you need any interactive input (ie YaST) to configure a device you need to authenticate[1] as root. That barrier does not only avoid accidential privilege escalation, it also prevents users from thoughtlessly doing something that can harm the system. You need to authenticate only if you plug in the hardware the first time anyways. One likely does not plug in a different printer, scanner, tv card etc every day.

They don't need to be a special case, I suggested a couple of ways we could generalize this for hardware. One good use case we've seen with customers is that they don't want to give out the root password because that would enable users to do anything they want like update packages.

...

3) Detecting when a printer is connected/disconnected and offering visual feedback via a notification area icon, or some other ui feedback

There should be no special case for printers. You want that for any hardware. Like e.g. a well known popuplar OS tells you "the XYZ device is ready to use now" (or whatever the exact wording is). In case of a printers I'd expect tools like kprinter to already visually indicate if a queue is disabled which is unrelated to whether the hardware is actually available.

I'm talking of specialized device info, not simple existence. Yes, you can poll for the status, but a straight forward message on the bus allows a number of applications to receive pushes rather than pull the info.

...

4) Ability to remove printers from cups (even shared printers) when they're unplugged to prevent jobs from accumulating in the queue or being default

I think it's a valid use case to queue a printjob and have it printed when the printer is connected again.

Its a valid use case not to want to do this either, which is why it should be configurable. -JP -- JP Rosevear Novell, Inc. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ludwig Nussel schreef:

JP Rosevear wrote:

...

One good use case we've seen with customers is that they don't want to give out the root password because that would enable users to do anything they want like update packages.

What specific part of printer configuration should a user be able to do without authentication? Demanding that users must be able to "configure printers" without knowing the root password is too coarse grained. AFAICS the YaST2 printer module for example offers to reconfigure the firewall and to install additional packages when needed also as part of printer configuration.

cu Ludwig

This might than also be the cause why a printer can not be found in the network? 10.3alpha0 can not even detect a parralelle printerport, when the printer is plugged in. He guys, wake up! Configuring the printer needs just the printer drivers, the way you want to have it printed, must be accessible from any app. Not needing any password.. - -- Have a nice day, M9. Now, is the only time that exists. OS: Linux 2.6.18.2-34-default x86_64 Huidige gebruiker: monkey9@tribal-sfn2 Systeem: openSUSE 10.2 (X86-64) KDE: 3.5.5 "release 45.2" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFF5rCDX5/X5X6LpDgRAhnDAKDIT3lH5m0X06NIbnf9cPTqtq4BqwCglIeD 5CRAv6hyfkGgPYLM36Jluac= =KH3C -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2007-03-01 13:35 +0100, M9 wrote:

-----BEGIN PGP MESSAGE----- Charset: ISO-8859-15 Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

hQIOA/E8+Y9nFZR0EAf/YeEfYvt2amLhhj7E4ni/t/yTIWnkMr0o1DswSusOs7a2 n6scwb9xCRmMj43xJBVbcO0vpVviJX/7D1u6wz9A1C3ibrfmCT4qESSwrmpD2cyv

Would you care to decrypt, please? Unless it is a secret, of course :-P - -- Cheers, Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFF6CamtTMYHG2NR9URAokRAJ92yC8vkI9+/oF+nMIhjvkrN3loJQCdGXpH OzeKUG5iAoO1OQYogTOqxpw= =LBhH -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sid Boyce schreef:

Carlos E. R. wrote:

...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 2007-03-01 13:35 +0100, M9 wrote:

...

-----BEGIN PGP MESSAGE----- Charset: ISO-8859-15 Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

hQIOA/E8+Y9nFZR0EAf/YeEfYvt2amLhhj7E4ni/t/yTIWnkMr0o1DswSusOs7a2 n6scwb9xCRmMj43xJBVbcO0vpVviJX/7D1u6wz9A1C3ibrfmCT4qESSwrmpD2cyv

Would you care to decrypt, please? Unless it is a secret, of course :-P

- -- Cheers, Carlos E.R.

All swear words, no deleted expletives, so encrytion saves him from prosecution. Come in M9. Regards Sid.

Thought so.... it was me.... again... Was testing 10.3A0+, on 586, and as i upgraded the systen from 10.2RCfinal trough the net, also thinderbird got upgraded, with a new pgp module, which is (?) incompatible with the old one.. Can not even read my own posts on the other machines...(lol) And the old module can not import the keys, so, i just switched it off. ( after discovering that it was impossible to read) Btw. did anyone got the key imported?

- -- Have a nice day, M9. Now, is the only time that exists. OS: Linux 2.6.18.2-34-default x86_64 Huidige gebruiker: monkey9@tribal-sfn2 Systeem: openSUSE 10.2 (X86-64) KDE: 3.5.5 "release 45.2" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFF6FPCX5/X5X6LpDgRAs16AJ9CGFBa2q+9WDKZcLKQWrzEeoC/PQCgm6Js NS0h2d3c0d8XVA4tzZ9q7CA= =ov6t -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Friday 2007-03-02 at 13:55 -0500, Patrick Shanahan wrote:

...

Btw. did anyone got the key imported?

For an open mailing list??? You waste my time!

Precisely for an open mail list! You haven't been hit by an impersonating trickster on a list, no? I was, that why I always sign. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFF6H+ItTMYHG2NR9URAqcUAKCVJlkBmW8q8WL3aVHDaYU9+C+GZgCfUTLy 4MxO1VGxo0fh/JY0ipixG8w= =KOwm -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Friday 2007-03-02 at 20:54 +0100, M9. wrote:

Patrick Shanahan schreef:

...

* M9. [03-02-07 11:44]: [...]

...

Btw. did anyone got the key imported?

For an open mailing list??? You waste my time!

Well fuck you than... ;-)

Please, please! Don't start insulting, please. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFF6IOZtTMYHG2NR9URAqhnAJ4r4TbZ5WrqUyZGQDDLtq60p3V36wCfSyYa MmwclY9KipkvBvr/OI9RJhs= =njt9 -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Carlos E. R. schreef:

The Friday 2007-03-02 at 17:41 +0100, M9. wrote:

...

Btw. did anyone got the key imported?

Yes, but from the previous email:

| gpg: Signature made Thu 01 Mar 2007 11:52:51 AM CET using DSA key ID 7E8BA438 | gpg: Good signature from "Monkey 9 "

which is the same signature you use today:

...

gpg: Signature made Fri 02 Mar 2007 05:41:38 PM CET using DSA key ID 7E8BA438 gpg: Good signature from "Monkey 9 "

If you mean the key for the encrypted message, no obviously not. Only the recipient of the encrypted message can read it - not even you, unless you also encrypted to yourself.

These mails come from different machines... The mail sent from the 32bits, SuSE103A0+ i can not read on my 64bits, 102Final.. And i imported the key, but am not able to use it. Not yet have the time to look into it.. This key is also at the keyservers.... - --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org - -- Have a nice day, M9. Now, is the only time that exists. OS: Linux 2.6.18.2-34-default x86_64 Huidige gebruiker: monkey9@tribal-sfn2 Systeem: openSUSE 10.2 (X86-64) KDE: 3.5.5 "release 45.2" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFF6IJnX5/X5X6LpDgRAqRqAKCnKgMJQyFcY0o+V1RE6riaMwQmEQCgqYz2 MQAqhFSvp9U+CUD0j8f1Gzk= =Hl6q -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

JP Rosevear wrote:

On Thu, 2007-03-01 at 11:29 +0100, Ludwig Nussel wrote:

...

JP Rosevear wrote:

...

One good use case we've seen with customers is that they don't want to give out the root password because that would enable users to do anything they want like update packages.

What specific part of printer configuration should a user be able to do without authentication? Demanding that users must be able to "configure printers" without knowing the root password is too coarse grained. AFAICS the YaST2 printer module for example offers to reconfigure the firewall and to install additional packages when needed also as part of printer configuration.

Adding printers. You can get large setups with dozens or hundreds of printers.

Are you talking about setups where you plug in your shiny new USB printer and want it to just work or are you talking about network printers? I was assuming you were talking about the former but I somehow doubt that "hundreds of printers" need to be configured in that scenario ;-) cu Ludwig -- (o_ Ludwig Nussel //\ SUSE Labs V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Hello, On Mar 2 18:44 JP Rosevear wrote (shortened):

On Fri, 2007-03-02 at 11:56 +0100, Ludwig Nussel wrote:

...

JP Rosevear wrote:

...

On Thu, 2007-03-01 at 11:29 +0100, Ludwig Nussel wrote:

...

What specific part of printer configuration should a user be able to do without authentication?

Network printers

Network printers??? What about http://en.opensuse.org/SDB:CUPS_in_a_Nutshell "Intrinsic design of CUPS for printing in the network" What is the original end-user requirement behind? Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany AG Nuernberg, HRB 16746, GF: Markus Rex --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Mon, 2007-03-05 at 15:30 +0100, Johannes Meixner wrote:

Hello,

On Mar 2 18:44 JP Rosevear wrote (shortened):

...

On Fri, 2007-03-02 at 11:56 +0100, Ludwig Nussel wrote:

...

JP Rosevear wrote:

...

On Thu, 2007-03-01 at 11:29 +0100, Ludwig Nussel wrote:

...

What specific part of printer configuration should a user be able to do without authentication?

Network printers

Network printers???

What about http://en.opensuse.org/SDB:CUPS_in_a_Nutshell "Intrinsic design of CUPS for printing in the network"

What is the original end-user requirement behind?

The original requirement is two fold 1) Ease of use for end users It works perfectly fine on Windows XP and OS X to browse network printers and print to one without requiring admin privileges. 2) Restricting root access for admins Admins want to allow straightforward operations like changing the wireless network or adding a printer without giving out the full root password (which allows things like installing new packages) Item 1) is primary here, its just easier. -JP -- JP Rosevear Novell, Inc. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Tue, 2007-03-06 at 10:58 +0100, Johannes Meixner wrote:

Hello,

On Mar 5 13:09 JP Rosevear wrote (shortened):

...

On Mon, 2007-03-05 at 15:30 +0100, Johannes Meixner wrote:

...

What about http://en.opensuse.org/SDB:CUPS_in_a_Nutshell "Intrinsic design of CUPS for printing in the network"

What is the original end-user requirement behind?

The original requirement is two fold

1) Ease of use for end users

It works perfectly fine on Windows XP and OS X to browse network printers and print to one without requiring admin privileges.

Your info is too terse for me. I still do not understand the end-user's situation. Please do not misunderstand me - I don't want to do nitpicking. But I need to understand the whole picture from the end-user's point of view - otherwise whatever nice-looking implementation may not solve the actual end-user problem.

The situtation is the end user doesn't want to type in a password to do simple operations.

What do you mean with "browse network printers" here? Browse the raw printers or browse associated SMB shares (or whatever kind of associated print queues)?

Adding an SMB shared printer is the specific case I had in mind, but other types of network printers too if applicable

Did you read http://en.opensuse.org/SDB:CUPS_in_a_Nutshell "Intrinsic design of CUPS for printing in the network"? When there is a CUPS server, there is _nothing_ to be set up at all on the client systems, see http://en.opensuse.org/SDB:CUPS_in_a_Nutshell "Configuration of the clients" ------------------------------------------------------------ Start cupsd. ... Under normal circumstances, you should not configure anything else, especially * no local queues on clients and * no changes in the default settings for cupsd on clients. ------------------------------------------------------------

Why do you want to implement Windows-stlye printing when we use CUPS on Linux?

Because its what most users expect and want, even many linux ones.

Or is there a special end-user environment why we need to do Windows-stlye printing even with CUPS on Linux?

Perhaps you are talking about a user with a Linux laptop or Linux workstation in a Windows-only environment?

Not just in these specific cases, I'm thinking home users in general.

...

2) Restricting root access for admins

Admins want to allow straightforward operations like changing the wireless network or adding a printer without giving out the full root password (which allows things like installing new packages)

Why cannot the admin set up appropriate stuff in cupsd.conf so that whatever users on whatever hosts are allowed to do whatever he likes?

Why should we implement something anew when from my point of view everything is (and was) already implemented in CUPS?

Since CUPS 1.2 there are even fine-grained policies, see http://www.cups.org/documentation.php/ref-cupsd-conf.html "Policy" and "Limit (Policy)"

Ah, this is nice, I wasn't aware there was a policy system in 1.2, thanks for pointing this out.

From my point of view all we may need is a nice GUI to set up those policies in cupsd.conf - e.g. an enhancement of the CUPS web-interface, see on a CUPS 1.2 system http://localhost:631/admin "Server"

Yes, quite possibly with the policy system above. I might rather see a single yast module that is a starting point for various configurations of this type of options, ie something like: [ ] Primary user can mount removable media [ ] All users can mount removable media [ ] Primary user can add and remove printers [ ] All users can add and remove printers [ ] Primary user can install, update and remove software [ ] All users can install, update and remove software Where the primary user is the first user you create. Ideally we'd be able to keep this hidden and have a 'Home User' vs 'Traditional Unix Permissions' option or something. (I'm also not sure this is actually a Yast module, but it will do for now as an example). This would lead into a nice system for things like basic parental controls. Robert, you had some ideas around this right? -JP -- JP Rosevear Novell, Inc. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Wed, 2007-03-07 at 16:39 +0100, Johannes Meixner wrote:

Hello,

On Mar 7 10:30 JP Rosevear wrote (shortened):

...

On Tue, 2007-03-06 at 10:58 +0100, Johannes Meixner wrote:

...

Your info is too terse for me. I still do not understand the end-user's situation. Please do not misunderstand me - I don't want to do nitpicking. But I need to understand the whole picture from the end-user's point of view - otherwise whatever nice-looking implementation may not solve the actual end-user problem.

The situtation is the end user doesn't want to type in a password to do simple operations.

Frommy point of viwe it seems from mail to mail you change the issue (it started with USB printers, became network printers, now it is about typing passwords) and it seems you still don't tell the whole story.

No, the user should not need root to include any printers, I just didn't explicitly call out network printers to begin with and I should have.

...

...

Why do you want to implement Windows-stlye printing when we use CUPS on Linux?

Because its what most users expect and want, even many linux ones.

I am afraid but it seems now we are at a dead end.

Why exactly are we at a dead end? We agreed in the dist meeting not needing root to configure a printer was a valid use case. -JP -- JP Rosevear Novell, Inc. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Hello, On Mar 7 10:46 JP Rosevear wrote (shortened):

On Wed, 2007-03-07 at 16:39 +0100, Johannes Meixner wrote:

...

On Mar 7 10:30 JP Rosevear wrote (shortened):

...

On Tue, 2007-03-06 at 10:58 +0100, Johannes Meixner wrote:

...

Your info is too terse for me. I still do not understand the end-user's situation. Please do not misunderstand me - I don't want to do nitpicking. But I need to understand the whole picture from the end-user's point of view - otherwise whatever nice-looking implementation may not solve the actual end-user problem.

The situtation is the end user doesn't want to type in a password to do simple operations.

Frommy point of viwe it seems from mail to mail you change the issue (it started with USB printers, became network printers, now it is about typing passwords) and it seems you still don't tell the whole story.

No, the user should not need root to include any printers, I just didn't explicitly call out network printers to begin with and I should have.

You mix up many different things is your requests that I don't know what you actually want. I asked you several times to provide more info about the original problem and the user situation but all I get are terse snippets which are useless at least for me. You talk about USB printers and home users and about printing in big networks with hundreds of printers (obviously now a business environment) where dedicated admins exist and full automated setup of printers (in the network?) and not being root to set up printing (in the network?) and whatever else may come into mind when talking about "the printing stuff". Please be 100% exact with your wording - at least try to be as exact as you can! I had it in the past so often that discussions get lost in a mess of non-exact words like the ancient http://en.wikipedia.org/wiki/Confusion_of_tongues For example "no need to be root to do something" is different to "not type in a password". If there is a policy in cupsd.conf which allows the normal user "johndoe" to do any printer setup, then the cupsd does authentication (i.e. it asks for the password of johndoe): -------------------------------------------------------------------- johndoe$ /usr/sbin/lpadmin -p test -v parallel:/dev/lp0 -E Password for johndoe on localhost? [johndoe must type in his password] -------------------------------------------------------------------- As far as I know this is because for the cupsd there is just a IPP request comming in (the lpadmin command can work from any host to any host in the network) and the cupsd must make sure that it is really johndoe who sent this IPP request. On the other hand I wonder why cupsd doesn't need to do the same kind of explicite authentication for root on localhost. I will ask on the CUPS mailing list why cupsd does explicite authentication for normal users on localhost.

...

...

...

Why do you want to implement Windows-stlye printing when we use CUPS on Linux?

Because its what most users expect and want, even many linux ones.

I am afraid but it seems now we are at a dead end.

Why exactly are we at a dead end? We agreed in the dist meeting not needing root to configure a printer was a valid use case.

We are at a dead end when you want to pervert how printing is done under Unix/Linux operating sytems (for CUPS and even for the old-stlye Unix/Linux printing systems like LPR and LPRng) into how printing is done under Windows (and iPrint). Because you wrote "most users expect and want" this, it means you want to do Windows-stlye printing by default. This is the dead end. Again: Please be exact with your wording! "do Windows-stlye printing" is different to "no need to be root to do something" (which is different to "not type in a password"). Of course when the Linux system is in a Windows-only environment (or in an iPrint environment) then the Linux system must do Windows-stlye printing but this is different to do Windows-stlye printing by default. Compare http://en.opensuse.org/SDB:CUPS_in_a_Nutshell "Intrinsic design of CUPS for printing in the network" ----------------------------------------------------------------- the queues of the server are available directly on the client. ... * no local queues on clients and * no changes in the default settings for cupsd on clients. ----------------------------------------------------------------- with http://en.opensuse.org/SDB:Printing_via_SMB_%28Samba%29_Share_or_Windows_Sha... "Background Information" ------------------------------------------------------------------ The SMB host does not convert the print data from the applications (e.g., PostScript) to printer-specific data. Therefore, the filtering must take place on the Linux host, which requires a complete print system on the Linux host. A queue with filtering must be set up on the Linux host. ------------------------------------------------------------------ For iPrint it is the same as for SMB. Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany AG Nuernberg, HRB 16746, GF: Markus Rex --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

* JP Rosevear [Mar 08. 2007 17:01]:

You pointed out the policy piece in cups 1.2 which is great, that gives us the underlying tools to solve this.

... which seems to be limited to cups. There exists a myriad of implementation to delegate access rights to users in Linux. On the low level pam modules is one, resmgr another, then we have policy kit, setuid-root binaries, etc. ZENworks brings its own framework for role based access control (rbac), cups has policies, YaST is supposed to support rbac in the future. I'm not a security expert, so these things might have non-overlapping semantics. But they certainly do overlap in certain areas. The more such implementations exist, the more ways hackers will find to break them. Long term, I'd like to see one architecture to delegate 'specific root rights' to users rather than extending different implementations for specific use cases. Just my $0.02 ;-) Klaus --- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Fri, 2007-03-09 at 11:51 +0100, Johannes Meixner wrote:

Hello,

On Mar 8 10:59 JP Rosevear wrote (shortened):

...

1) It sucks for home users to have to enter a password to setup a printer.

How often does a home user set up a printer?

When it comes to a USB printer, how about every time it's disconnected/connected?? I've got a HP Photosmart printer at home. If I configure it (with root), then I can print. But if I turn it off and then back on, cups will show it as online, but when I print to it, nothing will happen. There won't even be a document in the printer queue. So, the only thing (well, shouldn't say that it's the only thing, but...) I can do is to delete the old printer and re-add it. Then I can print again. Again, this require root. I tried to browse to localhost:631 and put the printer in off-line mode, then on-line mode again, but to no avail (off course, to be able to do that, I need to login as root). If I try to add a new printer while the non-functional one is still there, I get an error message that it can't find <name-of-the-printer>-2. If I hadn't forced my G/F to run Linux on her laptop, I could not have cared less, but... As it happens, she is running Linux and she can not print more than once per session without having to re-install the printer. Yes, I should probably report this behaviour as a bug. No, she shouldn't have to ask me what the username/password is in localhost:631 to try to restart the printer.

The system admin password is only needed when a new printer is added or the existing printer is replaced by a different model.

Wrong! See above...

A normal user can change and store his own printer specific settings in his ~/.lpoptions (CUPS 1.1) or ~/.cups/lpoptions (CUPS 1.2) file usually via the various printing dialog tools (kprinter, gtklp, xpp, lpoptions) but not via the various printer setup tools (which do the admin-related stuff).

Will a normal user know about these files? Or are you confirming JPR's idea of having something to simplify printing on Linux?

I can only guess that printer setup which really requires the system admin password happens about once in a year for a home user. Does it really suck to enter a password about once in a year?

See above.

Perhaps the real cause of the problem is that normal users can access in their desktop menues the printer setup tools and then they think they must use them to change printer specific settings?

How else would they *set* the printer settings? At the moment, printing in Linux sucks big time. I'm not only blaiming cups for that. OpenOffice, Adobe Acrobat Reader etc is equally bad at it (OpenOffice refuses to use the paper size set on the printer and Reader wants to print to lpr) suck as well.

...

2) Large corporate environments don't want to give out a root password,

This is a very valid request.

Agreed!

Even in a home user environment the person who works as system admin may not want to give out his root password for example to all members of his family.

See my answer above. Even if I wanted to give the username/password to my G/F, she wouldn't understand when to use it and how.

Right now Klaus Kaempf explained the background to me:

It is not only about printing, it is a very general problem that currently we have onyl a "either all or nothing" policy: Either root who has unlimited permissions or normal user who has almost no permissions.

This is correct. I would like to see everything on the Desktop simplified like JPR explained. If I plugin, for an example, an extra Network card, I don't want to have to go to YaST to configure it. I want a pop-up on my Desktop telling me that it found new hardware, and give me an option to configure it (if this can be done securely without requiring the root password, even better!) Cheers, Magnus --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Fri, 2007-03-09 at 14:13 +0100, Johannes Meixner wrote:

Hello,

On Mar 9 22:17 Magnus Boman wrote (shortened):

...

On Fri, 2007-03-09 at 11:51 +0100, Johannes Meixner wrote:

...

How often does a home user set up a printer?

When it comes to a USB printer, how about every time it's disconnected/connected?? I've got a HP Photosmart printer at home. If I configure it (with root), then I can print. But if I turn it off and then back on, cups will show it as online, but when I print to it, nothing will happen.

A bug somewhere in your hardware, in USB or in HPLIP or whatever. A bug must be fixed where it is and not by a workaround via re-setup every time the hardware is disconnected/connected. For the resulting pronblems with such a re-setup, see the previous mails in this thread.

Fair enough. I'll make an effort to report this bug.

...

...

A normal user can change and store his own printer specific settings in his ~/.lpoptions (CUPS 1.1) or ~/.cups/lpoptions (CUPS 1.2) file usually via the various printing dialog tools (kprinter, gtklp, xpp, lpoptions) but not via the various printer setup tools (which do the admin-related stuff).

Will a normal user know about these files?

I wrote "via the various printing dialog tools". If a normal user does not know how to use the printing dialog tools, there is something to do on the desktop/application layer.

You wrote *usually* via the various printing tools. But at least we're going somewhere here since you admit that if a user does not know how to do something, we need to make a change somewhere. And that's where this discussion started.

Kind Regards Johannes Meixner

I noticed that you didn't comment on the OpenOffice, Acrobat Reader issues that I also had in this mail. I know that this is not a cups issue, but it's still worth remembering in this discussion. Kinder regards, Magnus --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Friday 2007-03-09 at 11:51 +0100, Johannes Meixner wrote:

On Mar 8 10:59 JP Rosevear wrote (shortened):

...

1) It sucks for home users to have to enter a password to setup a printer.

How often does a home user set up a printer?

The system admin password is only needed when a new printer is added or the existing printer is replaced by a different model.

I have tried on my system, and I, with my user password, can add a new printer, via cups web interface. Maybe I have cups as too permisive, but as I'm also root and the only one using this computer, so it doesn't matter. If I had more users, I could modify it, I think, so that only a group of users have that privilege. But my point is that it is possible to allow users to add new printers, without root's password. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFF8dBztTMYHG2NR9URAn0zAKCJXTuKSApT9OHEnXyPePvolnSeMACgkaCc nmBFQGuGHrs1C0dTH/L7kQk= =u/bk -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Monday 2007-03-12 at 11:23 +0100, Johannes Meixner wrote:

Hello,

On Mar 9 22:24 Carlos E. R. wrote (shortened):

...

I have tried on my system, and I, with my user password, can add a new printer, via cups web interface.

Not by default (in particular not on my openSUSE 10.2 system). If it would be possible by default, it would be a major bug.

No, of course not, not by default. I did it that way many months ago, so that I don't remember what I did O:-) My point was that it is possible to let a normal user add printers, if so wanted.

What exactly is your system? Which printer setup tools did you use? Did you install whatever special printing-related packages (e.g. third-party drivers or a Novell iPrint client package)?

Only one user, me, I'm root also, so the only user is as safe as root, he won't be "dafter" than Mr root ;-) Home system, inkjet printer (canon bjc4000), with turboprint driver. I use cups for printer setup, not Yast (I do use Yast during system install, then switch to cups web interface).

What are the active lines in your cupsd.conf? Show them via egrep -v '^$|^#' /etc/cups/cupsd.conf | fold -s -w60

Mmm, fold? That's new for me... Ah, I see. Interesting. Ok, here goes: +++************************** LogLevel info Printcap /etc/printcap User lp Group lp RunAsUser Yes Port 631 BrowseAllow @LOCAL BrowseDeny All <Location /> Order Deny,Allow Deny From All Allow From 127.0.0.1 Allow From 127.0.0.2 Allow From @LOCAL </Location> AuthType BasicDigest AuthClass Group AuthGroupName sys Order Deny,Allow Deny From All Allow From 127.0.0.1 </Location> Browsing Off **************************++- I see. It is this: AuthType BasicDigest AuthClass Group AuthGroupName sys and only on 127.0.0.1 The strange thing is that I don't belong to group "sys", but I do belong to "root". Could be that: # SystemGroup: the group name for "System" (printer administration) # access. The default varies depending on the operating system, but # will be "sys", "system", or "root" (checked for in that order.) # #SystemGroup lp Curious... - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFF9TPotTMYHG2NR9URAsHRAJ4kPm3py7OHuZiWxV2YFRsfcO/WYgCeMa3u sDc0bnsNwVvEds33zj3wi7M= =K/0z -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Monday 2007-03-12 at 12:30 +0100, Johannes Meixner wrote:

On Mar 12 12:05 Carlos E. R. wrote (shortened):

...

The Monday 2007-03-12 at 11:23 +0100, Johannes Meixner wrote:

...

On Mar 9 22:24 Carlos E. R. wrote (shortened):

...

I have tried on my system, and I, with my user password, can add a new printer, via cups web interface.

Not by default (in particular not on my openSUSE 10.2 system). If it would be possible by default, it would be a major bug.

No, of course not, not by default. I did it that way many months ago, so that I don't remember what I did O:-)

Puh!

:-)

This is a CUPS 1.1 cupsd.conf file. I guess you did lppasswd -g sys -a normal-user

Could be. This is a 10.2 system, updated from a 9.3 backup, this from 9.1, 8.2, 8.1, 7.3... at least. So, if I have a 1.1 config file, the fault is YAST's not to have it upgraded, or at least generate an /etc/cups/cupsd.conf.rpmnew file at some point in time.

see http://en.opensuse.org/SDB:Printer_Configuration_from_SUSE_LINUX_9.0_on

When you use openSUSE 10.2 which has CUPS 1.2 where RunAsUser is no longer supported, you may like to start from scratch with an original CUPS 1.2 cupsd.conf file where you may like to allow printer admin stuff for a normal user as follows:

Maybe I can get the original config from the rpm. One thing more to my to-do list. Thanks :-) - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFF9VyAtTMYHG2NR9URAiNEAJ9IxNH6i3GO+u0la4dGMNXtB4AdcACaAmTU ci51ChohlrZbbjEds2qcMF8= =R5Lj -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Monday 2007-03-12 at 12:36 +0100, jdd wrote:

Carlos E. R. wrote:

...

Only one user, me, I'm root also, so the only user is as safe as root, he won't be "dafter" than Mr root ;-)

don't think so.

When a simple user become root, this is for a specific task. He must give root pass. after thta he is warned to be specially cautious, and usually kill the root acces as soon as the work is done.

I don't mean that. I mean that me, as user, can add printers or other admin jobs using cups, same as root, because I have it configured that way. Being the same person, I, as "Mr Root" do not have problems trusting me, as "cer" to configure printers properly ;-) I'm never working as root, unless _really_ needed. See, I do not need to be root to configure printers :-) - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFF9V1LtTMYHG2NR9URAkt4AJ9XkraVB6H0A1TGVRXWmXFHj4XTLQCdHN7k ae/TGxpYTbcdQD9PgghW/XA= =fbt5 -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Hello, On Mar 7 10:52 Robert Love wrote (shortened):

The use case is that a standard use should (optionally) be able to manage his printers without requiring the administrator.

The "optionally" is the crucial word here! The system admin (i.e. the person who set up the system) can of course delegate his permissions and set up appropriate stuff in cupsd.conf so that whatever users on whatever hosts are allowed to do whatever the system admin likes, see my mail dated 6 Mar 2007. The crucial point is that it is under the system admin's control who is allowed to do what and that the system admin is aware of the consequences, for example http://www.cups.org/str.php?L790 ------------------------------------------------------------------- the CUPS admin user can copy this way any printout to any place he likes (e.g. send it via mail to any external address ... ------------------------------------------------------------------- If any user could change any print queue, any user could copy any printout. Note the "copy" which means that it is also correctly printed on the printer so that an innocent other user would not notice that his printout was copied. I assume this is not what we want to have by default to make our customers happy in big networks with hundreds of printers ;-) Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany AG Nuernberg, HRB 16746, GF: Markus Rex --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Hello, On Mar 8 11:16 JP Rosevear wrote (shortened):

On Thu, 2007-03-08 at 10:57 +0100, Johannes Meixner wrote:

...

http://www.cups.org/str.php?L790 ------------------------------------------------------------------- the CUPS admin user can copy this way any printout to any place he likes (e.g. send it via mail to any external address ... ------------------------------------------------------------------- ... The solution though is in a comment in the upstream bug:

"If you would like to contribute a patch which adds a "RestrictFilters" option (or a list of allowed paths, or something like that), we will consider it for inclusion in CUPS 1.2."

We could be proactive here and send a patch upstream!

According to http://www.cups.org/str.php?L790 such a "RestrictFilters" option has the consequence that it "would prevent driver developers from installing in alternate locations" (in particular third party drivers). I think what might be better is to distinguish between adding and deleting queues and changing existing queues. This way the system admin could allow that normal users can add (and perhaps even delete) queues but the system admin could forbid to change existing queues. For example a travelling salesman may have a company laptop where the system admin had set up carefully some queues for the company printers which the travelling salesman should not change but the system admin may allow that the travelling salesman can set up additional queues to print to whatever external printers e.g. in an external Windows-only or iPrint-only environment where usually even drivers must be installed on the client system to set up printing. Some background information regarding Unix/Linux-like printing and Windows/iPrint-like printing in the network: The crucial design difference is: Unix/Linux print systems: The client systems send the original data (e.g. plain text, PostScript, JPEG) to the print server and the print server converts it into printer specific format (the "filtering") and sends the printer specific data to the printer. Windows-like print systems: The client systems convert the original data into the printer specific format (therefore a printer specific driver is needed) and then send the printer specific data to the print server and the print server sends the printer specific data to the printer. Consequences: Unix/Linux print systems: The client systems don't need to care about the printer model. It is only the print server which is responsible to do the model specific stuff. This is THE advantage of the design under Unix/Linux. If an end-user has a laptop and connect it to a new network where a CUPS server is running and if the end-user runs his own cupsd on his own laptop, then he can immediately print. Windows-like print systems: The client systems must care about the actual printer model. Therefore usually model specific printer drivers must be installed on the client systems. This is THE drawback of the design under Windows. If an end-user has a laptop and connect it to a new network, then usually he cannot print without doing driver installation before. Perhaps he doesn't want to download and install drivers from an unknown/untrusted network system - what should he do? Consider the problems when printers are added or exchanged: Special software stuff (provide drivers for download) and special end-user actions (driver installation/replacement) are needed to deal with this situation. For more details see my "two longer explanations" in http://lists.opensuse.org/opensuse/2004-11/msg02874.html Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany AG Nuernberg, HRB 16746, GF: Markus Rex --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

JP Rosevear wrote:

On Tue, 2007-03-06 at 10:58 +0100, Johannes Meixner wrote: [...]

...

Your info is too terse for me. I still do not understand the end-user's situation. Please do not misunderstand me - I don't want to do nitpicking. But I need to understand the whole picture from the end-user's point of view - otherwise whatever nice-looking implementation may not solve the actual end-user problem.

The situtation is the end user doesn't want to type in a password to do simple operations.

Sorry, but I don't understand you here. Can you please elaborate these operations to me? What are they? [...]

...

From my point of view all we may need is a nice GUI to set up those policies in cupsd.conf - e.g. an enhancement of the CUPS web-interface, see on a CUPS 1.2 system http://localhost:631/admin "Server"

Yes, quite possibly with the policy system above. I might rather see a single yast module that is a starting point for various configurations of this type of options, ie something like:

[ ] Primary user can mount removable media [ ] All users can mount removable media [ ] Primary user can add and remove printers [ ] All users can add and remove printers [ ] Primary user can install, update and remove software [ ] All users can install, update and remove software

I think the comparision isn't very good. Removing media / updating software happens more recently than to add/remove printers. The spooling mechanism of print jobs (even printing to a printer, even not plugged in) is an important feature which is not comparable with the other two situations.

Where the primary user is the first user you create. Ideally we'd be able to keep this hidden and have a 'Home User' vs 'Traditional Unix Permissions' option or something. (I'm also not sure this is actually a Yast module, but it will do for now as an example). This would lead into a nice system for things like basic parental controls.

I agree with the intention, but I'm unhappy with the qualification of "primary user". This is not applicable when setting up a server. Regards, Klaus. -- Klaus Singvogel SUSE LINUX Products GmbH Maxfeldstr. 5 E-Mail: Klaus.Singvogel@SuSE.de 90409 Nuernberg Phone: +49 (0) 911 740530 Germany GnuPG-Key-ID: 1024R/5068792D 1994-06-27 SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Hi. sorry for delay, but had the flue last week... Chris Rivera wrote:

On Thu, 2007-03-01 at 12:33 +0100, Klaus Singvogel wrote:

...

We need to mention that the current hal backend needs to be extended to satisfy the new requirements, which actual CUPS system expects from backends. But it seems that upstream developers didn't work on this opportunity till today.

What requirements are you referring to?

The backends report now different states of printers back to the cups daemon.

...

Hmm. I had a quick look at the current hal/dbus architecture. I didn't see any pollin by any device so far. Instead an administration process called by the hal/dbus system is executed. I'm speeking about the hal-cups-utils/hal_lpadmin tools. Maybe I'm wrong...

Right. HAL callouts are used to add/remove printers when appropriate.

So, we can use any program here? Thinking of YaST for automatic de-/installation...

...

But if not, then we might replace the hal backend by _any_ backend, and no need to use no longer developed tools (hal backend) is needed. Instead we can use our own mechanism here, even YaST, as soon as YaST supports installation of printers without any need of user feedback (full automatism).

You would have to convert the HAL udis to whatever uri scheme the other backends use. We might be able get the device node in the callout and eliminate some of the work for the backends, but this seems kinda clunky. It would be nice to just take advantage of HAL and use the HAL udis as persistent printer uris.

But does HAL backend work properly for multi function printers (MFP) (= FAX/Scanner/Printer devices)? Does HAL backend always work with _any_ supported OpenSource driver? AFAIK the hplip backend needs to be used to be able to scan with such MFP devices. Using the usb backend caused (locking) problems, when scaning with such devices. As the code of the hal backend is pretty close to the usb backend, I expect same problems here.

...

I want to point out, that there should be no goal to remove the usb backend from the system. The reasons are the manuals, and the CUPS book, which only speaks about this. Also the good help at the cups mailing lists should be mentioned, which is no longer usuable for the customers, if we cut the usb backend off the system.

How are ambiguities between the backends resolved? Having both usb and HAL backends cause the same printer to be detected twice. You need mappings between uri schemes to avoid this, right?

Yes, I think that such a mapping might be necessary. But the libusb provides the same information (vendor, model, serial) as the dbus node contains. I think the program for mapping shouldn't take to long to write down. But a good testing needs to be done though. Regards, Klaus. -- Klaus Singvogel SUSE LINUX Products GmbH Maxfeldstr. 5 E-Mail: Klaus.Singvogel@SuSE.de 90409 Nuernberg Phone: +49 (0) 911 740530 Germany GnuPG-Key-ID: 1024R/5068792D 1994-06-27 SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Thu, 2007-03-01 at 12:33 +0100, Klaus Singvogel wrote:

JP Rosevear wrote: [...]

...

1) Detecting a local USB printer when plugged into the machine and prompting the user to configure it or automatically selecting a driver and configuring the printer

We have a lot of the detection code, both usb and hal cups backends can detect the usb printer.

Please keep in mind: this discussion should not be restricted to usb and hal backend, also the vendor specific backends should be supported: hp:, hpfax: (both from the full OpenSource project hplip), epson:, and many more to get the best printing results from a printer.

Very good point. Can these detect USB devices like the usb backend? Or to they have a better canonical naming scheme for the printers?

...

Hal being a general hardware detection layer actually sends a message when its plugged in and GNOME uses this to pop up a dialog to configure the printer via a hal backend for cups. However the hal backend is not a standard upstream cups backend and its very difficult to convert a cups hal:// uri to a usb:// one - but not entirely impossible, there is some code in /usr/bin/add-unknown-printer (part of the gnome-volume-manager) to do some of this.

We need to mention that the current hal backend needs to be extended to satisfy the new requirements, which actual CUPS system expects from backends. But it seems that upstream developers didn't work on this opportunity till today.

Well, it works enough to be used extensively in Fedora and Ubuntu, but yes it could be missing some pieces that we would need to add.

...

Yast also does not support the hal backend currently. The usb cups backend is the standard upstream cups backend but it does no polling so we'd need to poll somehow (gnome-volume-manager and kmediamanager are possiblities).

Hmm. I had a quick look at the current hal/dbus architecture. I didn't see any pollin by any device so far. Instead an administration process called by the hal/dbus system is executed. I'm speeking about the hal-cups-utils/hal_lpadmin tools. Maybe I'm wrong...

I meant if we want to base the detection on the usb backend we'll need polling.

But if not, then we might replace the hal backend by _any_ backend, and no need to use no longer developed tools (hal backend) is needed. Instead we can use our own mechanism here, even YaST, as soon as YaST supports installation of printers without any need of user feedback (full automatism).

I want to point out, that there should be no goal to remove the usb backend from the system. The reasons are the manuals, and the CUPS book, which only speaks about this. Also the good help at the cups mailing lists should be mentioned, which is no longer usuable for the customers, if we cut the usb backend off the system.

Agreed.

...

For true zero config printer, we'd need to build up a database of printer ids and driver mappings and include that in the distro. We also need to make this configurable so that you have the possibility of not doing zeroconfig printing on servers.

True. This is the first step.

I'm still asking myself how a correct paper size (Letter or DinA4) is configured by zero conf.

Locale data might be one way to guess (pretty much anyone outside North America is probably A4 :-)).

If we want to extend this later, then we should think about a way to preserve an existend, and possibly modified configuration of a specific printer. The idea is here to get the old system configuration back, as soon as a printer gets replugged into the system.

Agreed.

...

2) Not needing root to configure a printer [...]

No comments from me to this topic so far.

...

3) Detecting when a printer is connected/disconnected and offering visual feedback via a notification area icon, or some other ui feedback

An easy thing to do here would be to patch cups to send out dbus signals and both GNOME and KDE could put up tray icons or whatever. HAL could also be used to detect disconnects reconnects

We need also handle the situation if a printer gets connected/ disconnected from the system when the system was switched off. We should not restrict our thinking about getting signals, boot time needs also to be handled properly.

About the tray icons: as this automatic configuration should also work on machines without KDE nor GNOME, this is only an optional extension in my point of view.

DBus signals would handle this, if there is no listener they would just be ignored, if there is a listener the listener can do whatever they want.

...

4) Ability to remove printers from cups (even shared printers) when they're unplugged to prevent jobs from accumulating in the queue or being default

If we can get to zeroconfig printing we could optionally just remove a printer from cups when its unplugged. A little more unclear how useful it would be.

I want to point out the "optionally" here.

CUPS offers the possibility of spooling print jobs, when the communication to a printer fails (or the admin wishes so). Sure, Enterprise Servers admins are more interested in this spooling feature than home users. So we should offer a configuration for both kinds of customers. I'm thinking of storing this global configuration data somewhere below /etc/sysconfig.

Sounds good - we should consider a design that gets as much of the above as possible upstream as well. -JP -- JP Rosevear Novell, Inc. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org