On Thu, Nov 24, 2016 at 2:33 PM, Fabiano Fidêncio <[email protected]> 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/[email protected]/message/H6JOF5SGGSIJUIWYNANDA73ODHWBS7J2/ > [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-@[email protected]: > {{{ > [Unit] > Description=SSSD @responder@ Service responder > Documentation=man:sssd.conf(5) > Requires=sssd.service > PartOf=sssd.service > After=sssd.service > > [Install] > Also=sssd-@[email protected] > > [Service] > ExecStart=@libexecdir@/sssd/sssd_@responder@ --uid 0 --gid 0 --debug-to-files > }}} > > sssd-@[email protected]: > {{{ > [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-@[email protected]: > {{{ > [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 <[email protected]> > > Best Regards, > -- > Fabiano Fidêncio > _______________________________________________ > sssd-devel mailing list -- [email protected] > To unsubscribe send an email to [email protected] Best Regards, -- Fabiano Fidêncio _______________________________________________ sssd-devel mailing list -- [email protected] To unsubscribe send an email to [email protected]
