RE: ITS#857 - status? (fwd)

["Howard Chu" <hyc@highlandsun.com>]

This sounds very complicated to me. For use in back-ldap/proxy backend, I
don't see the need for multiple rewrite contexts. Each remote server that
you define encompasses a single naming context. Any schema/attribute mapping
required to interoperate with that remote server will need to be universally
applied to every request/response exchanged with that remote server.
Breaking up rewrite rules by operation type seems to me to add unnecessary
complexity...

There are already suffixAliases and such for tweaking the backend selection
process. I'm not sure why that should be changed.

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc

> -----Original Message-----
> From: ando@sys-net.it [mailto:ando@sys-net.it]
> Sent: Friday, January 19, 2001 11:58 PM
> To: Howard Chu
> Cc: kurt@openldap.org; openldap-devel@openldap.org
> Subject: Re: ITS#857 - status? (fwd)
>
>
> Howard Chu wrote:
>
> > If you are interested in working on this, please do. I haven't had very
> > much time lately... It looks to me like the rewriting is very flexible,
> > but I don't fully understand the syntax yet. Also, rewriting is only
> > implemented for compare and search, and I think it would be nice to
> > generalize it so it can also be used for add/modify. I'm not sure why
> > compare rules need to be separate from search rules, I believe
> a complete
> > mapping ought to be generally usable for any operation.
>
> Howard,
>
> I've written a rewrite library that can be applied in a
> straightforward manner
> to strings at any point in the slapd. I noticed only recently the
> nice work
> submitted
> with ITS#857 and it could be interesting to merge the two things.
> I don't want to steal credits from others: I've been mainly
> inspired by Apache's
> mod_rewrite with something from the rule syntax of sendmail, but
> I didn't even
> read such codes, only documentation.
> I don't want to go into excessive details now, I'm trying to
> write an essential
> documentation for it. I'd rather like to discuss how it could be
> integrated with
> back-ldap or even slapd itself (the latter is what I prefer - as
> required by the
> needs that drove my work). The rewriting is based on simple rules
> of the kind:
>
> pattern (with submatches) -> match ? rewrite [ -> actions ]
>                                    |
>                                    v
>                             leave untouched
>
> The rules are collected in what I called 'rewrite contexts', that
> is the name
> that is used to unvoke the rewriting. Things like submatches, recursive
> invocation of rewrite contexts, variable setting and
> dereferencing, dynamic
> rewrite maps and so are supported. I have provided hooks to let
> the application
> set some vars in advance (e.g. the client name and IP  of who made the
> connection in case of the slapd would be a nice idea).
>
> Moreover, a 'session' can be established, which allows to
> preserve variables
> across rewrite contexts. An example tailored on slapd or back-ldap would
> probably help.
>
> Think of rewrite contexts as:
>
>     client -> server
> bindDn, searchBase, searchFilter, compareDn, addDn, modifyDn,
> modrDn, deleteDn,
>
>     server -> client
> searchResult, referral
>
> rules can be defined for each context; they are invoked at the
> very first/last
> moment
> their subject (dn, filter, referral) shows up at back-ldap (slapd), so the
> server/client
> actually sees only the rewritten stuff. Moreover, as soon as a
> connection is
> performed,
> a 'rewrite session' is initialized, to allow variable sharing
> between different
> contexts.
>
> Of course, if no context is available, no rewriting takes place;
> moreover, you
> can
> also define a 'default' context, and let it aliase other contexts
> if they're not
> defined.
>
> Obviously the rewriting applies to the strings related to the
> contexts; e.g. in
> case
> of bindDN, the dn may be rewritten, stored for later retrieval in
> session scope,
> and
> so on.
>
> I'm going to submit all this stuff very soon, but I need to clean
> up alot and add
> some
> features that are still to do. At present, the rewrite engine
> with most of the
> stuff I
> described is ready and being tested, but integration with
> back-ldap (slapd) is
> still
> at an early stage. The reason I'm writing you this long message
> is to give you
> the
> flavor of the thing and get some hints on where should it be
> better to place
> rewriting.
>
> In my opinion there are two (three) solutions:
>
> - 'paranoid': in slapd, right after ber decoding and right before
> search result
> sending!
> - in back-ldap (or in any backend that might take advantage of
> it), after the
> backend
>     has been selected but before any operation begins.
> - both?
>
> in the second case, by interpreting the rewrite contexts as
> 'rewrite URIs', an
> interesting rule-based proxy may be implemented, by dinamically
> selecting the
> URI of the operation (including server and protocol, e.g. ldap vs ldaps).
> In the first case we'd get the important capability of
> influencing the backend
> selection phase.
>
> If you'd like to get a snapshot of the code, please let me know.
>
> Pierangelo.
>
> PS to Kurt:
> In case this sounds interesting to you, suggestions are welcome!
>
>
> --
> Dr. Pierangelo Masarati, mailto:ando@sys-net.it
> Developer, SysNet s.n.c. http://www.sys-net.it
>
>
>