On 10/24/2012 05:49 PM, Paul B. Henson wrote:
We're working on transitioning from RHEL5 to RHEL6 and have run
into a
bit of a problem with sssd and our ldap integration.
We have a number of groups with a very large number of members, which
took excessively long with nss_ldap to retrieve. We implemented the
nss_getgrent_skipmembers feature for nss_ldap, got it accepted into the
PADL upstream, talked Red Hat into backporting it, and have been
using it for years. Basically, this feature allows you to not request
the member attribute for a group lookup, the group shows up with no members.
However, for the purposes of initgroups, membership is still taken into
account and users belong to the correct groups. This works perfectly for
our needs.
Unfortunately, we have the exact same issue with sssd:
# time getent group members
[...]
real 1m29.589s
user 0m0.006s
sys 0m0.003s
# time getent group students
[...]
real 0m44.735s
user 0m0.007s
sys 0m0.002s
# time id -a cpcrudo
[...]
real 2m14.719s
In addition, any other lookups appear to be blocked during the delay, so
the whole system is basically without naming services for minutes.
Is there any way to emulate the behavior of nss_ldap with the
nss_getgrent_skipmembers option enabled with sssd? If not, would there
be any objection to adding such a feature?
Thanks...
I will leave it to the SSSD gurus to reply about the availability of the
similar capability in SSSD but I suspect that the answer is no.
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.
Also would you mind trying 1.9.2?
It has a bunch of performance improvements and it might be that the
results you would get with 1.9.2 are much more acceptable than you see now.
We can consider the feature but where we stand now it is unclear what
would be the time frame.
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.
If all options above are exhausted and if you a RHEL customer I suggest
you file a case with Red Hat support.
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.
--
Thank you,
Dmitri Pal
Sr. Engineering Manager for IdM portfolio
Red Hat Inc.
-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/