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.