Fwd: Re: [SSSD-users] ldap config

[Stephen Gallagher]

-----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 
To: Stephen Gallagher

On Fri, Apr 26, 2013 at 4:28 AM, Stephen Gallagher 
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-----

[SSSD-users] ldap config

[Brandon Foster]

On Fri, Apr 26, 2013 at 9:19 AM, Stephen Gallagher  wrote:
> -----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 
> To: Stephen Gallagher
>
> On Fri, Apr 26, 2013 at 4:28 AM, Stephen Gallagher 
> 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-----

yep sorry, was getting lazy with hitting reply.

here is my ssd version
------
root@virt-vm-99:~> rpm -q sssd
sssd-1.9.2-82.4.el6_4.x86_64
--------

[Jakub Hrozek]

On Fri, Apr 26, 2013 at 12:19:05PM -0400, Stephen Gallagher wrote:
> -----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.

I haven't had yet the time to investigate fully but we're looking at
either a tight loop or a request that never finishes.

Brandon, could you run an instrumented test build for us in case we fail
to reproduce the problem locally?

[Brandon Foster]

sure, what would i need to do exactly?

On Mon, Apr 29, 2013 at 5:08 AM, Jakub Hrozek  wrote:
> On Fri, Apr 26, 2013 at 12:19:05PM -0400, Stephen Gallagher wrote:
> > -----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.
>
> I haven't had yet the time to investigate fully but we're looking at
> either a tight loop or a request that never finishes.
>
> Brandon, could you run an instrumented test build for us in case we fail
> to reproduce the problem locally?