Bug 1053861
| Summary: | SSSD is enabled by default but fails to start by default | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Ray Strode [halfline] <rstrode> | ||||||||
| Component: | authconfig | Assignee: | Tomas Mraz <tmraz> | ||||||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | David Spurek <dspurek> | ||||||||
| Severity: | medium | Docs Contact: | |||||||||
| Priority: | high | ||||||||||
| Version: | 7.0 | CC: | dpal, dspurek, ebenes, eber67, grajaiya, jgalipea, ksrot, lslebodn, mkosek, pbrezina, preichl, rstrode | ||||||||
| Target Milestone: | rc | ||||||||||
| Target Release: | --- | ||||||||||
| Hardware: | Unspecified | ||||||||||
| OS: | Unspecified | ||||||||||
| Whiteboard: | |||||||||||
| Fixed In Version: | authconfig-6.2.8-8.el7 | Doc Type: | Bug Fix | ||||||||
| Doc Text: | Story Points: | --- | |||||||||
| Clone Of: | Environment: | ||||||||||
| Last Closed: | 2014-06-13 10:40:36 UTC | Type: | Bug | ||||||||
| Regression: | --- | Mount Type: | --- | ||||||||
| Documentation: | --- | CRM: | |||||||||
| Verified Versions: | Category: | --- | |||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||
| Embargoed: | |||||||||||
| Attachments: |
|
||||||||||
|
Description
Ray Strode [halfline]
2014-01-15 20:55:13 UTC
I tend to agree that SSSD shouldn't be enabled out of the box unless configured (and then enabled) by realmd. Actually the chkconfig by default is not the biggest issue, I think, but can you find out from the system who pulled in SSSD? realmd should be able to automatically install sssd when required. repoquery --whatrequires \*sss\* on a RHEL-7 system gives me: docbook-utils-0:0.6.14-36.el7.noarch ipa-client-0:3.3.3-12.el7.x86_64 ipa-server-trust-ad-0:3.3.3-12.el7.x86_64 libsss_idmap-devel-0:1.11.2-27.el7.i686 libsss_idmap-devel-0:1.11.2-27.el7.x86_64 libsss_nss_idmap-devel-0:1.11.2-27.el7.i686 libsss_nss_idmap-devel-0:1.11.2-27.el7.x86_64 libsss_nss_idmap-python-0:1.11.2-27.el7.x86_64 slapi-nis-0:0.52-2.el7.x86_64 sssd-0:1.11.2-27.el7.x86_64 sssd-ad-0:1.11.2-27.el7.x86_64 sssd-common-0:1.11.2-27.el7.i686 sssd-common-0:1.11.2-27.el7.x86_64 sssd-common-pac-0:1.11.2-27.el7.x86_64 sssd-ipa-0:1.11.2-27.el7.x86_64 sssd-krb5-0:1.11.2-27.el7.x86_64 sssd-krb5-common-0:1.11.2-27.el7.x86_64 sssd-ldap-0:1.11.2-27.el7.x86_64 sssd-proxy-0:1.11.2-27.el7.x86_64 sssd-tools-0:1.11.2-27.el7.x86_64 The first hit is a false positive, docbook-utils requires docbook-style-dsssl. The rest is expected. Did your install require any of the packages above? the anaconda-ks.cfg in /root has: @directory-client so i'm assuming that's what pulled it in. yum remove sssd lists: Removing: sssd x86_64 1.11.2-24.el7 @rhel7-Workstation 34 k Removing for dependencies: c-ares x86_64 1.10.0-2.el7 @anaconda/7.0 178 k certmonger x86_64 0.70-1.el7 @anaconda/7.0 1.4 M ipa-client x86_64 3.3.3-11.el7 @rhel7-Workstation 329 k ipa-python x86_64 3.3.3-11.el7 @rhel7-Workstation 5.1 M krb5-workstation x86_64 1.11.3-41.el7 @anaconda/7.0 2.3 M libdhash x86_64 0.4.3-21.el7 @anaconda/7.0 57 k libipa_hbac x86_64 1.11.2-24.el7 @rhel7-Workstation 53 k libipa_hbac-python x86_64 1.11.2-24.el7 @rhel7-Workstation 38 k libsss_idmap x86_64 1.11.2-24.el7 @rhel7-Workstation 65 k ntp x86_64 4.2.6p5-16.el7 @anaconda/7.0 1.4 M pam_krb5 x86_64 2.4.8-2.el7 @anaconda/7.0 396 k python-dns noarch 1.10.0-4.el7 @anaconda/7.0 988 k python-kerberos x86_64 1.1-12.el7 @anaconda/7.0 49 k python-ldap x86_64 2.4.6-5.el7 @anaconda/7.0 654 k python-netaddr noarch 0.7.5-7.el7 @anaconda/7.0 5.0 M python-sssdconfig noarch 1.11.2-24.el7 @rhel7-Workstation 213 k sssd-ad x86_64 1.11.2-24.el7 @rhel7-Workstation 270 k sssd-client x86_64 1.11.2-24.el7 @rhel7-Workstation 162 k sssd-common x86_64 1.11.2-24.el7 @rhel7-Workstation 3.6 M sssd-common-pac x86_64 1.11.2-24.el7 @rhel7-Workstation 191 k sssd-ipa x86_64 1.11.2-24.el7 @rhel7-Workstation 587 k sssd-krb5 x86_64 1.11.2-24.el7 @rhel7-Workstation 113 k sssd-krb5-common x86_64 1.11.2-24.el7 @rhel7-Workstation 465 k sssd-ldap x86_64 1.11.2-24.el7 @rhel7-Workstation 284 k sssd-proxy x86_64 1.11.2-24.el7 @rhel7-Workstation 186 k ipa-client is a reason why sssd was installed. Did you run command ipa-client-install? There should be log file /var/log/ipaclient-install.log in this case. no, i didn't run ipa-client-install. my machine isn't an ipa client. perhaps something is pulling in ipa-client that shouldn't be? It would be great to know what was installed by anaconda.
Could you send output of following command?
yum history info 1
sssd was installed due to package group directory-client, but you need to configure sssd either with realmd or ipa-client or yourself. [root ~]# yum groupinfo directory-client Loaded plugins: auto-update-debuginfo, product-id, subscription-manager This system is not registered to Red Hat Subscription Management. You can use subscription-manager to register. There is no installed groups file. Maybe run: yum groups mark convert Group: Directory Client Group-Id: directory-client Description: Clients for integration into a network managed by a directory service. Default Packages: +adcli +ipa-client +oddjob-mkhomedir +realmd +sssd Optional Packages: +certmonger +krb5-pkinit +krb5-workstation +ldapjdk +nscd +nss-pam-ldapd +openldap-clients +pam_krb5 +samba-winbind Created attachment 853415 [details]
complete yum history
done with
for i in $(seq 1 68); do yum history info $i; done > yum-history.txt
Created attachment 853416 [details]
/root/anaconda-ks.cfg
Created attachment 853417 [details]
/root/initial-setup-ks.cfg
(In reply to Lukas Slebodnik from comment #7) > sssd was installed due to package group directory-client, but you need to > configure sssd either with realmd or ipa-client or yourself. Lukas, my point is out of the box there shouldn't be any failed services. I don't think I checked any "directory client" checkbox in the installer, but I suppose it's possible. Anyway, I really don't think it should fail just because it's installed before it's configured. Probably the service file should have ConditionPathExists=/etc/sssd/sssd.conf in it or so? (In reply to Ray Strode [halfline] from comment #11) > Probably the service file should have > ConditionPathExists=/etc/sssd/sssd.conf in it or so? Thanks, I had no idea this condition existed! It appears to do exactly what we need for this use case. I'll file an upstream bug to include this condition in the upstream service file as well as the RHEL one. Upstream ticket: https://fedorahosted.org/sssd/ticket/2207 I still wonder which component enabled SSSD by default, though. In %post, we only call "/bin/systemctl daemon-reload" to register the service.. > Lukas, my point is out of the box there shouldn't be any failed services. I > don't think I checked any "directory client" checkbox in the installer, but > I suppose it's possible. I agree there should not be failed services by default. According to anaconda-ks.cfg, your machine was installed from quite old repo (20131016). This repo is not available any more. I tried to install VM from newer repo (virtual); then I installed all 15 package groups like you. sssd was installed on the machine, but it was disabled. [root@vm-204 ~]# service sssd status Redirecting to /bin/systemctl status sssd.service sssd.service - System Security Services Daemon Loaded: loaded (/usr/lib/systemd/system/sssd.service; disabled) Active: inactive (dead) Let's solve the first problem. Why was service sssd enabled? I was not able to reproduce it. Can you try to reproduce it one more time with never repo? > Anyway, I really don't think it should fail just because it's installed > before it's configured. > > Probably the service file should have > ConditionPathExists=/etc/sssd/sssd.conf in it or so? I am not against this solution, we can discuss later which of the following approaches is better. And it can be improved one more time (see BZ1030974) [root@vm-204 ~]# systemctl start sssd [root@vm-204 ~]# echo $? 0 [root@vm-204 ~]# systemctl status sssd sssd.service - System Security Services Daemon Loaded: loaded (/usr/lib/systemd/system/sssd.service; disabled) Active: inactive (dead) start condition failed at Thu 2014-01-23 17:08:02 CET; 1s ago ConditionPathExists=/etc/sssd/sssd.conf was not met [root@vm-204 ~]# systemctl start sssd Job for sssd.service failed. See 'systemctl status sssd.service' and 'journalctl -xn' for details. [root@vm-204 ~]# echo $? [root@vm-204 ~]# systemctl status sssd sssd.service - System Security Services Daemon Loaded: loaded (/usr/lib/systemd/system/sssd.service; disabled) Active: failed (Result: exit-code) since Thu 2014-01-23 17:23:19 CET; 3s ago Process: 2097 ExecStart=/usr/sbin/sssd -D -f (code=exited, status=4) One more time: Can you try to install machine one more time from newer repo and test if service sssd is enabled? okay, i did another install today and reproduced the issue. After boot up, the journal has this in it: Jan 27 15:34:56 localhost.localdomain sssd[751]: Configuration file: /etc/sssd/sssd.conf does not exist. Jan 27 15:34:56 localhost.localdomain systemd[1]: sssd.service: control process exited, code=exited status=4 Jan 27 15:34:56 localhost.localdomain systemd[1]: Failed to start System Security Services Daemon. Jan 27 15:34:56 localhost.localdomain systemd[1]: Unit sssd.service entered failed state. This was a workstation install using the third radio button (not GNOME, not KDE, but the "Developer" one). I didn't check any other boxes. anaconda-ks.cfg has: @base @core @debugging @desktop-debugging @dial-up @directory-client @fonts @gnome-apps @gnome-desktop @guest-desktop-agents @input-methods @internet-applications @internet-browser @java-platform @multimedia @network-file-system-client @performance @perl-runtime @print-client @ruby-runtime @virtualization-client @virtualization-hypervisor @virtualization-tools @web-server @x11 also see bug 1058329 comment 4 for another user hitting this issue. I was able to reproduce it, but only with installation from DVD with anaconda.
I did some analysis where problem is. All packages cab be installed in graphical installation even if root password was not chosen.
All packages were installed(including sssd) and I *was not* able to find sssd.service in directory tree "/mnt/sysimage/etc/systemd/". It means sssd service was not enabled.
I chose root password and then "Final configuration" was done. Before reboot, I was able to find sssd.service in directory tree "/mnt/sysimage/etc/systemd/". It means sssd *was* enabled.
After some tweaking, I found out problem can be in authconfig.
--- a/usr/lib64/python2.7/site-packages/pyanaconda/install.py
+++ b/usr/lib64/python2.7/site-packages/pyanaconda/install.py
@@ -63,7 +63,6 @@ def doConfiguration(storage, payload, ksdata, instClass):
# Now run the execute methods of ksdata that require an installed system
# to be present first.
with progress_report(_("Configuring installed system")):
- ksdata.authconfig.execute(storage, ksdata, instClass)
ksdata.selinux.execute(storage, ksdata, instClass)
ksdata.firstboot.execute(storage, ksdata, instClass)
ksdata.services.execute(storage, ksdata, instClass)
I found information about authconfig in anaconda.program.log file. 13:42:58,278 INFO program: Running... /usr/sbin/authconfig --update --nostart --enableshadow --passalgo=sha512 --enablefingerprint 13:42:59,242 DEBUG program: Return code: 0 Some additional information: [root@localhost ~]# rpm -q sssd authconfig realmd ipa-client sssd-1.11.2-29.el7.x86_64 authconfig-6.2.8-5.el7.x86_64 realmd-0.14.6-5.el7.x86_64 ipa-client-3.3.3-13.el7.x86_64 [root@localhost ~]# file /etc/sssd/sssd.conf /etc/sssd/sssd.conf: cannot open (No such file or directory) [root@localhost ~]# systemctl status sssd.service sssd.service - System Security Services Daemon Loaded: loaded (/usr/lib/systemd/system/sssd.service; disabled) Active: inactive (dead) [root@localhost ~]# /usr/sbin/authconfig --update --nostart --enableshadow --passalgo=sha512 --enablefingerprint [root@localhost ~]# file /etc/sssd/sssd.conf /etc/sssd/sssd.conf: cannot open (No such file or directory) [root@localhost ~]# systemctl status sssd.service sssd.service - System Security Services Daemon Loaded: loaded (/usr/lib/systemd/system/sssd.service; enabled) Active: inactive (dead) [root@localhost ~]# systemctl disable sssd.service rm '/etc/systemd/system/multi-user.target.wants/sssd.service' [root@localhost ~]# /usr/sbin/authconfig --update --nostart --enableshadow --passalgo=sha512 --enablefingerprint [root@localhost ~]# systemctl status sssd.service sssd.service - System Security Services Daemon Loaded: loaded (/usr/lib/systemd/system/sssd.service; enabled) Active: inactive (dead) [root@localhost ~]# Authconfig enables sssd if it is configured in nsswitch.conf which is now default due to other reasons. I do not know the bug# but you can find it by looking for "enable sss in nsswitch by default" or similar query. But it configures sssd only in case it knows where to point it. I'm sorry but I can't see anything that authconfig could do at this point. Regardless, the proposed change in https://fedorahosted.org/sssd/ticket/2207 seems right and should go in to SSSD, anyway, right? (In reply to Tomas Mraz from comment #20) > Authconfig enables sssd if it is configured in nsswitch.conf which is now > default due to other reasons. It is not true [root@vm-140 tmp]# yumdownloader glibc Loaded plugins: product-id (1/2): glibc-2.17-48.el7.x86_64.rpm | 3.6 MB 00:00 (2/2): glibc-2.17-48.el7.i686.rpm | 4.2 MB 00:00 [root@vm-140 tmp]# rpm2cpio glibc-2.17-48.el7.x86_64.rpm | cpio -i -d 27354 blocks [root@vm-140 tmp]# grep sss etc/nsswitch.conf passwd: files sss shadow: files sss group: files sss services: files sss netgroup: nisplus sss sss is by default in nsswitch.conf (as you can see) you just confirmed what he said and then used that as evidence to reassign the bug back to him. so the real issue here, i think, is that nss module is always supposed to be in nsswitch.conf even when sssd isn't enabled. This is because adding it at runtime fails because of libc internal caching. See bug 621700 and https://sourceware.org/bugzilla/show_bug.cgi?id=12459 for more details about that. So using it's presence in nsswitch.conf isn't a good litmus test for if it should be enabled or not. Perhaps a better litmus test would be: 1) pam_sss is in system-auth 2) sssd.conf exists Does that sound reasonable, Tomas? Also, just wanted to add the ConditionPathExists= fix has the real downside that "systemctl start sssd" will seemingly succeed when the config file isn't there, which could be confusing for the admin (until they think to run systemctl status sssd). So it's not ideal, and it would be better if we could make sssd not get enabled by default. I think this will not fix the problem completely because existence of sssd.conf does not mean that there is a domain configured. And if there is no domain configured sssd startup will fail (or at least this was the case when I tested it last time). However it would solve at least the "default install" problem. (In reply to Ray Strode [halfline] from comment #23) > you just confirmed what he said and then used that as evidence to reassign > the bug back to him. I misread words "which is now default". I read it as "which is NOT default" I agree with you that presence of sss in nsswitch.conf is not enough, because sss is there by default. I doubt anyone would like to use sssd only for resolving names(nss) without configured pam stack. This request was resolved in Red Hat Enterprise Linux 7.0. Contact your manager or support representative in case you have further questions about the request. |