[opensuse-factory] Printing in openSUSE 10.3
A couple weeks ago at the dist meeting we discussed improving how printers are configured on openSUSE. Specifically we discussed the following use cases as something we would want to achieve for 10.3, and we'd like to open up the discussion on implementation: 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. 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. 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). 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. 2) Not needing root to configure a printer Couple of thoughts here, for a hal based solution we might be able to leverage PolicyKit and unify our hardware access permissions system with an upstream default. We could also alter resmgr for this or use sudo. We need to make sure this is configurable though, because it needs to be turned off for servres. 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 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. If someone wants to throw up some info as an openSUSE project http://en.opensuse.org/Projects that would be great. I suspect items 1) and 2) are really the keys, if they work then 3) or 4) should be pretty straightforward. -JP -- JP Rosevear <jpr@novell.com> Novell, Inc. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
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.
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.
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. cu Ludwig [1] Some like the idea of typing their own password instead of the root password for that purpose. -- (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
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 <jpr@novell.com> Novell, Inc. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
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 -- (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
-----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 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 8SorBaLHa7fvf+b+O7hvPKdpUU3HSN7Sfzm9HrmlNiSvCX/7mX2Gl/66BrxXLiMW yBNEtTqK3eIPld95VFtrMH1qCfFKWxptOGD/IPjmryc2zkbHTZ8cbYfaSmkjGQRy 4LN5qUIRRe8h8Q1hFO25kaOcexhd0uUtF3gYCtbyAZc4hb6VkCKAYIpwrXgYvpA+ mdpjI4aKWycOFJ2PmtipB26MGGP4BHj3heeNioTdKQf9GYdoCup/wXsBvpO355ms +Yis1u/+o3qXb/OJ7VgTaNvqa2S0ebRmBRoBqicCH/qJCRErMaYZCDbEeTjPtyTy nnc2xriYdt4xkR5Pz4n3vfDH/A1ZL+or2WbTx+g1taEElymHxCE+4n/OmPNG0+eD COigw9baxVaJplBP4rAMrClMmnI3bs3d6BBoVobQeUfNbyPDD3jxTxAnmHoI/3T3 HO542zIJ4aMgxr6cgM3dfOJIh7fWobN9MWst0S26kuFGAoP/EIuUN9YbtwffTA9B QMqm4wNtskP2p2+OxITXiiG7cSPhLJAji1ogA1e6iaiTn8fLV6zdLsXPSP1ccjco ndLpAT9H5zOQlRW8As+GqRtOEWEvGFK3x/TTzBVcHRntVgAvev94BbI7syoyJjAO 6YbCqZ/ZV51jHvRQFZ8t0wugBQb0xrx2/tV4X/KNqnAzI6zZhcBUGX+VJr24KUMN GORGcRnRypQcC9RpdItRweIPlaxAMZzHsvRXvTfRephxzON0awfpFU4a1qe7si3E Mhd8xabnjILUcoZlijluT+XoAt4d7DOs2pzIjklcBxByvmBbGkUN5NBo1JMqS9Jn MPkl0MQsy5wsQOoAXP9/onpUh+1dpKX1SWH+8JaQGAB1MfFsiyf2o03StW+ezF0T BEvEya2ps4cqGND7rIo+DPi0w5ys5bjk8u96PuPqJBXkX9Hto8Lo0GrJDTnU9p/0 rXm0o0PZeLpLoUBOhWv3onqRpmZ9PhPEfDmWwSVlEoucywQ/Sodo/Bik1Fia6EA/ JGumzX51jsFsJrTIJ/hlwfhyW+/2GA50/VtRQAXXavDfE2TxER+WUz3DSdsvQcON nbwS3LYCxzhkmPUrArqQ7rp+K5yjyKwZb0RlFqnlA9o3pMOy6sfSZND984Qn62XO wEGDFQFHWCyn3qrTIs+1QOOFd2Ype8c3+XCwVi7QdIQkmQ3cR5b1X/nBwIpxp56o tPNRwGBfNzaxlBecOh2F8Z9Ehi13paUbEczOXdX3dQhOfSrAPigVLm0uZvcmy6GG YjGcOe0QGJeu/izhwL9yLS1bg4xcNI5WjtW3V0vewEHUNEmwDQLHnkVfzxlaZxHI XwaXtODO+HC12cEtL/DTktMZ0R4qKWnsy/huZvViiPYYYdmc8umK66BXwcRlF+jQ ns+cjIYYVVoKilaEwVh+dtBVPqFtBjApe31HWwffizMTRwan008sKXa3AEPjS1p0 VV5YefoIZGTADo4EtZipmrQ+OkgAKLn4h4EtIfi9m/UQzros8v4/aH1nZpeQiFsv iOroo1Eu4I28t4mB0rT+Q1MDXy+rMBJE7F2zntthA0SSpYqbEaOk5NmsEpmcVqb4 IOcK =tl0K -----END PGP MESSAGE----- --------------------------------------------------------------------- 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
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. -- Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support Specialist, Cricket Coach Microsoft Windows Free Zone - Linux used for all Computing Tasks --------------------------------------------------------------------- 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
* M9. <monkey9@iae.nl> [03-02-07 11:44]: [...]
Btw. did anyone got the key imported?
For an open mailing list??? You waste my time! -- Patrick Shanahan Registered Linux User #207535 http://wahoo.no-ip.org @ http://counter.li.org HOG # US1244711 Photo Album: http://wahoo.no-ip.org/gallery2 OpenSUSE Linux http://en.opensuse.org/ --------------------------------------------------------------------- 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 Patrick Shanahan schreef:
* M9. <monkey9@iae.nl> [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... ;-) - -- 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 iD8DBQFF6IDqX5/X5X6LpDgRAtaZAKDIsJMZLvmHqSyLGpqrexohcQ6/6wCeKmkO QjtZvJE6MAv5oEQ5zn1uCFE= =CQn4 -----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. <monkey9@iae.nl> [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 The Friday 2007-03-02 at 17:41 +0100, M9. wrote:
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?
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 <monkey9@iae.nl>" 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 <monkey9@iae.nl>"
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. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFF6HQ0tTMYHG2NR9URAmruAJ9mVxVbrASOEQp7PPUu7bgCYsLCXwCfRRlZ w0IvTC5vu0l1ydh0Yu6v2bI= =S7Mj -----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 <monkey9@iae.nl>"
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 <monkey9@iae.nl>"
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
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. -JP -- JP Rosevear <jpr@novell.com> Novell, Inc. --------------------------------------------------------------------- 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
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:
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 ;-)
Network printers, I should have actually listed that explicitly in use case 2) as well. -JP -- JP Rosevear <jpr@novell.com> Novell, Inc. --------------------------------------------------------------------- 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Johannes Meixner schreef:
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
Might sound a bit strange for an expert, but i think what is meanth is: A printer is connected, people need to print and want the hardware found by the software, recognised, and installed, with less possible interaction or/and choices, Which means: Someone pushes whatever printbutton, and the printer starts printing. Recognised, drivers downloaded, installed, visible in a network, and useable in a network. It should be enough, to plugin the printer, wait until the software has set-up the hardware, and asks the user if he/she wants to print a testpage..( an icon could show, that everything is ok) If not, i would happy to be corrected.... - -- 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 iD8DBQFF7D++X5/X5X6LpDgRAg4pAKCOk4FaaAXysAEcUSyHX/O5pZcn2gCghUFm pFrfluYP0wmJefdeTL+gVCE= =9d0f -----END PGP SIGNATURE----- --------------------------------------------------------------------- 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 <jpr@novell.com> Novell, Inc. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
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. 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)? 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? 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?
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)
From my point of view all we may need is a nice GUI to set up
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)" 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" 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 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 <jpr@novell.com> 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: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.
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. 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 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 <jpr@novell.com> Novell, Inc. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Wed, Mar 07, 2007 at 10:46:37AM -0500, JP Rosevear wrote:
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.
Correct. We also agreed on: - Either do full automatic configuration on plugin / detection, if necessary driven by a database of known good printer <-> configuration mappings or: - Ask for the root password. Any interaction channel between desktop user and higher privileged processes should be protected by the root password. Ciao, Marcus --------------------------------------------------------------------- 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
On Thu, 2007-03-08 at 10:04 +0100, Johannes Meixner wrote:
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.
I will put this as plainly as I can, the original problems are: 1) It sucks for home users to have to enter a password to setup a printer. 2) Large corporate environments don't want to give out a root password, but do want people to be able to configure a printer still. You pointed out the policy piece in cups 1.2 which is great, that gives us the underlying tools to solve this. We just need to figure out how to set this up nicely for people instead of using vim to edit a file on disk. Klaus's role bast yast email sounds promising for this.
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".
See above, two cases to be solved by the same mechanism.
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).
I personally don't think setting up cups policies that mimic "Windows or OS X printing permission requirements is "perverting the Unix/Linux way"? There are millions of people who expect this kind of behavior. I want them all to be happy SUSE users. I think even existing users will by and large like this change, and if not it needs to be optional anyhow.
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.
Nope, its a challenge. We need to present the average end/home user with what they want and expect. You've talked a lot about how cups differs. The windows-style part I'm looking for is the end user experience, its not to fundamentally change how cups works.
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").
Not having a password is the key. Maybe I jumped a head on the implementation, but a simple way to do this is to not require being root for this operation. -JP -- JP Rosevear <jpr@novell.com> Novell, Inc. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
* JP Rosevear <jpr@novell.com> [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
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? The system admin password is only needed when a new printer is added or the existing printer is replaced by a different model. 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). 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? 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?
2) Large corporate environments don't want to give out a root password,
This is a very valid request. 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. 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.
Klaus's role bast yast email sounds promising for this.
I think this is exactly the right direction. In particular see my other mail from today: Only CUPS policies are not sufficient to set up printing in a Windows-like network printing environment where usually printer drivers must be installed on the client system.
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).
I personally don't think setting up cups policies that mimic "Windows or OS X printing permission requirements is "perverting the Unix/Linux way"?
It seems only a misunderstanding because of unclear words. See my other mail from today where I explained what I mean with Unix/Linux-like printing versus Windows/iPrint-like printing (in the network). Of course setting up appropriate CUPS policies is perfectly o.k. and it has nothing to do with the fundamental difference between Unix/Linux-like printing and Windows/iPrint-like printing. What I want to point out is that in a big (i.e. business) network where admins exists, there has to be a CUPS server machine which is set up by the admins so that all Linux client systems can immediately print without any kind of printer setup on the Linux client systems. Therefore all my questions about which environment you have in mind where printer setup on client systems in a business network (with network printers) is needed. When there is a business customer who wants to install many SLEDs, we should urgently recommend to set up also at least one SLES to run a CUPS server so that for all SLEDs printing just works. 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 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
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.
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. 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 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
Hello, On Mar 10 00:32 Magnus Boman wrote (shortened):
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.
Unfortunately the subject of this thread is unspecific so that all kind of printing issues could mix up here. I recommend to focus in this thread only on the initial issues and start new threads with appropriate subjects for other issues. But if there are issues which look like real bugs, please file bug reports. By the way: Regarding media size and imageable area see https://bugzilla.novell.com/show_bug.cgi?id=148707 Regarding Adobe Reader: It is proprietary software and all we are allowed to do is to provide it "as is" and we can only inform Adobe about bug reports. 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
-----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
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. 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)? What are the active lines in your cupsd.conf? Show them via egrep -v '^$|^#' /etc/cups/cupsd.conf | fold -s -w60 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
-----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> <Location /admin> 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
Hello, 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!
User lp Group lp RunAsUser Yes ... <Location /admin> AuthType BasicDigest AuthClass Group AuthGroupName sys Order Deny,Allow Deny From All Allow From 127.0.0.1 </Location>
This is a CUPS 1.1 cupsd.conf file. I guess you did lppasswd -g sys -a normal-user 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: -------------------------------------------------------------------- <Policy default> ... <Limit ... CUPS-Add-Printer ...> Require user @SYSTEM normal-user -------------------------------------------------------------------- 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
-----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
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. this is why the work is safer. also that way, no malicious script can harm your system. jdd -- http://www.dodin.net Lucien Dodin, inventeur http://lucien.dodin.net/index.shtml --------------------------------------------------------------------- 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
On Wed, 2007-03-07 at 16:39 +0100, Johannes Meixner wrote:
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.
There are several benefits to changing the backend, I grant, but the primary goal here is to not require root to do basic printer manipulation last. The use case is that a standard use should (optionally) be able to manage his printers without requiring the administrator. I don't think we should be at a dead end! :) Robert --------------------------------------------------------------------- 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
On Thu, 2007-03-08 at 10:57 +0100, Johannes Meixner wrote:
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 ;-)
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! -JP -- JP Rosevear <jpr@novell.com> Novell, Inc. --------------------------------------------------------------------- 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Thursday 2007-03-08 at 10:57 +0100, Johannes Meixner wrote:
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.
As a user, I like it the way it is now, with cups; when I want to add or modify a printer, I use the cups web interface. A user can add a printer, if I remember correctly, depending on cups config. The only thing I miss is a Yast module to configure cups for those permission schemes. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFF8c3ztTMYHG2NR9URArIEAJ9++i/MPaKOCZP3vemPdiQBPmxEIwCfdiSn ahGE+zrY3aEyjvZRqcX/zKQ= =S1ra -----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 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Thursday 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? 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.
Add a new printer, not the main one. I think cups handles that nicely, I don't use Yast to install my printer. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFF6BsRtTMYHG2NR9URAn/0AJ0bbK6EPBufUAKG330lf70P3RcH/QCfRIbn d/YSB1Fj4L+ilFJK+XTKo2Q= =szXH -----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: [...]
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.
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.
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... 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.
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. 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.
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.
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. Again the points removing a printer during switch off and preserving configuration for later replug should be possible/designed for later here too. Best 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:
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?
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.
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.
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? Chris --------------------------------------------------------------------- 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Thursday 2007-03-01 at 12:33 +0100, Klaus Singvogel wrote: ...
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 would object to something configuring printers without my knowledge, automatically. One of the good points of linux is that it is stable, in the sense that once we configure something it stays put and we don't have to touch it ever again. Too many automatisms and that will break. At least, let yast ask whether we want automatic configuration of printers or not.
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.
As a home user, I'm very happy with cups spooling while the printer is disconnected. I print, I notice that it is not actually printing, then I look at it and power it on, without having to repeat the print job, and no pesky pop-ups. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFF6CHbtTMYHG2NR9URAqzJAJ46kzOa3iaYL42bwpHC1BcODPpM9ACaAuas Xt7xe2nZHKJeNcui1iaVFyw= =nqNB -----END PGP SIGNATURE----- --------------------------------------------------------------------- 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 <jpr@novell.com> Novell, Inc. --------------------------------------------------------------------- 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 12:33 +0100, Klaus Singvogel wrote:
JP Rosevear wrote: [...]
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.
Sorry, but to my knowledge Ubuntu isn't using it anymore, due to given reasons. They will move toward PrinterDrake in future: https://wiki.ubuntu.com/PrinterDrake [...]
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.
Sorry, but I'm not able to follow you here. Isn't this polling/interrupt mode depending on the configured dbus/hal callout configuration (the fdi file) and not the used cups backend? If I understood the hal-cups-utils correctly (which Fedora is using), then this is only a small helper tool "/usr/sbin/hal_lpadmin", which is independend from the used cups backend. I don't see at the moment any relationship between polling mode of dbus/hal and the used cups backend. The only advantage of using the hal backend is IMHO that we don't need any additional book keeping about the used backends for configured printer. But (!) as soon as we accept that multi function printers have to use different backends (hplip), and which are not the hal backend, this book keeping has to be done anyway. So I think the hal backend isn't really helpful as soon as we need to support additional backends anyway. And due to given reason (no further developing upstream for new cups features, problems in the past), I still vote not to use the hal backend as default and to use of the usb backend instead. 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
Hello, I am afraid I was busy - therefore my late answer now: In general I like to learn about which end-user requirements are behind the items below. E.g. "set up a printer as non-root" is not an end-user requirement. The end-user wants something different and this leads somehow to "set up printer as non-root" which is an implementation detail from the end-users point of view. Please provide the original end-user requirement and how this leads to the items which you described below. On Feb 28 18:07 JP Rosevear wrote (shortened):
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
Main problem here: Detect if there is already a queue for a plugged in USB printer. Problem because there are different backends for USB printers e.g. "usb" in CUPS, "epson" and "canon" in Gimp-Print/Gutenprint, "hal" in HAL, and each printer manufacturer can make its own backend, e.g. HP has "hp" and "hpfax", Epson Avasys has "ekplp", ... I.e. how to force the printer manufacturers to use all the same style for DeviceURIs for USB printers so that one can detect that this individual printer is already configured?
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.
Model names are often useless e.g. many Epson USB printers show up only as "USB printer" - in contrast for HP model names work o.k. so that only USB IDs would work well but currently we don't have a list of USB printer USB verdor and model IDs.
2) Not needing root to configure a printer
What does "configure a printer" mean? Set up a queue for new plugged in USB printer? Change any settings for any existing queue? What is the original end-user requirement behind this item?
3) Detecting when a printer is connected/disconnected and offering visual feedback via a notification area icon, or some other ui feedback
Why any visual feedback at all? I assume you have USB printers in midn because only hotpluggable printers can be connected/disconnected while the system is up and running. But a USB printer is locally conneted so that the user who connects/disconnects it already knows it and doesn't need additional visual feedback about what he did. Again: What is the original end-user requirement behind this item?
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 do not understand what "or being default" means? What do you mean with "remove shared printers"? Again: What is the original end-user requirement behind this item? Are you perhaps talking about the CUPS error policy, see http://www.cups.org/documentation.php/ref-printers-conf.html and http://www.cups.org/documentation.php/man-backend.html Background info: If for whatever reason a queue can no longer print (e.g. after a USB printer was unplugged) there are four possible reactions: 1. Do nothing and leave it up to the particular backend and the CUPS error policy what happens to further print jobs. 2. Disable printing (but still let jobs queue): Useful when there is only a short-time outage. 3. Reject jobs: Useful when there is a longer time outage. 4. Remove the queue (all info about the queue gets lost): Useful when the printer will not come back at all (e.g. one model is replaced by a different model). 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
participants (15)
-
Carlos E. R. -
Chris Rivera -
jdd -
Johannes Meixner -
JP Rosevear -
Klaus Kaempf -
Klaus Singvogel -
Ludwig Nussel -
M9 -
M9.
-
Magnus Boman -
Marcus Meissner -
Patrick Shanahan -
Robert Love -
Sid Boyce