Hey fabiano,
There are couple of spelling mistakes(*Bo**ld*) on DesignDoc Page:
consists in marking the service as started, increasing the services'
counter, getting the responder's *configuratiom*, <====
he change in the responders' common code is quite trivial, just *chnage*
the sss_process_init code to call activate_unix_sockets() <========
Thanks
On 11/25/2016 04:34 AM, Fabiano Fidêncio wrote:
On Thu, Nov 24, 2016 at 2:33 PM, Fabiano Fidêncio
<fidencio(a)redhat.com> wrote:
> 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/sssd-devel@lists.fedorahoste...
> [2]:
https://github.com/SSSD/sssd/pull/84
Well, PR#94:
https://github.com/SSSD/sssd/pull/94
> 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>
>
> Best Regards,
> --
> Fabiano Fidêncio
> _______________________________________________
> sssd-devel mailing list -- sssd-devel(a)lists.fedorahosted.org
> To unsubscribe send an email to sssd-devel-leave(a)lists.fedorahosted.org
Best Regards,