User Account Management

Registered by Robert Ancell on 2009-10-23

Provide an improved API for managing user accounts. Update applications like GDM, user switch applet, user and group administration tool to use this API.

Blueprint information

Status:
Complete
Approver:
Martin Pitt
Priority:
Low
Drafter:
Robert Ancell
Direction:
Needs approval
Assignee:
Robert Ancell
Definition:
Obsolete
Series goal:
None
Implementation:
Deferred
Milestone target:
None
Completed by
Robert Ancell on 2011-11-10

Related branches

Sprints

Whiteboard

https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-lucid-user-account-management

https://wiki.ubuntu.com/DesktopTeam/Specs/Lucid/UserAccountManagement

 = Requirements =
   * User object:
     * Name
     * Home directory
     * Contact information (phone, address, jabber etc)
     * Image
     * Logged in status
     * Notification of user add/remove/update
     * Must support large number of users and information in remote locations
       without blocking/excessive network/filesystem access
   * Data sources
    * <jedi wave>there is no /etc/passwd - use NSS
    * Do not enumerate home directories!! or at least provide an async API for
      only scanning a subset for an icon (like if you only show the top 5 users
      in gdm, request to scan only those)
    * enumerating the number of users may even be a costly operation
    * Needs multiple backends for different OS, like using adduser on Debian/Ubuntu (but please not in the "dynamic crazy" way of s-t-b; build time configuration seems appropriate?)
   * Data consumers
     * Login manager
     * User admin tool
     * User switcher
     * about me
     * gnome-screensaver?
     * No other use cases?

 = Linking Telepathy and local users =
   * No use case?

 * Investigate existing/future efforts
   * Overlap with system-config-backends? (for users-admin backend)
   * https://fedoraproject.org/wiki/Features/SSSD
   * http://fedoraproject.org/wiki/Features/UserAccountDialog
   * freedesktop effort?

= Structure =

Should be a separate project, not built into gdm; that way, it is kept as non-interactive, non-GTK-dependent project shareable with KDE/XFCE, etc., and can also have noninteractive test suite

gdm's code would become much cleaner then, too

Implementing in Python is pretty expensive wrt. startup cost if this daemon gets activated often during sessions -> glib/C? vala?

 = Conclusions =
  * No resource for Lucid, reschedule for Lucid+1?
  * Limited number of applications to make use of it
  * Good candidate for shared effort with KDE/freedesktop

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.