Nothing on this page truly exists. It contains only ramblings on what SSSD might become in the future. These are mostly unordered notes.

SSSD 2.0

Major themes

  • Powered by systemd wherever possible
  • Eliminate the monitor process
  • Support socket activation and idle termination
  • Simplify configuration
  • Fast support for local users

systemd

This init system supports many powerful features that could make large parts of SSSD infrastructure irrelevant.

  • Supports process monitoring and automatic restart
  • Can support chaining multiple child processes together
  • Manages socket-activation for registered processes
  • Supports kdbus for secure and fast D-BUS communication between processes

Process start-up

  • Use the sssd process (formerly the monitor) solely to parse sssd.conf and convert it to the config LDB, which the other processes will be able to read at startup.
  • Eliminate the services= line. All supported responders should simply be invoked (socket-activated) when their client asks for them and then proceed according to the config LDB (which may just tell it to terminate again with an appropriate error reply)
  • We may want to load different providers as separate processes to make it easier to decide when to terminate them. It would be better to rethink whether it makes more sense to have one process per domain as opposed to one process per configured provider back-end.
  • systemd now has a D-BUS method for setting up persistent or non-persistent units (such as service units), so we can take advantage of this to start up only the processes we really need.

idle termination

Shutting down any SSSD process that is not actively doing work would be advantageous for several reasons (most notably memory and CPU resource reduction during idle periods). Designing for this would also force us to optimize for making SSSD operations stateless (or at least tracking in-progress operations more carefully).

Some random thoughts on provider implementations:

  • LDAP provider (and derivatives) should auto-terminate once the the ldap_connection_expire_timeout is reached, since we can then assume that nothing has been happening on the connection for quite some time (15 minutes by default).
  • Other providers should terminate after a similar reasonable amount of time.
  • Providers that have computationally-rare periodic tasks (such as cache cleanup or kerberos ticket renewal) should be stored in a persistent manner between process startups and should automatically be invoked if their period has passed. We can take advantage of systemd timer units to have the process periodically woken up to process these events, rather than simply holding the process alive and idle for long periods.

Local users

  • We need to rework the local provider to behave more similarly to the other providers (even if this just means a provider backend that always returns “offline”). This way, the local id_provider can be configured with other providers like kerberos.
  • We need to optimize the local user behavior such that it is acceptable to have sss first in the nsswitch.conf lines everywhere. This will solve the performance problem caused by disabling nscd for local users (which results in disk reads for all lookups prior to trying sssd)
  • We need to work on ​https://sourceware.org/glibc/wiki/Proposals/GroupMerging and finish it.

Enumeration

Enumeration mode should be deprecated in SSSD 2.0 with a strong recommendation being placed on a D-BUS API for doing enumeration that supports paging and filtering. Most uses of enumeration are for presenting a user/group list in a UI, so this will be a better fit for that anyway.

SBUS

The original point-to-point SBUS should be retired. Now that SSSD supports running as non-root, we should instead set up a session bus and use that (which will also be advantageous as we get into the kdbus-enabled world).