A new user management tool

[Matthias Clasen]

On Fri, 2008-05-23 at 12:23 +0200, Nils Philippsen wrote:

> 
> > The target usage scenarios are home and smb, not enterprise customers and big deployments, 
> > although we do need to make sure that the tools not totally break down when used in a big 
> > deployment scenario, since users should still be able to use it for changing their own account. 
> > But we do expect system administrators in enterprise settings to use a web interface to their 
> > directory server, not this tool.
> 
> That's a pretty daring assumption IMO. I don't think that there should
> be one tool for both home/smb and enterprise (or home and
> smb/enterprise, but I digress ;-), but I'm not sold to the idea that
> enterprise admins will want to use web interfaces over native tools
> anytime soon, assuming that native interfaces will always outperform web
> interfaces for the same job (more performance with a given level of
> convenience, or more convenience with given level of performance). And,
> just as a datapoint, there are people using s-c-users against an LDAP
> directory ;-). I'd like to think that a backend handling the
> conventional passwd type of stuff should be able to cater for more than
> one use case. This would make it fairly easy to implement several UIs on
> top of it for the different use cases: graphical home/smb and
> enterprise, text-mode and what have you -- and I'm pretty sure that
> we'll (have to) end up with something like that anyway. Whether or not
> that same backend would handle the non-Unix properties of users would
> need some dicussion, I don't have a firm opinion on that one.

The backend needs to be flexible enough to support more
enterprise-oriented frontends, sure. Perhaps that hasn't been stated
clearly enough. Wrt to storage, I think we are pretty much within the
standard LDAP user schema.

> I trust that the ability to convert a guest account to a normal one
> would be protected by an appropriate amount of PolicyKit ;-)?

Of course.

> > Clicking on the face image brings up a dialog for selecting the user image which offers a set of  
> > predefined images, as well as an option to use a webcam (if available), a simple drawing tool  
> > (such as MeMaker) or pick an image from the filesystem. Fine point: when showing the 
> > predefined faces, we should indicate which ones are already 'taken'. This dialog has not been 
> > mocked up yet. 
> > When creating a new user, it initially gets a randomly picked image from the predefined 
> > images  (excluding those that are already used for a different user) 
> 
> I don't think that's a good idea, as there are too many ways to
> unintentionally insult people by picking the wrong one, even  colors can
> have bad connotations in some cultures ("Your @*§$"!§%" tool picked {a
> monkey, something green, ...} for my account, now I'll {have your guts,
> not do any business with you again, ...}!").

Or maybe we just make the business customers use the other frontend...

> At least for some SMBs (those who don't trust Google/Yahoo/... with
> their mails), a user mgmt tool should at some point (by way of a plugin
> or else) do exactly that, e.g. log into the company's cyrus-imapd and
> create a mailbox for the user. Maybe that's better suited for the
> enterprisey kind of user mgmt tool, however.

In fact, an earlier draft of the design had the idea of plugins for this
kind of setup tasks. Maybe we'll have to revisit it. 
For the client-side email setup, I guess you could get 90% of the way
there sabayon - just give the user a sabayon profile that has all the
mail configuration set up except for the email address, that evolution
can then pick up from the user service... 

> > Beyond direct user management, we also want the new tool to take up some login screen 
> > configuration (which is, after all, more or less related to users and passwords).
> 
> Shouldn't that be somehow done in the login greeter so you directly see
> your changes (suitably authenticated of course)?

The old gdm had something like that, and it was not very nice. Maybe it
was just not very well done, with the configuration options being
directly visible in a toolbar on the greeter, and all gtk themes in a
long menu...

> > The service will certainly have the expected Create, Delete, Modify functions dealing with 
> > individual users. It is well­known that it is a bad idea to have a enumerate­all­users function, 
> > since the cost may be prohibitive and user interfaces that rely on such a function will simply 
> > not work in large deployments (cf fast­user­switch­applet vs NIS).
> 
> Which makes "Show list of users" in the login settings kind of dead in
> the water, unless that list of users is somehow limited, e.g. to people
> who were logged into the system in a certain timeframe (e.g. since 4
> weeks before the last successful login), and/or people who have been
> created on that system, ...

...which is pretty much exactly what the user list in the greeter
already does.