On Thu, Nov 24, 2016 at 02:33:04PM +0100, Fabiano Fidêncio 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.fedorahosted.org/message/H6JOF5SGGSIJUIWYNANDA73ODHWBS7J2/ > [2]: https://github.com/SSSD/sssd/pull/84 > > The full text of c&p here:
In general looks good to me, but note that I was involved a bit with Fabiano in the discussion, so my view might be tainted. The only question I have is actually something Stephen asked during review of the KCM design page -- there might be a situation where a periodic timer (like credentials renewal in KCM) might conflict with socket-activated responder time out. At worst, we can just disable the time out, or we can explore Stephen's suggestion there or do something else. But this problem is worth keeping in mind. > > = 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-@respon...@.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-@respon...@.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-@respon...@-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 <fiden...@redhat.com> > > Best Regards, > -- > Fabiano Fidêncio > _______________________________________________ > sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org > To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org _______________________________________________ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
