SYSTEMD: Don't mix up responders' socket and monitor activation Let's ensure that in case a responder is explicitly configured in the sssd.conf its socket won't even start. The patchset introduces a new binary that will be distributed and will be called before starting the responders' sockets, ensuring the sockets will only start in case the responder is supposed to be socket-activated and its been configured accordingly. Otherwise the responders' socket startup will fail with a quite helpful debug message leading the admins to choose between using systemd or not and what has to be done to achieve their desire. This suggestion came from Sumit Bose. The reason for adding a new binary instead of a simple python script is to avoid dragging unnecessary dependencies to sssd-common package. Resolves: https://pagure.io/SSSD/sssd/issue/3300 Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com> Reviewed-by: Jakub Hrozek <jhrozek@redhat.com> Reviewed-by: Lukáš Slebodník <lslebodn@redhat.com>

SYSTEMD: Avoid starting a responder socket in case SSSD is not started As systemd adds "Before=sockets.target" to any socket unit by default, during the startup of the system we can end up having a responder socket up, being contacted while SSSD is shutdown. By using "DefaultDependencies=no" we ensure that sockets.target won't trigger the sockets' startup and that it only will be done when SSSD is up. The downside of using "DefaultDependencies=no" is that we have to deal with conflicts and add "Conflicts=shutdown.target" to each of the sockets unit. This patch has been suggested by Lukáš Nykrýn. Related: https://pagure.io/SSSD/sssd/issue/3298 Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com> Reviewed-by: Jakub Hrozek <jhrozek@redhat.com> Reviewed-by: Lukáš Slebodník <lslebodn@redhat.com>

SYSTEMD: Add "After=sssd.service" to the responders' sockets units While debugging the whole breakage reported by Stric I've noticed that the NSS socket has been starting up the NSS responder _before_ SSSD being up. As libc does initgroups on pretty much any account and initgroups checks all NSS modules in order to be precise, the nss_sss triggers the NSS responder which would try talking to the data providers which are not up uet (because SSSD is not up yet), causing the whole process to hang until libc gives up (causing a timeout on services like systemd-logind and on services depending on this one). By adding this ordering explicitly we can avoid the reported situation. Also, it has been recommend by Lukáš Nykrýn that "BindsTo", which is used to tie up two services, and After must be used together in order to avoid undefined/unexpected behavior (although it's still not mentioned in the systemd documentation). Related: https://pagure.io/SSSD/sssd/issue/3298 Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com> Reviewed-by: Jakub Hrozek <jhrozek@redhat.com> Reviewed-by: Lukáš Slebodník <lslebodn@redhat.com>

PAM: Make PAM responder socket-activatable As part of the effort of making all responder socket-activatable, let's make PAM responder ready for this by providing its systemd's units. In case the administrators want to use PAM responder taking advantage of socket-activation they will need to enable sssd-pam.socket and after a restart of the sssd service, the PAM socket will be ready waiting for any activity in order to start the PAM responder. Also, the PAM responder must be removed from the services line on sssd.conf. The PAM responder service is binded to the SSSD service, which means that the responder will be restarted in case SSSD is restarted and shutdown in case SSSD is shutdown/crashes. PAM responder, differently from the others, is a special case as it has two sockets and its private sockets must be owned by root and must have a specifc permission (0600). It's not new, though, and it's following what has been already done in the project.. Related: https://fedorahosted.org/sssd/ticket/2243 Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com> Reviewed-by: Pavel Březina <pbrezina@redhat.com> Reviewed-by: Jakub Hrozek <jhrozek@redhat.com> Reviewed-by: Lukáš Slebodník <lslebodn@redhat.com>