We have an in-house created rpm that sets up everything needed for sssd, krb, the conf
file, etc. due to having all the way from rhel6 to rhel 8 in our environment, and the rpm
requires sssd >= 1.14 I think. RHEL 8 installs sssd 2.2.3, sets up everything, adds
all the files and all the paths for sudo to the cond files, etc., does the join, then at
the end of the kickstart it does yum update and upgrades it to 2.3.0, and the system,
after deployment, leaves sssd not working.
This is how it looks just after deployment
systemctl status sssd-sudo
● sssd-sudo.service - SSSD Sudo Service responder
Loaded: loaded (/usr/lib/systemd/system/sssd-sudo.service; indirect; vendor preset:
disabled)
Active: inactive (dead)
Docs: man:sssd.conf(5)
man:sssd-sudo(5)
so seems to be disabled, but loaded?
At this point, I can either downgrade to sssd 2.2.3, remove the db, and restart sssd,
making no other changes, and sssd 2.2.3 loads and works as I expect it to
Or
I can edit sssd.conf and remove sudo as a service, remove the db, and restart sssd, making
no other changes, and sssd 2.3.0 loads and works as I expect it to.
Todd
-----Original Message-----
From: Alexey Tikhonov <atikhono(a)redhat.com>
Sent: Monday, November 30, 2020 2:52 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 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%2Fdo
> cs
> .fedoraproject.org%2Fen-US%2Fproject%2Fcode-of-conduct%2F&data=0
> 4%
> 7C01%7Cmoter%40austin.utexas.edu%7Cf01f8e8df12c460005a208d8956a3d92%
> 7C
> 31d7e2a5bdd8414e9e97bea998ebdfe1%7C1%7C0%7C637423630815484265%7CUnkn
> ow
> n%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwi
> LC
> JXVCI6Mn0%3D%7C1000&sdata=oceNDHl05MPSDYn52tAb5Mnsqb0bnHKlAO1tpo
> aU
> hrE%3D&reserved=0 List Guidelines:
>
https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffe
> do
> raproject.org%2Fwiki%2FMailing_list_guidelines&data=04%7C01%7Cmo
> te
> r%40austin.utexas.edu%7Cf01f8e8df12c460005a208d8956a3d92%7C31d7e2a5b
> dd
> 8414e9e97bea998ebdfe1%7C1%7C0%7C637423630815484265%7CUnknown%7CTWFpb
> GZ
> sb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0
> %3
> D%7C1000&sdata=WbMFjIprD%2BbYocMn0uoTgOscDL%2Fp4jlH7icPneGL3v8%3
> D&
> amp;reserved=0 List Archives:
>
https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fli
> st
> s.fedorahosted.org%2Farchives%2Flist%2Fsssd-users%40lists.fedorahost
> ed
> .org&data=04%7C01%7Cmoter%40austin.utexas.edu%7Cf01f8e8df12c4600
> 05
> a208d8956a3d92%7C31d7e2a5bdd8414e9e97bea998ebdfe1%7C1%7C0%7C63742363
> 08
> 15484265%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzI
> iL
> CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Yl5fnjkNmK37oRoQFQhA1
> Sj
> 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
.fedoraproject.org%2Fen-US%2Fproject%2Fcode-of-conduct%2F&data=04%
7C01%7Cmoter%40austin.utexas.edu%7C97c6c3a3314b4db7b1f908d89571dbb0%7C
31d7e2a5bdd8414e9e97bea998ebdfe1%7C1%7C0%7C637423663534337090%7CUnknow
n%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLC
JXVCI6Mn0%3D%7C1000&sdata=4cEksddCWG1FE2grSho5Rq1D8ozAvpYots4l5W1P
YZU%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%7C97c6c3a3314b4db7b1f908d89571dbb0%7C31d7e2a5bdd
8414e9e97bea998ebdfe1%7C1%7C0%7C637423663534337090%7CUnknown%7CTWFpbGZ
sb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3
D%7C1000&sdata=B%2FMEGD4j2%2Ba9L0DJPhZVtAZqcff6lX5%2BqmwTCBLLEAw%3
D&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%7C97c6c3a3314b4db7b1
f908d89571dbb0%7C31d7e2a5bdd8414e9e97bea998ebdfe1%7C1%7C0%7C6374236635
34347089%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL
CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=sH3ponuPgAATyTVWPnuJLkF
Z1aLkDfPpF2ViYV7ig2E%3D&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 -- 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%7C97c6c3a3314b4db7b1f908d89571dbb0%7C
31d7e2a5bdd8414e9e97bea998ebdfe1%7C1%7C0%7C637423663534347089%7CUnknow
n%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLC
JXVCI6Mn0%3D%7C1000&sdata=Y42vA1NdOaa5NAH3j3YanIsN5TAyKjMrNSsBH8OZ
Hn4%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%7C97c6c3a3314b4db7b1f908d89571dbb0%7C31d7e2a5bdd
8414e9e97bea998ebdfe1%7C1%7C0%7C637423663534347089%7CUnknown%7CTWFpbGZ
sb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3
D%7C1000&sdata=NdyTXynsAzON%2B2bgwkLzn2vQ%2BuFXAYwVab7RBgEeHqE%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%7C97c6c3a3314b4db7b1
f908d89571dbb0%7C31d7e2a5bdd8414e9e97bea998ebdfe1%7C1%7C0%7C6374236635
34347089%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL
CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=sH3ponuPgAATyTVWPnuJLkF
Z1aLkDfPpF2ViYV7ig2E%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. <<