[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: modify dn while replication
Jehan,
I had no problems ith replication thru the proxy; I've been able
to use the whole stuff round, from add to modify to delete, with
three caveats:
1) I couldn't add a user with rewritten DN until I added two values
to "uid", e.g. "uid=test" and "uid=test-XXXXX" because in your case
"uid" is a naming attribute, so the slave wants the value that is
used in the DN present into the entry. This requires the master
to be modified by adding the NEW value of the "uid" to the
existing value before replication takes place.
2) I think there might be issues whenever the attributes "uid"
and "IntEPersUserPTM" are modified because it's difficult to
rewrite the DN correctly.
3) I couldn't delete the user because, as soon as it is deleted on
the master, the proxy is no longer able to generate the new DN.
I could work this around by using two maps: one pointing and the
master, used by default, and one pointing to the slave, used in
case of failure of the first one (usually, only during deletion).
This required a slight modification to the rewrite code because
the currently released code ignores search errors, including no
results, from maps.
As a consequence, the setup seems to work (I dodn't check yet writes
to the slave and proxying the reverse way).
I'm attaching the configure files and the ldif files I used to
test the system; I didn't use your schema to simplify stuff, that's
why you'll see that I've been using the "employeeNumber" attribute
instead of "IntEPersUserPTM", but this should be a minor difference.
<slapd/master.conf>
database bdb
suffix "dc=int-evry,dc=fr"
directory ./evry/db-master
rootdn "cn=Manager,dc=int-evry,dc=fr"
rootpw secret
index objectClass eq
index cn,sn,uid pres,eq,sub
replica uri=ldap://localhost:9010
bindmethod=simple
binddn="cn=replicator,dc=int-evry,dc=fr"
credentials=replicator
replogfile ./evry/master.replog
<slapd-proxy.conf>
database ldap
suffix "dc=int-evry,dc=fr"
rootdn "cn=Manager,dc=int-evry,dc=fr"
uri ldap://localhost:9012/
rootpw secret
lastmod on
updatedn "cn=replicator,dc=int-evry,dc=fr"
rewriteEngine on
rewriteContext default
rewriteMap ldap uidMap1
"ldap://:9009/dc=int-evry,dc=fr?employeeNumber?one";
rewriteMap ldap uidMap2
"ldap://:9012/dc=int-evry,dc=fr?employeeNumber?one";
rewriteRule "^(uid=[^,]+)(,.*)$$" "%1-%{uidMap1(%1)}%2" ":@I"
rewriteRule "^(uid=[^,]+)(,.*)$$" "%1-%{uidMap2(%1)}%2" ":@I"
<slapd-slave.conf>
database bdb
suffix "dc=int-evry,dc=fr"
directory ./evry/db-slave
rootdn "cn=Manager,dc=int-evry,dc=fr"
rootpw secret
index objectClass eq
index cn,sn,uid pres,eq,sub
updatedn "cn=replicator,dc=int-evry,dc=fr"
updateref "ldap://localhost:9009/";
access to attrs=userPassword
by dn.exact="cn=replicator,dc=int-evry,dc=fr" write
by * auth
access to *
by dn.exact="cn=replicator,dc=int-evry,dc=fr" write
by * read
I ran:
../servers/slapd/slapd -f evry/slapd-master.conf -h ldap://:9009 -d 256
../servers/slapd/slapd -f evry/slapd-proxy.conf -h ldap://:9010 -d -1
../servers/slapd/slapd -f evry/slapd-slave.conf -h ldap://:9012 -d -1
../servers/slurpd/slurpd -f evry/slapd-master.conf -t evry/ -d 256
I used HEAD code as of today, with a small change
to libraries/librewrite/subst.c to be able to replicate
deletions (you can check it out from the CVS).
I first loaded this in master and slave out of the
replication mechanism (you may use slapadd)
<preload.ldif>
dn: dc=int-evry,dc=fr
objectClass: organization
objectClass: dcObject
o: Evry
dc: int-evry
dn: cn=replicator,dc=int-evry,dc=fr
objectClass: inetOrgPerson
cn: replicator
sn: replicator
userPassword: replicator
ou: People
I ran this test:
<test.ldif>
dn: uid=test,dc=int-evry,dc=fr
changetype: add
objectClass: inetOrgPerson
uid: test
uid: test-000001
cn: Test User
sn: Test User
employeeNumber: 000001
dn: uid=test,dc=int-evry,dc=fr
changetype: modify
add: description
description: This is a test user
dn: uid=test,dc=int-evry,dc=fr
changetype: delete
note that, at least on my laptop, you need to run the three
operations separately, otherwise addition is too slow to
allow DN rewriting during replication, and the whole thing
fails. It may fail in two ways: if ALL the DN in the form
"uid=<smtg>,dc=int-evry,dc=fr" MUST be rewritten, then delete
the "I" from the last rewtire rule flags; this causes rewrite
to fail if no rule succeeds. Otherwise, you need to live with
that "I" ignore flag, so in case of failure, the DN is passed
over without rewriting, which might not be what you want.
Hope this helps, though.
p.
--
Dr. Pierangelo Masarati mailto:pierangelo.masarati@sys-net.it
LDAP Architect, SysNet s.n.c. http://www.sys-net.it
SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497