[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: ldapsearch on local attributes with slapo-translucent



<quote who="Howard Chu">
> Gavin Henry wrote:
>> Julien Garnier wrote:
>>> Gavin Henry a écrit :
>>>> Yes, as I thought. Translucent doesn't return searches on local
>>>> attributes.
>>>>
>>>> One for the to do list then.
>
> Yes... The original spec for this overlay only required the ability to
> search
> the remote DB. Searching both requires quite a lot more work.

I agree, after poking at the code with my beginner skills.

>
> One sticking point is that search filters need to be munged; if you send a
> filter to the remote server and it mentions attributes that are only known
> on
> the local server, then you may not get any results back at all. (And vice
> versa.)

Right.

>
> E.g., if you have a remote entry containing
> 	uid=foo
> and the local translucent entry containing
> 	cn=bar
>
> and you search for (&(uid=foo)(cn=bar)) then the search will return no
> results
> unless you rewrite the filter on both the local side and the remote side.
>
> A solution here would be to add config keywords to control how filters
> should
> be handled. For any attribute used in a filter, it may be remote only,
> local
> only, or both local and remote.

That could work, as long as you have the correct indexes on local and
remote so as not to be a complete hog.

>
> The processing would go something like -
> 	for the remote search, walk through the filter and nullify any clauses
> that
> aren't in the list of remote attributes. If the filter collapses down to
> nothing, skip the remote search. Otherwise, execute the search and keep a
> list
> of the results.

Right.

> 	for the local search, process the filter as above; if the filter
> collapses,
> skip the local search. Otherwise, execute the search and keep a list of
> the
> results.

Right.

> 	for each entry in the remote list, look for a corresponding entry in the
> local list and the local DB. Merge the entries.
> 	for each entry in the local list, do likewise.
> 	merge the lists
> 	reprocess the list using the original filter.
>
> Quite a lot of steps.

Agreed.

My original plan was to merge a remote with a local *and* use rwm to setup
different ou etc. for Asterisk Voip accounts to try and map these users to
any foreign Directory ;-)

Stick rwm in the overlay stack somewhere for a laugh.

Gavin.