On Thu, 2008-05-22 at 13:59 -0400, Matthias Clasen wrote:
We (Jon McCann and myself, with some input from others) have been
working on a design for a new user management tool, with the goal of
coming up with something better than the current trias of
system-config-users, gnome-about-me and gdmsetup.
The design is not finalized, you can see the current state of affairs
here:
http://people.redhat.com/mclasen/user-account3.pdf.bz2
(I really wanted to put this on the wiki, but all I could only get proxy
errors when trying to do so).
Comments are welcome. Please note the section on target audience and use
cases.
[...]
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.
Another use case is temporary access to a computer (guest account).
The proposed workflow
for this is to offer a "Guest" user on the login screen. Selecting this user
will not ask for a
password, the account will have limited privileges (Account type: Guest), and all data
will be
removed at the end of the session, unless the user chooses 'Convert to normal
account' from the
menu of the userswitch applet. Todo: this is not reflected in the screenshots below.
I trust that the ability to convert a guest account to a normal one
would be protected by an appropriate amount of PolicyKit ;-)?
The Name field is first, since we expect the full name to be entered
first. The tool then
generates a Unix username from the full name and prefills the Short Name field. There was
some idea to define a set of rules for this (e.g. Matthias Clasen→mclasen or Jon
McCann→jonm) and update the currently used rule based on the corrections that are made to
the pregenerated username. We do need to validate the Name and Short Name fields to
ensure
that there are no conflicts with existing users. While it is technically possible to have
two users
with the same Name, we at last want to ask 'Did you really mean to do this ?'.
Ignoring technical possibility (which is just a side effect of that the
full name has no bearing w.r.t. the Unix side of things), we shouldn't
allow this, to avoid confusion about which "John Doe" a user should log
into in the login greeter.
Likewise, the home directory, the uid and gid, the shell, and other
uninteresting pieces of
legacy information will be automatically determined by the tool and/or the service.
People who
have a strong interest in these will probably be better served by useradd anyway.
... or a suitable different frontend ;-).
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, ...}!").
The Account Type field associates (still to be implemented) PolicyKit
'roles' with the account.
The Password field shows information about the kind of password that is currently set.
The
password change dialog is a bit more complicated than the other change dialogs, and is
discussed in a separate section below.
The Email, Language and Location fields are here because they are frequently useful (e.g.
the
language is needed on the login screen to relieve gdm from storing this information in
.dmrc).
Also, they are part of the standard LDAP user schema. Todo: these dialogs should perhaps
provide some hints as to how these fields are used. E.g. entering an email address here
does
not create an email account or set up the mail client to use it.
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.
The Parental Controls field is just an idea that needs to be fleshed
out.
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 service will certainly have the expected Create, Delete, Modify
functions dealing with
individual users. It is wellknown that it is a bad idea to have a enumerateallusers
function,
since the cost may be prohibitive and user interfaces that rely on such a function will
simply
not work in large deployments (cf fastuserswitchapplet 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, ...
By the same token,
exposing every user as a dbus object will not work very well in such situations. One idea
(inspired by LDAP again) is to have a Query function that allows querying for users by
certain
criteria.
... which would return the list of user names and create the matching
dbus objects? Sounds sensible to me.
Nils
--
Nils Philippsen / Red Hat / nphilipp(a)redhat.com
"Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759
PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011