We've talked about this before; it would be nice for the consumer to be able to pull updates from a different suffix on the provider than the one in use on the consumer. Just attaching the rwm overlay is not straightforward, since that expects to sit on a database and the consumer's queries are sent through direct LDAP calls. A potential kludge for this would be to rewrite all of the consumer client code in terms of backend calls through a back-ldap instance. That seems a little heavy-handed though.
Another possibility may be to just expose some of the rwm overlay's entry points so the consumer can call them explicitly, faking enough of the context so we can call suffixmassage config. Suggestions?
We've talked about this before; it would be nice for the consumer to be able to pull updates from a different suffix on the provider than the one in use on the consumer. Just attaching the rwm overlay is not straightforward, since that expects to sit on a database and the consumer's queries are sent through direct LDAP calls. A potential kludge for this would be to rewrite all of the consumer client code in terms of backend calls through a back-ldap instance. That seems a little heavy-handed though.
Another possibility may be to just expose some of the rwm overlay's entry points so the consumer can call them explicitly, faking enough of the context so we can call suffixmassage config. Suggestions?
Considering to limit ourselves to suffix massaging (no attribute mapping, but DN-valued attribute massaging) we could operate at the entry level, since the client either operates on entryUUIDs or turns messages into entries before operating on them. In this case, an entry_massage() call that either no-ops or massages DNs would minimize the impact.
p.
masarati@aero.polimi.it wrote:
We've talked about this before; it would be nice for the consumer to be able to pull updates from a different suffix on the provider than the one in use on the consumer. Just attaching the rwm overlay is not straightforward, since that expects to sit on a database and the consumer's queries are sent through direct LDAP calls. A potential kludge for this would be to rewrite all of the consumer client code in terms of backend calls through a back-ldap instance. That seems a little heavy-handed though.
Another possibility may be to just expose some of the rwm overlay's entry points so the consumer can call them explicitly, faking enough of the context so we can call suffixmassage config. Suggestions?
Considering to limit ourselves to suffix massaging (no attribute mapping, but DN-valued attribute massaging) we could operate at the entry level, since the client either operates on entryUUIDs or turns messages into entries before operating on them. In this case, an entry_massage() call that either no-ops or massages DNs would minimize the impact.
Good idea. Since we already use librewrite for authz-regexp there's probably no reason to tie this into the rwm overlay at all, this should be pretty simple.
For the purpose I have in mind (replicating cn=config from a different branch on the provider) there's no need for any other mapping. If more complex mappings are needed, the relay database should work:
database relay suffix o=example,c=us syncrepl rid=001 ... overlay rwm rwm-suffixmassage dc=example,dc=com ...
database hdb suffix dc=example,dc=com ...
-
Howard Chu -
masaratiļ¼ aero.polimi.it