Red Hat rpms [was: modify dn while replicating]

["Medievalist" <ldap@hbcs.org>]

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.

  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!

--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.
> >