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
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.
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
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.
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.
So, I'm curious if the socket based responders can play a meaningful part
An addition question that may help me. What are your thoughts on the use
case(s) for the socket based responders?
On Thu, Nov 21, 2019 at 5:16 AM Lukas Slebodnik <lslebodn(a)redhat.com> wrote:
On (20/11/19 11:57), Lawrence Kearney wrote:
>Lukas et al.,
>Thank you for the suggestion. I'll test that as soon as convenient. I'm
>currently attending SC19 so spinning up labs is something best managed in
>the mornings with coffee :-) .
>Curiously I did have to change the ownership of the socket, and a few
>service, unit files to sssd:root to get them to start. I would like to
>the daemon to running as an unprivileged user as much as possible. I did
>not consider digging into the files themselves to check configured runtime
>users, I should've.
Using "hybrid" sssd:root is not a good idea.
You should either remove sssd user/group from service files
or run sssd as completely unprivileged user.
>As to your question I currently have no real use case for the socket based
>responders other than their potential for system level optimisation in
>large enterprise deployments and kicking the tyres on the SSSD feature set
>to both experiment with it and document the assessment, results, and
>configuration nuances and requirements.
And I an exactly interested in that real use-case :-)
Could you share a little bit more even thought you did not test it?
Because there might be other solution to the problem you would like to
sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
Fedora Code of Conduct:
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines