[SSSD] Fwd: Re: [SSSD-users] ldap config

Stephen Gallagher sgallagh at redhat.com
Fri Apr 26 16:19:05 UTC 2013


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Forwarding back to the sssd-users list, because it contains useful
information that other developers might need to see. Please make sure
to keep this list in all replies.

So this confirms my hypothesis. Something is happening during the
RootDSE lookup that is causing the SSSD to freeze forever here. The
monitor notices this after 30s and sends a SIGTERM, which is never
handled. After another 30s, it sends a SIGKILL which forcibly restarts it.

Brandon, can you tell us the exact version of SSSD you are using? You
can get this by running 'rpm -q sssd'. Please report the entire string
it gives back.


- -------- Original Message --------
Subject: Re: [SSSD-users] ldap config
Date: Fri, 26 Apr 2013 09:13:13 -0700
From: Brandon Foster <brandon.foster at liferay.com>
To: Stephen Gallagher <sgallagh at redhat.com>

On Fri, Apr 26, 2013 at 4:28 AM, Stephen Gallagher <sgallagh at redhat.com>
wrote:
> On 04/25/2013 05:49 PM, Brandon Foster wrote:
>> No, i never tried to log in during that time, and I did not shut 
>> it down manually, it must have crashed.
> 
>> So adding in that time out line seems to have done something.
>> Now with the timeout line it wont even search ldap for my user.
>> the search does not show up in sssd_default.log, and it still
>> returns no such user.
> 
>> here is my sssd.conf with the timeout line:
> 
>> ------------------------- [sssd] config_file_version = 2 services
>> = nss, pam domains = default
> 
>> [nss] filter_users = 
>> root,ldap,named,avahi,haldaemon,dbus,radiusd,news,nscd
> 
>> [pam]
> 
>> [domain/default] timeout = 5400 auth_provider = ldap debug_level
>> = 9 enumerate = True cache_credentials = True chpass_provider =
>> ldap entry_cache_timeout = 600 ldap_chpass_uri = 
>> ldaps://66.117.7.48:11389/ id_provider = ldap ldap_group_member
>> = uniquemember ldap_group_object_class = group
>> ldap_id_use_start_tls = False ldap_pwd_policy = none
>> ldap_search_base = ou=Liferay\, 
>> Inc.,ou=Organizations,ou=liferay.com,o=Liferay ldap_tls_cacertdir
>> = /etc/openldap/cacerts ldap_tls_reqcert = never ldap_uri = 
>> ldaps://66.117.7.48:11389/ ldap_user_gecos = displayName 
>> ldap_user_home_directory = unixHomeDirectory ldap_user_name = cn 
>> ldap_user_object_class = user -----------------------
> 
>> good news is it isnt crashing anymore. but still not working
> 
> 
> Ok, so what that suggests to me is that the problem was never 
> *actually* a crash, but instead may have been a tight loop
> problem. The sssd_be may have gotten into an infinite loop, which
> prevents it from replying to the ping from the service monitor,
> which eventually kills it forcibly.
> 
> Let's try to verify this hypothesis. Please add 'debug_level = 9'
> to your [sssd] section, remove the 'timeout = 5400' from the 
> [domain/default] section, truncate or delete the logs in
> /var/log/sssd and restart sssd.
> 
> Then *run the user login* and send us /var/log/sssd/sssd.log and 
> /var/log/sssd/sssd_default.log
> 
> This should hopefully give us enough to go on. Sorry for the
> repeated back-and-forth, but debugging without being able to
> reproduce the problem locally is tricky.
> 
> 
> Side-note: I notice you are using "uniquemember" for the member 
> attribute, but you're not setting ldap_schema = rfc2307bis. If I 
> remember correctly 'uniquemember' (like 'member') stores the 
> user/group DN, not the username. If that's correct, you really need
> to set 'ldap_schema = rfc2307bis' or you won't see group
> memberships correctly.

thanks again for your help.

as far as the uniquemember, what should this be to be the username?
Also i dont know which schema my ldap is but i've tried both and
neither has worked with the current set up.

just as an example i have a user who's dn is:
cn=testuser,ou=organizationunit3,ou=organizationunit2,ou=organizationunit1,o=domain

and i want him to log in as testuser. would I then set ldap_group_member
to cn?

i've attached the complete sssd.log and sssd_default.log



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlF6qPcACgkQeiVVYja6o6OvvgCfShTffrzINj64pTg/sWgqQiDn
GdwAn1qLAuMkzG9yzxoJaBxz3DnANHH5
=fwPX
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sssd.log
Type: application/octet-stream
Size: 43683 bytes
Desc: not available
URL: <https://lists.fedorahosted.org/pipermail/sssd-devel/attachments/20130426/9ffa23e0/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sssd_default.log
Type: application/octet-stream
Size: 103852 bytes
Desc: not available
URL: <https://lists.fedorahosted.org/pipermail/sssd-devel/attachments/20130426/9ffa23e0/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sssd.log.sig
Type: application/pgp-signature
Size: 72 bytes
Desc: not available
URL: <https://lists.fedorahosted.org/pipermail/sssd-devel/attachments/20130426/9ffa23e0/attachment.sig>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sssd_default.log.sig
Type: application/pgp-signature
Size: 72 bytes
Desc: not available
URL: <https://lists.fedorahosted.org/pipermail/sssd-devel/attachments/20130426/9ffa23e0/attachment-0001.sig>


More information about the sssd-devel mailing list