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

Re: Red Hat rpms [was: modify dn while replicating]



Medievalist wrote:

Hi Jehan

Are you still keeping the red hat patches in the SRPMS, like we did on the 2.1.25 builds? They may be very inappropriate on 2.2.x... I suspect the OpenLDAP team has already implemented fixes for the stuff Nalin was patching in 2.0.x and the two sets of fixes may cause problems.


No I've removed some ... cf my recent mail to the list to jens@zope.com

If you get a working 2.2 src.rpm I'll build the binaries for RH EL3, but I won't be actively testing them this time around since my plate is more than full already.

As far as I know you are still the only one hosting Red Hat-compatible binary .rpms for current versions of OpenLDAP. Thank you again for that!



I'am "hosting" but apparently others are also building ! (cf jens !)
I'll let you know if I finaly get it working.

--Charlie


On 4 Mar 2004 at 16:19, jehan.procaccia wrote:



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.