On Mon, Nov 30, 2020 at 9:37 PM Mote, Todd <[email protected]> wrote:
>
> > 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.

[sbus_dbus_request_name] (0x0020): Unable to request name on the system bus [3]
This error code (3) stands for `DBUS_RELEASE_NAME_REPLY_NOT_OWNER ` here.
This is expected if you didn't disable systemd sssd-sudo service.

Did you have it enabled when you upgraded?


>
> 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 <[email protected]>
> Sent: Monday, November 30, 2020 1:58 PM
> To: End-user discussions about the System Security Services Daemon 
> <[email protected]>
> 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 <[email protected]> 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 -- [email protected] To
> > unsubscribe send an email to [email protected]
> > Fedora Code of Conduct:
> > https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs
> > .fedoraproject.org%2Fen-US%2Fproject%2Fcode-of-conduct%2F&amp;data=04%
> > 7C01%7Cmoter%40austin.utexas.edu%7Cf01f8e8df12c460005a208d8956a3d92%7C
> > 31d7e2a5bdd8414e9e97bea998ebdfe1%7C1%7C0%7C637423630815484265%7CUnknow
> > n%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLC
> > JXVCI6Mn0%3D%7C1000&amp;sdata=oceNDHl05MPSDYn52tAb5Mnsqb0bnHKlAO1tpoaU
> > hrE%3D&amp;reserved=0 List Guidelines:
> > https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedo
> > raproject.org%2Fwiki%2FMailing_list_guidelines&amp;data=04%7C01%7Cmote
> > r%40austin.utexas.edu%7Cf01f8e8df12c460005a208d8956a3d92%7C31d7e2a5bdd
> > 8414e9e97bea998ebdfe1%7C1%7C0%7C637423630815484265%7CUnknown%7CTWFpbGZ
> > sb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3
> > D%7C1000&amp;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&amp;data=04%7C01%7Cmoter%40austin.utexas.edu%7Cf01f8e8df12c460005
> > a208d8956a3d92%7C31d7e2a5bdd8414e9e97bea998ebdfe1%7C1%7C0%7C6374236308
> > 15484265%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL
> > CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=Yl5fnjkNmK37oRoQFQhA1Sj
> > XigQNO0orE4IY%2FRe%2FjgA%3D&amp;reserved=0
> _______________________________________________
> sssd-users mailing list -- [email protected] To unsubscribe 
> send an email to [email protected]
> Fedora Code of Conduct: 
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.fedoraproject.org%2Fen-US%2Fproject%2Fcode-of-conduct%2F&amp;data=04%7C01%7Cmoter%40austin.utexas.edu%7Cf01f8e8df12c460005a208d8956a3d92%7C31d7e2a5bdd8414e9e97bea998ebdfe1%7C1%7C0%7C637423630815484265%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=oceNDHl05MPSDYn52tAb5Mnsqb0bnHKlAO1tpoaUhrE%3D&amp;reserved=0
> List Guidelines: 
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedoraproject.org%2Fwiki%2FMailing_list_guidelines&amp;data=04%7C01%7Cmoter%40austin.utexas.edu%7Cf01f8e8df12c460005a208d8956a3d92%7C31d7e2a5bdd8414e9e97bea998ebdfe1%7C1%7C0%7C637423630815484265%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=WbMFjIprD%2BbYocMn0uoTgOscDL%2Fp4jlH7icPneGL3v8%3D&amp;reserved=0
> List Archives: 
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.fedorahosted.org%2Farchives%2Flist%2Fsssd-users%40lists.fedorahosted.org&amp;data=04%7C01%7Cmoter%40austin.utexas.edu%7Cf01f8e8df12c460005a208d8956a3d92%7C31d7e2a5bdd8414e9e97bea998ebdfe1%7C1%7C0%7C637423630815484265%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=Yl5fnjkNmK37oRoQFQhA1SjXigQNO0orE4IY%2FRe%2FjgA%3D&amp;reserved=0
> >> This message is from an external sender. Learn more about why this <<
> >> matters at https://links.utexas.edu/rtyclf.                        <<
> _______________________________________________
> sssd-users mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
> 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/[email protected]
_______________________________________________
sssd-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
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/[email protected]

Reply via email to