These patches add support for multiple search bases for users and
in non-enumeration mode. I want to get these out for review before I
start working on the enumeration support, so if there are major issues
they will be found before I put in a lot more work.
Some notes: There is no patch adding multiple search base support for
group lookups in RFC2307bis because it's meaningless right now. Since
the group memberships are direct DNs, we do all of our searches as base
searches, ignoring group_search_base. There is a separate ticket,
that will need to address this,
taking advantage of the multiple search base features.
Also, while working through this, I opened
as I noticed that we are using
far too many separate transactions while processing RFC2307bis (which is
likely the cause of the extreme slowdown that some of our users were
reporting with AD).
Thank you, and please review promptly.
Patch 0001: Remove some unused options in a struct
Patch 0002: Fix size return for split_on_separator()
It was returning the size of the array, rather than the number of
elements. (The array was NULL-terminated). This argument was only
used in one place that was actually working around this odd return
Patch 0003: Make sdap_get_id_specific_filter() more strict
Just makes it take const char * instead of char *.
Patch 0004: Add parser for multiple search bases
As discussed on the list, this will the ldap_*_search_base options in
the form of:
This is backwards-compatible (just use a search base)
Why haven't you used the for cycle to parse search bases? Personally I'd
prefer it that way, but I guess it is nothing wrong to do it this way either.
Other than that the patch is fine.
Patch 0005: Add support for multiple search bases for users
Patch 0006: Add support for multiple search bases for netgroups
Patch 0007: Add support for multiple search bases for RFC2307 groups
Patch 0008: Add support for multiple search bases for initgroups (user
Ack to all four
Patch 0009: Add support for multiple search bases for initgroups
(RFC2307 group portion)
Is this the correct behavior? I mean if we find user, is it correct to look for
for its initgroups in other search bases than the one we found the user in? It
doesn't seem right to me.
Patch 0010: Add support for multiple search bases for initgroups
(RFC2307 group portion)
This patch I'm not 100% sure of. It may need more processing. With
RFC2307, it was safe to have duplicate groups in the list, because only
the group name is important (and we guarantee that the name list has
only unique values before saving it). With RFC2307bis, I'm not sure if
it's safe to add two groups that may have the same name. Comments
The same as for 0009, I didn't go through the entire patch yet, more comments
might come up
Patch 0011: Temporary patch that just disallows the use of multiple
search bases when enumeration mode is turned on. We can drop this patch
when the enumeration support is available.