On Thu, 24 Dec 2009 10:35:24 -0800
Jeff Schroeder <jeffschroed(a)gmail.com> wrote:
I've not been able to reproduce this just yet, but when
installing
sssd 1.0 via puppet, it didn't seem to come up right. It only started
the LDAP provider and nothing else. It seems like this should be
critical and the watchdog parent should spawn the other child
providers such as the pam and nss providers.
root(a)core022.lax02 ~ # ps -efH | grep sss[d]
root 5347 1 0 10:20 ? 00:00:00 /usr/sbin/sssd -f -D
root 5348 5347 0 10:20 ? 00:00:00
/usr/libexec/sssd/sssd_be -d 0 --debug-to-files --domain LDAP
[sssd]
config_file_version = 2
domains = LDAP
reconnection_retries = 3
sbus_timeout = 30
services = nss, pam
[nss]
filter_groups = root,core
filter_users = root,core
reconnection_retries = 3
[pam]
reconnection_retries = 3
[domain/LDAP]
auth_provider = ldap
cache_credentials = TRUE
chpass_provider = ldap
enumerate = TRUE
id_provider = ldap
ldap_group_search_base = ou=Groups,o=int
# Ignore ldap pwd policies so password changes work with shadow*
attributes in ldap
ldap_pwd_policy = none
ldap_tls_reqcert = never
ldap_uri = ldap://server1.site1/ ldap://server2.site2
ldap://server3.site3 ldap_user_search_base = o=int
min_id = 1
timeout = 60
Needless to say, this makes it a bit difficult to login. Any pointers
to if the config is wrong in this instance? In any case, it seems like
the watchdog was wrong in not starting the other providers. What do
you guys think? Puppet doesn't call anything crazy other than service
sssd {start,restart,reload} in this instance.
In theory sssd_nss and sssd_pam should be started anyway after a brief
timeout. Do you have logs we can analyze ?
I have never seen such misbehavior nor I have heard form others.
Did a restart just fix it ?
Simo.
--
Simo Sorce * Red Hat, Inc * New York