On Mon, Nov 30, 2020 at 9:37 PM Mote, Todd <moter(a)austin.utexas.edu> 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 <atikhono(a)redhat.com>
Sent: Monday, November 30, 2020 1:58 PM
To: End-user discussions about the System Security Services Daemon
<sssd-users(a)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(a)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(a)lists.fedorahosted.org To
> unsubscribe send an email to sssd-users-leave(a)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(a)lists.fedorahosted.org To unsubscribe send an email
to sssd-users-leave(a)lists.fedorahosted.org
Fedora Code of Conduct:
https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.fe...
List Guidelines:
https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedorap...
List Archives:
https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.f...
>> This message is from an external sender. Learn more about why this <<
>> matters at
https://links.utexas.edu/rtyclf. <<
_______________________________________________
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:
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.fedorahoste...