On 10/24/2012 08:09 PM, Paul B. Henson wrote:
On 10/24/2012 3:13 PM, Dmitri Pal wrote:
> SSSD has the ability to use enumeration. In this case you pay the price
> 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.
BTW SSSD connects in an authenticated way.
> 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
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.
I might not have been clear. 1.9.2 is coming in RHEL 6.4 as a supported
rpm so if it solves the problem for you it will show up in several
months and might save everybody some time and effort.
> We can consider the feature but where we stand now it is unclear what
> 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.
As was mentioned in other mails we have this request in plans but if
1.9.2 works for you you might not need to do the work.
> You can always get back to nss-ldap but I suspect the version that is
> 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.
That is what I thought. Thanks for confirming.
> If all options above are exhausted and if you a RHEL customer I suggest
> 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
> That would trigger the proper escalation sequence to make sure the issue
> 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 supported RPM...
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.
Yes I am from Red Hat and you filing the ticket would help me to help
our support to learn how better handle cases like this in future.
Thank you for your patience.
Thanks much for your input...
Sr. Engineering Manager for IdM portfolio
Red Hat Inc.
Looking to carve out IT costs?