On 10/24/2012 3:13 PM, Dmitri Pal wrote:
SSSD has the ability to use enumeration. In this case you pay the
once in advance and then the cache is updated in the background. That
might be a solution for your use case.
Honestly, I have zero interest in trying to replicate my entire LDAP
directory on each and every server 8-/. It's kinda big ;). Most servers
are probably only going to touch pieces of it, improving performance by
caching those is good, but trying to replicate it entirely feels wrong.
I'm not even sure it would work on our LDAP server, which resource
restricts anonymous connections.
Also would you mind trying 1.9.2?
I could try it out to see if it changes anything, but the only reason we
run RHEL is for proprietary products that require it, and not running
the stock supported rpm's kind of defeats that purpose :). If 1.9.2 is
better I'd have to get them to back port whatever changes were relevant
to the resolution, which would likely be more trouble than getting them
to backport a single feature such as skipping group membership lookups.
It's not intractable to handle our groups in a timely fashion, our
Solaris 10 boxes do the same getent lookup in about 2/10 of a second.
But considering we don't actually need the membership returned, just not
including it seems a quicker solution.
We can consider the feature but where we stand now it is unclear
would be the time frame.
We would implement it ourselves, but I don't want to go to the trouble
unless there's some reasonable chance upstream will accept it.
You can always get back to nss-ldap but I suspect the version that
available in RHEL6 is different code from PADL and might not have the
specific feature you are talking about.
RHEL6 includes nss-pam-ldapd rather than stock nss_ldap. While forked
from nss_ldap, it does indeed not include the skipmembers feature.
If all options above are exhausted and if you a RHEL customer I
you file a case with Red Hat support.
I already opened a case; the initial response was:
Could you please provide us the output of the strace command so that we
can check where exactly the command is taking more time?
You will have to execute below commands and provide us the resulting
# strace -o /tmp/getent_group_members.out getent group members
Level 1 support has never exactly impressed me 8-/. Disregarding the
fact that strace on getent is only going to show a long delay between
the connect to /var/lib/sss/pipes/nss and the response (it's not exactly
a mystery what's taking so much time), they didn't even request the -t
flag so the output won't even include timing information <sigh>.
That would trigger the proper escalation sequence to make sure the
is addressed in RHEL and you have a clear migration path from the
solution you have to some adequate solution on RHEL6.
I find the most effective method to get something fixed through Red Hat
support is to go fix it ourselves, get the fix accepted in the upstream
project, hand it to them gift wrapped, and then have a lot of patience
for the six months to a year it takes to show up in an officially
I see you have an @redhat address :), please don't interpret my
grumbling as derogatory to your company; you guys have some great
engineers and do a lot of good stuff -- but your support absolutely
drives me up the wall.
Thanks much for your input...
Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/
Operating Systems and Network Analyst | henson(a)csupomona.edu
California State Polytechnic University | Pomona CA 91768