On Thu, 16 Sep 2010 17:50:28 +0200
Ralf Haferkamp <rhafer(a)suse.de> wrote:
On Thursday 09 September 2010 15:14:10 Ralf Haferkamp wrote:
> I have started working on a patch to let sssd look up the non-cached
> users via LDAP (and save them into the cache). Find it attached.
> Note: That patch is not really complete (e.g. it doesn't handle
> rfc2307 groups correctly). But before putting more effort into this
> I like to make sure that I am not trying to fix a "feature" here.
Find a newer version of my patch attached. Actually it's 3 patches
now. Please review.
Patch1: This just adds a new flag to save_groups() to indicate that
the group's member attribute is already populated with the members'
sysdb DN (instead on LDAP DNs). As I need to lookup the group members
in sysdb anyway, when processing the group, this saves some redundant
sysdb lookups when storing the group.
This looks like a good idea.
Patch2: This is a somewhat improved version of my last patch.
- better error handling
- limit the number of LDAP requests that are issued before
starting to process the results. This is especially needed when
dealing with large groups, otherwise the server might choke on us
(e.g. OpenLDAP has a (configurable) limit of 100 pending
operations per anonymous connection and 1000 per authenticated
connection). OTOH sending multiple LDAP request at once will speed up
things a bit compared to just sending the next request after
processing the result of the previous.
- populate the "member" attribute with the correct sysdb DNs to
- limit the group unrolling to rfc2307bis for now. rfc2307 and IPA
need to be treated differently as discussed previously in this
This patch makes the main function very complex, I suggest that you at
least create separate functions for each new tevent request you want to
create, that is sort of a rule for sssd. (And it makes code digestible
more often than not).
As for group unrolling I have also started working on it (ticket #625),
although I am doing that in the 1.2.x branch as we need the
functionality there too. I will try to post a patch soon so that we can
compare relative approaches and merge the effort, ok ?
Patch3: This adds a new config option to
to enable/disable group unrolling
Can we use the followin patch instead ?
This patch assumes the code will consider a nesting level of 0 as "no
nesting". therefore it will embed in a single option both a way to
enable disable unrolling and a limit on the level of nesting we will
allow on the client (to avoid loops or very long delay on pathological
Simo Sorce * Red Hat, Inc * New York