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 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.
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 *.out files:
# 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>.
Sigh.
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...