On (21/11/19 09:14), Lawrence Kearney wrote:
Lukas et al.,
Firstly reverting the ownership of the sssd service and socket files in the
"/usr/lib/systemd/system" and "/var/lib/sss" directories to sssd:sssd
and
adding the "user = sssd" to the sssd.conf file did resolve the responder
issue.This file ownership model was what I thought should be in place, but
rhel did not install them consistently this way. I implemented the
sssd:root ownerships to resolve some issues with services starting.
Interestingly even after changing the ownerships of the same files to
sssd:sssd the responder still crashed without the user = sssd directive
present in the sssd.conf. I would have thought the daemon on this platform
would not require it.
Sorry If I was not clear. I did not suggest to change owner/permissions of
directories or files
Just to remove "sssd" user and group from systemd service files for sssd
responders
cp /usr/lib/systemd/system/sssd-pam.service /etc/systemd/system/sssd-pam.service
#modify file /etc/systemd/system/sssd-pam.service
e.g.
[Unit]
Description=SSSD PAM Service responder
Documentation=man:sssd.conf(5)
After=sssd.service
BindsTo=sssd.service
RefuseManualStart=true
[Install]
Also=sssd-pam.socket sssd-pam-priv.socket
[Service]
Environment=DEBUG_LOGGER=--logger=files
EnvironmentFile=-/etc/sysconfig/sssd
ExecStartPre=-/bin/chown root:root /var/log/sssd/sssd_pam.log
ExecStart=/usr/libexec/sssd/sssd_pam ${DEBUG_LOGGER} --socket-activated
Restart=on-failure
User=root
Group=root
PermissionsStartOnly=true
systemctl daemon-reload
That said, my experience on other platforms is the daemon runs as
root, so
this is useful to know for additional testing with other distributions, so
thank you.
Different distributions build packages with different flags.
As to the use case discussion, most of my experience and assistance
in
deployments are direct integration models. Not that I have a technical
issue with the indirect approach, but most organisations I encounter prefer
the reduced complexity of the direct model. As long as it works reliably.
There are feature trade offs using this method but most are okay given
those choices are communicated.
I am still not sure how socket activated responders would help here.
That said, when you stand up sssd as a client against a large,
mature,
complex directory service any thing you can do to reduce the load on the
clients and the directory service is a good step. Filtering search results
across purposefully configured hosts and reducing load on the client and
the directory service are key design components of this proposition.
You still need to provide sssd.conf for each host.
(and whether there is a line with "services" is a minimal change)
So, I'm curious if the socket based responders can play a
meaningful part
in optimisation.
An addition question that may help me. What are your thoughts on the use
case(s) for the socket based responders?
I would say it in this way.
If distributions though that socket activated responders are tested enough
hey would enable it by default.
LS