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
_______________________________________________
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org