<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
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.