[SAMBA4] Using ldb_map for pure translations
mkhl at samba.org
Tue Aug 1 22:49:58 GMT 2006
On 8/1/06, Andrew Bartlett <abartlet at samba.org> wrote:
> I started on an entryUUID module, but I'm wondering if we should either
> have lots of extra logic in the current ldb_map to cope with never
> reading a local database, or create a new module, sharing many of the
> support routines (which replace values in the parse tree).
I'm not sure if it would really require lots of extra logic.
The largest subproblem seems to be handling of attributes without an
associated mapping. My first reaction was to propose "catch-all"
mappings of a form like
.local_name = "*",
.type = MAP_KEEP,
but as the only sensible choices here seem to be MAP_KEEP and
MAP_IGNORE (which is implicitly used right now), we could just
parameterize the module with this choice.
With that in place, targeting only a single partition would be
immediate for add/modify requests (as the local message would always
be empty) and could be done easily for the other requests (with a test
whether the base DNs are equal, say).
I'm hesitant about sharing the support routines because the
differences between our intentions would affect both high- and
low-level routines and we would be limited to sharing those in
between. That said, the request handling should be a lot easier for a
single partition, so only the low-level routines would need to be
changed, and ripping out the mapping routines should make the current
module less unwieldy.
Still, I think I prefer the former option.
> My initial attempts are attached.
> What do you think?
They're looking pretty straightforward. And make me think of a whole
bunch of problems one will run into when the local and remote base DNs
are equal, so thanks for raising the issue.
Any specific reason you pushed the call to `find_local_attr' down into
> If we can make this work, I would like to merge your ldb_map code into
> the mainline. What is the best way to do this?
I'm still working on an issue with parse-trees, and I'd like to clean
the module up a little (rename/reorder functions, use fewer gotos,
maybe add section headers), but should be done in one or two days.
After that, I can supply a patch to the list for review (and bashing
my coding style :-). And eventually, someone (me?) might merge my
More information about the samba-technical