... that is a good point :-) .
-- lawrence
On Thu, Nov 21, 2019, 7:56 AM Lukas Slebodnik <lsleb...@redhat.com> wrote:
> 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-le...@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
>
_______________________________________________
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@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
