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 <[EMAIL PROTECTED]> Novell, Inc. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
