| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Although I didn't have any problem with this before I'd like to ensure
that the NSS socket is always up _before_ any other (SSSD) services'
sockets as they may trigger initgroups calls as some of them have
SocketUser and SocketGroup set to the "sssd" user.
Related:
https://pagure.io/SSSD/sssd/issue/3322
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Reviewed-by: Lukáš Slebodník <lslebodn@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
NSS service is always run as root, so there's no need to change its
socket ownership to the sssd user.
More than that, by setting up the SocketUser and SocketGroup to "sssd"
a loop would be caused as the "sssd" would trigger an initgroups call
during the NSS socket setup.
The problem was found when starting up a machine with SSSD built with
"--with-sssd-user=sssd" and having "sss" before "files" in the
name-service switch.
Related:
https://pagure.io/SSSD/sssd/issue/3322
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Reviewed-by: Lukáš Slebodník <lslebodn@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
As part of the effort of making all responders socket-activatable, let's
make the NSS responder ready for this by providing its systemd's units.
In case the administrators want to use NSS responder taking advantage
of socket-activation they will need to enable sssd-nss.socket and after
a restart of the sssd service, the NSS socket will be ready waiting for
any activity in order to start the NSS responder. Also, the NSS
responder must be removed from the services line on sssd.conf.
The NSS 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.
Is quite important to mention that NSS responder will always run as
root. The reason behind this is that systemd calls getpwnam() and
getgprnam() when "User="/"Group=" is set to something different than
"root". As it's done _before_ starting NSS responder, the clients would
end up hanging for a few minutes (due to "default_client_timeout"),
which is something that we really want to avoid.
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>
|
