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

Re: modify dn while replication



Sorry for delays ... I've got lot of urgent stuff going on ...
Anyway I try to work on this project from time to time. I decided to install openldap 2.2.6, so I upgraded my openldap.spec file (I use homebuilt RPMs http://www.int-evry.fr/mci/user/procacci/SRPMS/) The problem is that when I try to upgrade openldap from 2.1.25 to 2.2.6 on my RedHat 9 system I get :
$ rpm -Uvh openldap-2.2.6-1.i386.rpm openldap-devel-2.2.6-1.i386.rpm openldap-servers-2.2.6-1.i386.rpm openldap-clients-2.2.6-1.i386.rpm
error: Failed dependencies:
liblber.so.2 is needed by (installed) php-ldap-4.2.2-18.3
liblber.so.2 is needed by (installed) autofs-3.1.7-36
liblber.so.2 is needed by (installed) postfix-2.0.11-5
liblber.so.2 is needed by (installed) nss_ldap-202-5
etc ....


I noticed that openldap 2.2.6 provides :
$ rpm -qpli openldap-2.2.6-1.i386.rpm | grep liblber
/usr/lib/liblber.so.199
/usr/lib/liblber.so.199.3.4

I'am a bit lost in liblber.so versions here . Is my present openldap 2.1.25 liblber.so.2 older or newer than the one provided by openldap 2.2.6: /usr/lib/liblber.so.199 ? Will I brake dependances if I rpm --force my new openldap-2.2.6 packages ?

Thanks for the advice .

PS: I didn't find any embeded version number from the lib:
$ strings /usr/lib/liblber.so.2 | grep liblber
liblber.so.2
../../../libraries/liblber/decode.c
../../../libraries/liblber/encode.c
../../../libraries/liblber/io.c
../../../libraries/liblber/bprint.c
../../../libraries/liblber/memory.c
../../../libraries/liblber/options.c
../../../libraries/liblber/sockbuf.c
@(#) $OpenLDAP: liblber.la 2.1.25 (Feb 18 2004 09:49:26) $
root@corbeau:/usr/src/redhat/BUILD/openldap-2.1.25/build-clients/libraries/liblber




Pierangelo Masarati wrote:

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.