Bug 908383 - sssd.service is not running after installation
sssd.service is not running after installation
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: sssd (Show other bugs)
18
x86_64 Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Jakub Hrozek
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-02-06 10:05 EST by habicht
Modified: 2013-02-07 13:12 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-02-07 13:12:53 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description habicht 2013-02-06 10:05:31 EST
Description of problem:

I am trying to change my Fedora 17 kickstart files for Fedora 18.
After a 1:1 transfer, fixing some little things, i see, i cannot
login via LDAP. Local root login is working and also doing a su
for a LDAP user. SELinux is disabled.

I saw this in log/secure:

Feb  6 15:46:23 pxe-122 sshd[3687]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=130.n  user=habicht
Feb  6 15:46:23 pxe-122 sshd[3687]: pam_ldap: could not open secret file /etc/pam_ldap.secret (No such file or directory)
Feb  6 15:46:23 pxe-122 sshd[3687]: Failed password for habicht from 130.n port 39748 ssh2
Feb  6 15:46:23 pxe-122 sshd[3687]: fatal: Access denied for user habicht by PAM account configuration [preauth]

I found, sssd is not running. I tried to use a new rpm, but this has the same effect.

Version-Release number of selected component (if applicable):

sssd-1.9.3-1.fc18.x86_64
sssd-1.9.4-2.fc18.x86_64

How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:

[root@pxe-122 ~]# systemctl status sssd.service
sssd.service - System Security Services Daemon
	  Loaded: loaded (/usr/lib/systemd/system/sssd.service; disabled)
	  Active: failed (Result: exit-code) since Wed 2013-02-06 15:17:01 CET; 2s ago
	 Process: 3374 ExecStart=/usr/sbin/sssd -D -f (code=exited, status=4)

Feb 06 15:17:00 pxe-122.n.de systemd[1]: Starting System Security Services Daemon...
Feb 06 15:17:00 pxe-122.n.de sssd[3374]: nscd socket was detected.  Nscd caching capabilities may conflict ...maps.
Feb 06 15:17:01 pxe-122.n.de sssd[3374]: Cannot read config file /etc/sssd/sssd.conf, please check if permi....root
Feb 06 15:17:01 pxe-122.n.de systemd[1]: sssd.service: control process exited, code=exited status=4
Feb 06 15:17:01 pxe-122.n.de systemd[1]: Failed to start System Security Services Daemon.
Feb 06 15:17:01 pxe-122.n.de systemd[1]: Unit sssd.service entered failed state



Expected results:

Running sssd.


Additional info:

I told already, i used a running configuration for Fedora 17. If you need more information, please tell me, which files i have to provide. Disable nscd doesn't help.
Comment 1 Stephen Gallagher 2013-02-06 10:41:54 EST
The answer is in the log you pasted above: "Cannot read config file /etc/sssd/sssd.conf, please check if permi....root". The full version of that line tells you that this file must be owned by root and have the permissions 0600. This is a security feature, since some of the contents of that file may be sensitive and should not be readable by other users.
Comment 2 Jakub Hrozek 2013-02-06 15:15:58 EST
There seems to be several things that should be investigated with your confuguration.

First, the /var/log/secure indicates you are using pam_ldap as well..are you using the proxy provider in SSSD? If not, why is pam_ldap configured and not pam_sss?

Also, why are you running nscd in parallel with the SSSD? This can only be recommended if you make sure that nscd is only enabled for maps that the SSSD cannot serve.

How is your sssd.conf generated? If using authconfig (which is the recommended way), then the permission should be correct. If you are generating the file manually, then you should make sure the permissions and ownership is correct (0600, root.root).
Comment 3 habicht 2013-02-07 03:56:10 EST
Ok, as i told already, my setup was running with Fedora 17. But it was made by externals ....

* sssd is enabled by auth in the kickstart file, so permissions should be correct:

[root@pxe-122 etc]# ls -ld sssd/
drwx------. 2 root root 4096 Jan 30 15:07 sssd/

* This is sssd.conf running on my Fedora 17 hosts:

[root@pxe-101 sssd]# more sssd.conf 
[domain/default]

cache_credentials = True
ldap_search_base = ou=n,dc=n,n,dc=de
krb5_realm = #
id_provider = ldap
auth_provider = ldap
chpass_provider = ldap
ldap_uri = ldap://130.n/
ldap_tls_cacertdir = /etc/openldap/cacerts
[sssd]
services = nss, pam
config_file_version = 2

domains = default
[nss]

[pam]

[sudo]

[autofs]

* nscd was running by default and it was not a problem up to now. Well, i can disable it.

I will investigate for more informations.
Comment 4 Sumit Bose 2013-02-07 04:22:16 EST
Please check the permissions of /etc/sssd/sssd.conf as well. It should look like:

[root@localhost ~]# ls -alZ /etc/sssd/sssd.conf 
-rw-------. root root unconfined_u:object_r:etc_t:s0   /etc/sssd/sssd.conf
Comment 5 habicht 2013-02-07 05:25:05 EST
The point is: there is no sssd.conf after installation.
And i see no generated sssd.conf, when i try to start sssd.service.

But when i put after installation sssd.conf from our Fedora 17 hosts to this Fedora 18 host and i restart sssd.service, everything is working well and i can login:


[root@pxe-122 sssd]# systemctl status sssd.service
sssd.service - System Security Services Daemon
	  Loaded: loaded (/usr/lib/systemd/system/sssd.service; enabled)
	  Active: active (running) since Thu 2013-02-07 11:15:34 CET; 4min 16s ago
	 Process: 3453 ExecStart=/usr/sbin/sssd -D -f (code=exited, status=0/SUCCESS)
	Main PID: 3454 (sssd)
	  CGroup: name=systemd:/system/sssd.service
		  |-3454 /usr/sbin/sssd -D -f
		  |-3455 /usr/libexec/sssd/sssd_be --domain default --debug-to-files
		  |-3456 /usr/libexec/sssd/sssd_nss --debug-to-files
		  `-3457 /usr/libexec/sssd/sssd_pam --debug-to-files

Feb 07 11:15:33 pxe-122.ims.uni-hannover.de systemd[1]: Starting System Security Services Daemon...
Feb 07 11:15:33 pxe-122.ims.uni-hannover.de sssd[3454]: Starting up
Feb 07 11:15:34 pxe-122.ims.uni-hannover.de sssd[be[3455]: Starting up
Feb 07 11:15:34 pxe-122.ims.uni-hannover.de sssd[3457]: Starting up
Feb 07 11:15:34 pxe-122.ims.uni-hannover.de sssd[3456]: Starting up
Feb 07 11:15:34 pxe-122.ims.uni-hannover.de systemd[1]: Started System Security Services Daemon.

So the question is: Why is no sssd.conf generated?

This is my auth-cmd in the kickstart file:

auth --enableldap --enableldapauth --enablemkhomedir --disablenis --ldapserver=130.n --ldapbasedn="ou=n,dc=n,dc=de" --useshadow  --passalgo=md5 --enablesssdauth --enableforcelegacy


I tried to use --enablesssd also, but this doesn't help.
Comment 6 Sumit Bose 2013-02-07 06:13:12 EST
Please drop --enableforcelegacy because

# authconfig --help |grep enableforcelegacy
    --enableforcelegacy     never use SSSD implicitly even for supported configurations

There was a bug in older versions of authconfig which always creates a sssd.conf file if  --enablesssd or --enablesssdauth were used. Both options should only created the SSSD related entries in /etc/nsswitch.conf or the PAM configuration respectively. This might be the reason which the authconfig line worked in F17 but fails in F18 now.
Comment 7 habicht 2013-02-07 10:23:29 EST
Well funny, when i don't use --enableforcelegacy the file sssd.conf will be generated.

So i think now, my problem is a new or different behavior of auth or authconfig.
I see also a different behavior of generating pam.d-Files now.

So i don't know now, if we have bugs of features. 

If i don't use --enableforcelegacy, sssd is running at startup with an existing sssd.conf file. But my pam.d-passwd-files are now different. They have now no pam_ldap-entries anymore as with Fedora 17.

Well, i can found a workaround for use. And i will investigate more,
Comment 8 Jakub Hrozek 2013-02-07 13:12:53 EST
(In reply to comment #7)
> Well funny, when i don't use --enableforcelegacy the file sssd.conf will be
> generated.
> 
> So i think now, my problem is a new or different behavior of auth or
> authconfig.
> I see also a different behavior of generating pam.d-Files now.
> 
> So i don't know now, if we have bugs of features. 
> 
> If i don't use --enableforcelegacy, sssd is running at startup with an
> existing sssd.conf file. But my pam.d-passwd-files are now different. They
> have now no pam_ldap-entries anymore as with Fedora 17.
> 

I don't think the pam_ldap module should be present in the config file at all when authconfig is instructed to generate SSSD aware configuration.

Closing as notabug.

Note You need to log in before you can comment on or make changes to this bug.