On 10/24/2012 05:49 PM, Paul B. Henson wrote:
We're working on transitioning from RHEL5 to RHEL6 and have run
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
Unfortunately, we have the exact same issue with sssd:
# time getent group members
# time getent group students
# time id -a cpcrudo
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?
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.
Sr. Engineering Manager for IdM portfolio
Red Hat Inc.
Looking to carve out IT costs?