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