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:
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. bye, Sumit _______________________________________________ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
