Please support nested groups about nsscache

[jaqx0r]

This seems reasonable.

Do you want to work on this?

[akorn]

No. Unfortunately I have neither the required python skills, nor (more importantly) time. :(

I can work around the problem by not using nss-cache at all; instead, I'll periodically run getent passwd and getent group on a box with nss set to use LDAP, and copy the results to the LDAP servers (well, actually, I'll use svn or git to distribute the flat files).

This works for me because my only problem is that there are race conditions when the LDAP servers all try to start simultaneously and look up uid/gid mappings in LDAP; if the LDAP servers themselves use flat files, that's good enough for me. I don't need shadow, netgroup, automount or anything else, just uid-name, gid-name and group-member mappings, and this getent based kludge will work for me. (I'm writing this down because it may work for others too.)

[jaqx0r]

Understood. I too am short on time so this will have to wait for now.

On Wed, 6 Jan 2016, 18:26 Dr. András Korn [email protected] wrote:

No. Unfortunately I have neither the required python skills, nor (more
importantly) time. :(

I can work around the problem by not using nss-cache at all; instead, I'll
periodically run getent passwd and getent group on a box with nss set to
use LDAP, and copy the results to the LDAP servers (well, actually, I'll
use svn or git to distribute the flat files).

This works for me because my only problem is that there are race
conditions when the LDAP servers all try to start simultaneously and look
up uid/gid mappings in LDAP; if the LDAP servers themselves use flat files,
that's good enough for me. I don't need shadow, netgroup, automount or
anything else, just uid-name, gid-name and group-member mappings, and this
getent based kludge will work for me. (I'm writing this down because it may
work for others too.)

—
Reply to this email directly or view it on GitHub
#68 (comment).

[kev009]

@jaqx0r do you have a preference on how this should be implemented? I can do it quite easily in python, but maybe there are some reasons it should be in libnss-cache?

[jaqx0r]

Without having thought about it too hard, my feeling is that libnss-cache
is the wrong place because that's in the critical read path, so it should
be done in nsscache (i.e. the python).

This might prove to be bad for really large nestings of groups but we can
burn that bridge when we come to it.

On Fri., 7 Oct. 2016, 15:40 Kevin Bowling, [email protected] wrote:

@jaqx0r https://github.com/jaqx0r do you have a preference on how this
should be implemented? I can do it quite easily in python, but maybe there
are some reasons it should be in libnss-cache?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#68 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AC5b-85GXnF8-nSW48xzNt4HEgJrs18aks5qxc1EgaJpZM4G9yd1
.

[kev009]

I was thinking it has some considerations like, a recursive group member that is not in ldap should be preserved because one of the other nss providers may have it.. but after writing it out I don't see why doing that in the python side wont work.

[JaseFace]

Did anyone have some time to start this up yet?

[trenton42]

Looking through the python, it appears that there would be an issue mapping the recursive groups on incremental updates. For --full runs it is fine, but when running without --full, only modified groups will show up in the search result. In order to properly update all nested groups, several queries would have to be made (query for any groups that contain the changed group, then any groups that contain those groups, etc.), so depending on the ldap layout, it could greatly diminish the efficiency of doing an incremental update. It may also be possible to cache those group to group relationships, but that would also require more code changes.

[trenton42]

This first stab will cache nested groups, but only on a full sync: master...trenton42:nested-groups

Using this code with incremental updates will be subtly broken, as changes in memberships in child groups will not propagate up to parent groups

[jaqx0r]

Thanks for working on this! If we can hide this feature behind a flag then I'm happy to merge it so people can try it out.

…

On Fri, 26 Oct 2018 at 11:20, Trenton Broughton ***@***.***> wrote: This first stab will cache nested groups, but only on a full sync: master...trenton42:nested-groups <master...trenton42:nested-groups> Using this code with incremental updates will be subtly broken, as changes in memberships in child groups will not propagate up to parent groups — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#68 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AC5b-9UqqSWE-5ASLRR_MFRbq0gnasiUks5uo1J3gaJpZM4G9yd1> .

[trenton42]

Thanks @jaqx0r! I added those changes in #84. Let me know if that looks good.