[Date Prev][Date Next]
Re: ldapsearch on local attributes with slapo-translucent
- To: "Howard Chu" <firstname.lastname@example.org>
- Subject: Re: ldapsearch on local attributes with slapo-translucent
- From: "Gavin Henry" <email@example.com>
- Date: Wed, 28 Nov 2007 16:23:03 -0000 (GMT)
- Cc: OpenLDAP Devel <firstname.lastname@example.org>
- Importance: Normal
- Openpgp: id=796B1E87DB73BEA8
- User-agent: SquirrelMail/1.4.11-1.fc8
<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
>>>> One for the to do list then.
> Yes... The original spec for this overlay only required the ability to
> 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
> the local server, then you may not get any results back at all. (And vice
> E.g., if you have a remote entry containing
> and the local translucent entry containing
> and you search for (&(uid=foo)(cn=bar)) then the search will return no
> 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
> be handled. For any attribute used in a filter, it may be remote only,
> 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
> 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
> of the results.
> for the local search, process the filter as above; if the filter
> skip the local search. Otherwise, execute the search and keep a list of
> 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.
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.