[Date Prev][Date Next]
rewrite capabilities in back-ldap (ITS#989)
Full_Name: Pierangelo Masarati
OS: Linux RH 6.2
Submission from: (NULL) (184.108.40.206)
I submitted a patch that adds general rewriting capabilities toback-ldap.
A library, called `rewrite', has been put in libraries/librewrite. It is
quite general and can be reused outside of back-ldap.
All the features that are currently implemented, and some development
are described in the file libraries/librewrite/RATIONALE.
The back-ldap module has been modified to call appropriate rewriting
rules to the dns on all the operations that allow/require one, e.g.
bind dn, add dn, modify dn, delete dn, modrdn dn and newsuperior i f any,
compare dn, search base, search result, and to search filters.
The basic syntax is straightforward and should fit well in slapd.conf;
the rule writing may be cumbersome (those who played with Apache's mod_rewrite
know ...). All these functionalities supersede the `suffixmassage' features
I proposed in ITS#924 and that were recently commited to the devel branch.
These functionalities can be now achieved by adding the rules:
# client to server operations have the virtual naming context rewritten
rewriteRule ".*<virtual naming context>" "%0<real naming context>"
# server results have the virtual naming context rewritten back
rewriteRule ".*<real naming context>" "%0<virtual naming context>"
# no filter rewriting (otherwise default would be used)
I tested it with a very recent checkout of the devel branch; everything
seems to work fine, however the code is VERY EXPERIMENTAL, and of course
it is very sensitive to errors in rules (you can have hard times in
debugging rules; for this purpose, a simple client that tests rules, called
`rewrite', comes with the distribution (in libraries/librewrite).
It is NOT documented (I swear I will do it). I noticed a strange behavior
in playing with filter rewrite: at least in two cases I crashed the server
the back-ldap was pointing to by misrewriting the search filter; however I
haven't been able to reproduce the problem yet. Another point is the thread
stuff, I didn't check it thoroughly. I tried to hit the server with multiple
heavy requests with rules that exploited the mutex protected stuff, and
everything worked fine, but I didn't make any deep analysis of possible
deadlocks or conflicts.
Please check and let me know.