On Tue, Nov 29, 2016 at 11:28 AM, Sumit Bose <[email protected]> wrote: > 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/[email protected]/message/H6JOF5SGGSIJUIWYNANDA73ODHWBS7J2/ >> [2]: https://github.com/SSSD/sssd/pull/84 >> >> The full text of c&p here: > > Hi Fabiano, > > thank you for the design page. > >> >> = Socket Activatable Responders = >> > ... >> ==== KCM ==== >> The KCM responder is only seldom needed, when libkrb5 needs to access > > I'm not sure id 'seldom' is correct here. It will be used by mainly > during authentication but since it might be to default storage for any > Kerberos credential it will be use by the user for any kind of > Kerberos/GSSAPI related authentication to services. > >> 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. >> > > But my main question is about the monitor and > /var/lib/sss/db/config.ldb. If I understand the design correctly the > monitor will still run and create config.ldb which is good because then > all socket-activated components will see the same config. So a > configuration change required a restart of the monitor. How will the > socket activated services handled in this case. Will the monitor shut > them down or is systemd smart enough to see that the "parent" service is > shut down and will shutdown the children as well.
systemd is smart enough to do that, or almost. :-) Having "PartOf=sssd.service" as part of responders' unit files is enough to make then restart/shutdown any time systemd is restarted/shutdown. Best Regards, _______________________________________________ sssd-devel mailing list -- [email protected] To unsubscribe send an email to [email protected]
