[SSSD] Design document - Socket-activatable responders

[Fabiano Fidêncio]

The design page is done [0] and it's based on this discussion [1] we
had on this very same mailing list. A pull-request with the
implementation is already opened [2].

[0]: https://fedorahosted.org/sssd/wiki/DesignDocs/SocketActivatableResponders
[1]:
https://lists.fedorahosted.org/archives/list/[e-mail]...
[2]: https://github.com/SSSD/sssd/pull/84

The full text of c&p here:

= Socket Activatable Responders =

Related ticket(s):
 * https://fedorahosted.org/sssd/ticket/2243
 * https://fedorahosted.org/sssd/ticket/3129

=== Problem statement ===
SSSD has some responders which don't have to be running all the time,
but could be socket-activated instead in platforms where it's
supported. That's the case, for instance, for the IFP, ssh and sudo
responders.
Making these responders socket-activated would provide a better use
experience, as these services could be started on-demand when a client
needs them and exist after a period of inactivity. Currently the admin
has to explicitly list all the services that might potentially be
needed in the `services` section and the processes have to be running
all the time.

=== Use cases ===

==== sssctl  ====
As more and more features that had been added depending on the IFP
responder, we should make sure that the responder is activated on
demand and the admins doesn't have to activate it manually.

==== KCM ====
The KCM responder is only seldom needed, when libkrb5 needs to access
the credentials store. At the same time, the KCM responder must be
running if the Kerberos credentials cache defaults to `KCM`.
Socket-activating the responder would solve both of these cases.

==== autofs ====
The autofs responder is typically only needed when a share is about to
be mounted.

=== Overview of the solution ===
The solution agreed on the mailing list is to add a new unit for each
one of the responders. Once a responder is started, it will
communicate to the monitor in order to let the monitor know that it's
up and the monitor will do the registration of the responder, which
basically consists in marking the service as started, increasing the
services' counter, getting the responder's configuratiom, adding the
responder to the service's list.
A configurable idle timeout will be implemented in each responder, as
part of this task, in order to exit the responder in case it's not
used for a few minutes.

=== Implementation details ===
In order to achieve our goal we will need a small modification in
responders' common code in order to make it ready for
socket-activation, add some systemd units for each of the responders
and finally small changes in the monitor code in order to manage the
new activated service.

The change in the responders' common code is quite trivial, just
chnage the sss_process_init code to call activate_unix_sockets()
istead of set_unix_socket(). Something like:
{{{
-    ret = set_unix_socket(rctx, conn_setup);
+    ret = activate_unix_sockets(rctx, conn_setup);
}}}

The units that have to be added for each responder must look like:

sssd-@responder@.service.in:
{{{
[Unit]
Description=SSSD @responder@ Service responder
Documentation=man:sssd.conf(5)
Requires=sssd.service
PartOf=sssd.service
After=sssd.service

[Install]
Also=sssd-@responder@.socket

[Service]
ExecStart=@libexecdir@/sssd/sssd_@responder@ --uid 0 --gid 0 --debug-to-files
}}}

sssd-@responder@.socket.in:
{{{
[Unit]
Description=SSSD @responder@ Service responder socket
Documentation=man:sssd.conf(5)

[Socket]
ListenStream=@pipepath@/@responder@

[Install]
WantedBy=sockets.target
}}}

Some responders may have more than one socket, which is the case of
PAM, so another unit will be needed.

sssd-@responder(a)-priv.socket.in:
{{{
[Unit]
Description=SSSD @responder@ Service responder private socket
Documentation=man:sssd.conf(5)

[Socket]
ListenStream=@pipepath@/private/@responder@

[Install]
WantedBy=sockets.target
}}}

Last but not least, the IFP responder doesn't have a socket. It's
going to be D-Bus activated and some small changes will be required on
its D-Bus service unit.
{{{
-Exec=@libexecdir@/sssd/sss_signal
+Exec=@libexecdir@/sssd/sssd_@responder@
}}}

And, finally, the code in the monitor side will have to have some
adjustments in order to properly deal with an empty list of services
and, also, to register the service when it's started.

As just the responders' will be socket-activated for now, the service
type will have to exposed and passed through sbus when calling the
RegistrationService method and the monitor will have to properly do
the registration of the service when RegistrationService's callback is
triggered. As mentioned before, the "registration" that has to be done
from the monitor's side is:
 * Mark the service as started;
 * Increase the services' counter;
 * Get the responders' configuration;
 * Set the service's restart number;
 * Add the service to the services' list.

=== Configuration changes ===
After this design is implemented, the "services" line in sssd.conf
will become optional for platforms where systemd is present. Note that
in order to keep backward compatibility, if the "services" line is
present, the services will behave exactly as they did before these
changes.

=== How To Test ===
The easiest way to test is removing the "services" line from sssd.conf
and try to use SSSD normally.
Using sssctl tool without having the ifp responder set in the
"services" line is another way to test.

=== How To Debug ===
The easiest way to debug this new feature is taking a look on the
responders' common initialization code and in the monitors' client
registration code.
Is worth to mention that disabling the systemd's services/sockets will
prevent the responders' services to be started.

=== Authors ===
Fabiano Fidêncio <fidencio(a)redhat.com&gt;

Best Regards,
--
Fabiano Fidêncio