On Mon, Nov 30, 2020 at 8:43 PM Mote, Todd moter@austin.utexas.edu wrote:
Hi all
I updated my RHEL 8 test box today and got sssd-2.3.0-9.el8.x86_64 as an update from sssd-2.2.3-20.el8.x86_64. Prior to the upgrade everything worked fine. Immediately after upgrade sssd fails to restart the critical service [sudo], and fails to start sssd at all, as noted in journalctl -xe.
Could you please set "debug_level = 9" in "[sudo]" section of /etc/sssd.conf, restart sssd and provide /var/log/sssd_sudo.log (sanitized if needed)?
Are there things that needs to be done to affect a successful upgrade from 2.2.3 to 2.3.0? a conf file change perhaps? I saw mentions of “required conf file changes” in other issues reported in github.
Downgrading back to 2.2.3 and removing the database returns sssd to starting and working.
Removing “sudo” as a service from sssd.conf allows sssd to start with 2.3.0-9 installed.
I attempted to use “systemctl enable sssd-sudo” like the man page suggests and the result in the journal is “Dependency failed for SSSD Sudo Service responder socket.”
I also noted this in the sssd-sudo man page: “It's important to note that on platforms where systemd is supported there's no need to add the "sudo" provider
to the list of services, as it became optional. However, sssd-sudo.socket must be enabled instead.”
having enabled the sockect and removed “sudo” from the list of services, it does seem to work and retrieve rules from AD for the user.
Is all of this correct? Is removing “sudo” as a service the answer to this or is it just a workaround? If it is the solution, is there any documentation about changes to configurations from version to version like sudo no longer allowing the service to start if it’s explicitly listed as a service?
Just trying to figure out the scope of what will need to change on my fleet. The evidence so far seems to point to just removing “sudo” as a service in sssd.conf. Is that enough? Should “systemctl enable sssd-sudo” be run as well?
Thanks in advance for your insights.
Todd
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.o...
Could you please set "debug_level = 9" in "[sudo]" section of /etc/sssd.conf, restart sssd and provide /var/log/sssd_sudo.log (sanitized if needed)?
Here ya go.
I did verify on a clean install that only removing "sudo" as a service from the sssd.conf file does in fact allow it to work again. Enabling the socket does not seem to be required.
Todd
-----Original Message----- From: Alexey Tikhonov atikhono@redhat.com Sent: Monday, November 30, 2020 1:58 PM To: End-user discussions about the System Security Services Daemon sssd-users@lists.fedorahosted.org Subject: [SSSD-users] Re: sssd upgrade from 2.2.3-20 to 2.3.0-9 breaks sudo
On Mon, Nov 30, 2020 at 8:43 PM Mote, Todd moter@austin.utexas.edu wrote:
Hi all
I updated my RHEL 8 test box today and got sssd-2.3.0-9.el8.x86_64 as an update from sssd-2.2.3-20.el8.x86_64. Prior to the upgrade everything worked fine. Immediately after upgrade sssd fails to restart the critical service [sudo], and fails to start sssd at all, as noted in journalctl -xe.
Could you please set "debug_level = 9" in "[sudo]" section of /etc/sssd.conf, restart sssd and provide /var/log/sssd_sudo.log (sanitized if needed)?
Are there things that needs to be done to affect a successful upgrade from 2.2.3 to 2.3.0? a conf file change perhaps? I saw mentions of “required conf file changes” in other issues reported in github.
Downgrading back to 2.2.3 and removing the database returns sssd to starting and working.
Removing “sudo” as a service from sssd.conf allows sssd to start with 2.3.0-9 installed.
I attempted to use “systemctl enable sssd-sudo” like the man page suggests and the result in the journal is “Dependency failed for SSSD Sudo Service responder socket.”
I also noted this in the sssd-sudo man page: “It's important to note that on platforms where systemd is supported there's no need to add the "sudo" provider
to the list of services, as it became optional. However, sssd-sudo.socket must be enabled instead.”
having enabled the sockect and removed “sudo” from the list of services, it does seem to work and retrieve rules from AD for the user.
Is all of this correct? Is removing “sudo” as a service the answer to this or is it just a workaround? If it is the solution, is there any documentation about changes to configurations from version to version like sudo no longer allowing the service to start if it’s explicitly listed as a service?
Just trying to figure out the scope of what will need to change on my fleet. The evidence so far seems to point to just removing “sudo” as a service in sssd.conf. Is that enough? Should “systemctl enable sssd-sudo” be run as well?
Thanks in advance for your insights.
Todd
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://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs .fedoraproject.org%2Fen-US%2Fproject%2Fcode-of-conduct%2F&data=04% 7C01%7Cmoter%40austin.utexas.edu%7Cf01f8e8df12c460005a208d8956a3d92%7C 31d7e2a5bdd8414e9e97bea998ebdfe1%7C1%7C0%7C637423630815484265%7CUnknow n%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLC JXVCI6Mn0%3D%7C1000&sdata=oceNDHl05MPSDYn52tAb5Mnsqb0bnHKlAO1tpoaU hrE%3D&reserved=0 List Guidelines: https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedo raproject.org%2Fwiki%2FMailing_list_guidelines&data=04%7C01%7Cmote r%40austin.utexas.edu%7Cf01f8e8df12c460005a208d8956a3d92%7C31d7e2a5bdd 8414e9e97bea998ebdfe1%7C1%7C0%7C637423630815484265%7CUnknown%7CTWFpbGZ sb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3 D%7C1000&sdata=WbMFjIprD%2BbYocMn0uoTgOscDL%2Fp4jlH7icPneGL3v8%3D& amp;reserved=0 List Archives: https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist s.fedorahosted.org%2Farchives%2Flist%2Fsssd-users%40lists.fedorahosted .org&data=04%7C01%7Cmoter%40austin.utexas.edu%7Cf01f8e8df12c460005 a208d8956a3d92%7C31d7e2a5bdd8414e9e97bea998ebdfe1%7C1%7C0%7C6374236308 15484265%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Yl5fnjkNmK37oRoQFQhA1Sj XigQNO0orE4IY%2FRe%2FjgA%3D&reserved=0
_______________________________________________ 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://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.fedor... List Guidelines: https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedoraproj... List Archives: https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.fedo...
This message is from an external sender. Learn more about why this << matters at https://links.utexas.edu/rtyclf. <<
sssd-users@lists.fedorahosted.org