-----BEGIN PGP SIGNED MESSAGE-----
On 09/28/2010 07:02 PM, Jeff Schroeder wrote
Not for the sake of being argumentative, but for the sake of
completeness, why do you want to change the semantics of what an admin
would expect? Especially when most people using sssd are former
pam_ldap users and expect things like netgroups to work a certain way?
While not disagreeing, I'm just curious as to the reasoning.
Well, as I was trying to explain in the original email, there are
several advantages to doing this differently.
1) Much higher performance. If we perform the nested lookups inside of
SSSD, we can potentially perform multiple parallel lookups and save us
the time of repeated round-trips from LDAP.*
2) We can provide an option for nesting limits. Right now, glibc will
always follow nested netgroups down as far as it can go. In a
pathological case, this could be thousands of nestings deep. That can be
3) We guarantee that the central LDAP store is authoritative for
netgroups. Doing things this way ensures that if a netgroup arrangement
is set up on the server, no local change will interject unexpected
values into the mix, intentionally or otherwise.
* It occurred to me while writing this email that even if we did go with
the traditional behavior, we could still probably pre-cache the nested
groups so that when glibc requests them we can serve them from cache. Of
course, this can also be a waste of processing time if it turns out that
one of the nested members (potentially one that has other, further
nested members) is in fact being overridden on the client.
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
-----END PGP SIGNATURE-----