Am Freitag 24 September 2010, 16:29:33 schrieb Jakub Hrozek:
On 09/24/2010 11:27 AM, Ralf Haferkamp wrote:
> I agree that the parallel approach is a bit more complex. But it was
> significantly faster in the tests I did compared to serially
> processing the group members. Otherwise I wouldn't have done that
> implementation. BTW, you can see the difference by setting
> GROUPMEMBER_REQ_PARALLEL to 0.
> The goal wasn't to have multiple LDAP connections opened (that would
> be insane). But sending multiple request at once to the LDAP server
> (through a single connection) and then starting processing the
> results of the requests is of course faster than sending sending a
> single request then processing the result of that request and then
> sending the next request. Simply because the LDAP server can a)
> process multiple requests at once and b) has a some request queued
> to process while the client is busy with retrieving and processing
> the results. The only drawback I see here is that the LDAP Server
> might limit the number of LDAP request it queues on a single
> connection therefor it would probably be good to replace
> GROUPMEMBER_REQ_PARALLEL with a value configurable via sssd.conf.
I think this part of your work overlaps with what I've been doing in
order to fix #621 and #625. My approach was a little bit different and
I'm wondering whether we could merge our patches.
I've been implementing Simo's proposal so that for every user that is
not cached in sysdb we add a kind of fake "skeleton" user - just a
DN, name and marked as expired - so that getgrnam is able to return
the list of users but when additional details about the user are
requested via getpwnam/getpwuid, the entry is requested.
Yeah, we discussed that
already on the list here at the beginning of this
thread, but the fake user approach will only work reliably for RFC2307
setups, where the user names of the group members are stored in the
My patch currently only addresses the RFC2307bis approach, and there you
need to read the actualy LDAP objects in order to find out the username
(ok there are corner cases where you can derive the user names from the
DN but I think we agreed during the discussion not to do such hacks). And
it then it is better to actually request the complete users objects and
populate the cache with those instead of fake entries.
details, please see Simo's breakdown here:
My proposal is to modify your patch #2 to not lookup the users in
LDAP, but rather save these fake expired entries.
For rfc2307bis those lookups are
needed unfortunately. But for rfc2307
setups that's of course the right way to go.
I have implemeted this for initgroups (adding fake group entries)
started on getgrname (or rather sdap_save_group). I have pushed
patches into my fedorapeople git repository (master branch), if you'd
like to take a look.
Yes, I will.