Your message dated Tue, 25 Mar 2014 16:21:21 -0500
with message-id 
<CAL4L7=BYd1NirXwPQUiu=uppxrggy1vh0azvcfcy19_p6lr...@mail.gmail.com>
and subject line Re: Bug#730053: libnss-ldapd causes long login times because 
of recursive group lookups
has caused the Debian Bug report #730053,
regarding libnss-ldapd causes long login times because of recursive group 
lookups
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)


-- 
730053: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=730053
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: libnss-ldapd
Version: 0.8.10-4
Severity: important

Dear Maintainer,

I have some servers that have users that log in that are members of many
groups
in an LDAP directory. When I watch debug output from nscd I see that the
user
is looked up, then the members of each group the user is a member of are
looked
up. In my case, looking up users that are members of the group that the user
logging in is a member of causes a delay of up to one minute. As far as I
can
see, this also provides no value.

Instead of pasting the entire log that I have, I'll share a link to it. This
log has been trimmed in the middle...  ""[...] A few hundred more of
these...""


It could be possible that the culprit is actually ssh or pam, but I have
zero
clue how to debug that. If I can provide any debugging help, please, let me
know.

-- System Information:
Debian Release: 7.2
  APT prefers stable
  APT policy: (900, 'stable'), (700, 'unstable'), (500, 'stable-updates')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages libnss-ldapd depends on:
ii  debconf [debconf-2.0]  1.5.49
ii  libc6                  2.13-38
ii  multiarch-support      2.13-38
ii  nslcd                  0.8.10-4

libnss-ldapd recommends no packages.

libnss-ldapd suggests no packages.

-- debconf information:
* libnss-ldapd/nsswitch: passwd, group, shadow
  libnss-ldapd/clean_nsswitch: true

--- End Message ---
--- Begin Message ---
I worked with a consultant to find a solution. We wound up backporting
some changes to python-sss and just having this in place managed to
fix the issue I've been experiencing. Thanks for working with me!

On Mon, Mar 10, 2014 at 3:05 PM, Arthur de Jong <[email protected]> wrote:
> On Wed, 2013-11-20 at 12:58 -0600, Michael Lustfield wrote:
>> I have some servers that have users that log in that are members of
>> many groups in an LDAP directory. When I watch debug output from nscd
>> I see that the user is looked up, then the members of each group the
>> user is a member of are looked
>> up. In my case, looking up users that are members of the group that
>> the user logging in is a member of causes a delay of up to one minute.
>> As far as I can see, this also provides no value.
>>
>> Instead of pasting the entire log that I have, I'll share a link to
>> it. This log has been trimmed in the middle...  ""[...] A few hundred
>> more of these...""
>
> Judging from earlier examination of the log it seems that after the
> lookup of the groups for the user, the application requests each group
> (probably to lookup the group name).
>
> Group lookups with lots of members can be slow, especially if the member
> attribute is used. For this reason nslcd caches DN to username lookups.
>
> The upcoming 0.9.3 release includes a configuration option to set the
> timeout for these cached entries (by default 15 minutes) and allows
> disabling the member attribute.
>
> Other than the above, there is not much more that nslcd can do. It may
> be a good idea to use (u)nscd to cache group lookups (this may improve
> performance for subsequent lookups).
>
> Another point is that sshd may be doing the group lookups due to the use
> of AllowGroups/DenyGroups (haven't tested this). Perhaps disabling this
> is an option? Similarly it could be a pam_group or similar module that
> initiates the extra lookups.
>
>
> --
> -- arthur - [email protected] - http://people.debian.org/~adejong --

--- End Message ---

Reply via email to