[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: modify dn while replication

Pierangelo Masarati wrote:

Sorry but before playing with rewrite engine, I encontered basic
problems just to replicate from master to slave through a proxy server
:-(



There's a twofold problem: to allow user-modification
on non-user modification attributes (which is required
by replication) you need to add

updatedn <your upodate dn>



OK I added this directive to my slapd_proxy.conf file, now it works fine :-) , a least the replication to a slave through a proxy !

to the proxy; unfortunately, these are stripped by
back-ldap, exactly because they're tagged as
"no user modification" attributes in the schema.


what do you mean by strip ?, the fact that it worked, doesn't mean that everything's OK now ?

A quick'n'dirty hack is to remove the no user mod
from the schema on the proxy machine; unfortunately
most of the no user mod attributes actually are not
in schema files but hardcoded, so you need to hack
the source.


You mean these attributes: entryCSN modifiersName modifyTimestamp
Indeed I've seen this definition in servers/slapd/schema_prep.c
{ "entryCSN", "( 1.3.6.1.4.1.4203.666.1.7 NAME 'entryCSN' "
"DESC 'LCUP/LDUP: change sequence number of the entry' " "EQUALITY octetStringMatch "
"ORDERING octetStringOrderingMatch "
"SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{64} "
"SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation )",
NULL, SLAP_AT_HIDE,
NULL, NULL, NULL, NULL, NULL,
offsetof(struct slap_internal_schema, si_ad_entryCSN) }

I would have to remove the "NO-USER-MODIFICATION" from it, on every attributes in that file, why this schema definition are hard coded ? why don't put them in /etc/openldap/schema files ?
Anyway, for me it seems to work fine now ... perhaps I'll encounter pb later with rewrite engine ? do you think I shall go through these dirty modification in the source code :-( ?

A clean solution would be to add a parameter to
back-ldap that allows to pass-over no user modification
stuff at least if the proxy is configured to
propagate replica stuff.

This could be done very easily, if you agree on playing
with HEAD code.


Maybe , but how ? you plan on adding this "parameter" to the HEAD code ? again adding the updatedn to slapd_proxy.conf worked, so can I just continue this way ?

Thanks a lot .

p.



here's the error message on the proxy server logs:
Feb 16 16:27:23 corbeau slapd[15683]: conn=0 op=1 MOD
dn="uid=test,ou=People,dc=int-evry,dc=fr"
Feb 16 16:27:23 corbeau slapd[15683]: conn=0 op=1 MOD attr=userPassword
homePostalAddress entryCSN modifiersName modifyTimestamp
Feb 16 16:27:23 corbeau slapd[15683]: conn=0 op=1 RESULT tag=103 err=19
text=entryCSN: no user modification allowed


slapd.conf: (running on localhost port 389)
database        bdb
suffix          "dc=int-evry, dc=fr"
rootdn          "cn=admin, dc=int-evry, dc=fr"
rootpw          secret
directory       /var/lib/ldap/int
replica         host=127.0.0.1:8006
               binddn="cn=replicator,ou=System,dc=int-evry,dc=fr"
bindmethod=simple   credentials=secret
replogfile      /var/lib/ldap/replica/replogfile


slapd_proxy.conf: (running on localhost port 8006)
database ldap
suffix          "dc=int-evry,dc=fr"
uri             "ldap://127.0.0.1:9006";;
lastmod on
binddn cn=admin,dc=int-evry,dc=fr
bindpw secret

slapd_slave.conf: (running on localhost port 9006)

database        bdb
suffix          "dc=int-evry,dc=fr"
rootdn          "cn=admin,dc=int-evry,dc=fr"
rootpw          secret
directory       /var/lib/ldap/int_slave
updatedn        "cn=replicator,ou=System,dc=int-evry,dc=fr"
updateref       "ldap://127.0.0.1:389";

What a I doing wrong ?,

thanks .


Pierangelo Masarati wrote:



Pierangelo Masarati wrote:





It could be possible, but it's going to be rather clumsy;
it depends on whether there's a clear way you can extract
a filtering attribute from the DN, e.g. the "uid=<smtg>"
part, to do:

rewriteMap      ldap uidMap "ldap:///<naming context>?uid?sub"
rewriteRule     "^(uid=[^,]+)(,.*)$$" "%1-%{uidMap(%1)}%2" ":@I"







OK thanks a lot for the example :-), I'll try out, but before one
question, where should I put
these rewrite rules, in the replica section of the master ? this way :

replica         host=127.0.0.1:9006
              suffix="ou=people,dc=int-evry,dc=fr"

attr!="posixAccount,shadowAccount,loginShell,homeDirectory,uidNumber,gidNumber,gecos"
              binddn="cn=replicator,ou=people,dc=int-evry,dc=fr"
bindmethod=simple   credentials=secret
              rewriteMap      ldap uidMap
"ldap:///ou=People,dc=int-evry,dc=fr?uid?one";
              rewriteRule     "^(uid=[^,]+)(,.*)$$"
"%1-%{uidMap(%1)}%2" ":@I"
replogfile /var/lib/ldap/replica/replogfile

or on a dediceted ldap or meta backend ? sorry for beeing so ignorant,
but it's the first time I play with the rewrite engine ! by the way, I
suspect I need a " rewriteEngine on" somewhere, in slapd.conf ?




Sorry, my answer was incomplete.  Yes, you need to replicate
thru a proxy server, e.g. a server in between the master and
the slave so that

master --> m2s-proxy: uid=test,... ==> uid=test-number,... --> slave

you need to figure out what you intend to do with referrals


from slave to master; if you need to rewrite as well, then 


you need another proxy to revert the massaging.

slave --> s2m-proxy: uid=test-number,... ==> uid=test,... --> master

the proxy needs to be a back-ldap compiled with --enable-rewrite, and
needs to be configured with

database ldap
uri ldap://<slave>
lastmod on
rewriteEngine on
rewriteContext default
<rules as in example>

Note:

if the proxy is used also for normal operations,
you'll need to deal with other rewrite contexts,
e.g. searchBase, searchFilter, compareDN,
compareAttrDN if you want any rewriting to occur
in these cases.

you'll also need to deal with searchResults and more,
otherwise they'll be treated with the default rules.
see slapd-meta(5) in the REWRITE section for what
rewrite contexts are active.  otherwise you can add

rewriteContext searchBase
rewriteContext searchFilter
rewriteContext compareDN
rewriteContext compareAttrDN

rewriteContext searchResult
rewriteContext searchAttrDN
rewriteContext matchedDN

if you don't want any rewrite to occur for these
rewrite contexts.

On the contrary, the default rewriting should occur
for any write operation; the default naming context
is picked if you don't specify any.

Note: the "lastmod on" should work since the target
is a replica; it is important wince you want the
replica to be in sync with the master also in terms
of timestamps.

p.