syncrepl in OpenLDAP 2.3.x and updating on a replica

[Filipe Brandenburger <filipe.brandenburger@idilia.com>]

Hi,

I have a setup with two CentOS 5 machines running OpenLDAP 2.3.x,
right now the primary uses slurpd to send the updates to the second
server, and the second server is using "updatedn" to allow updates
(from what I understand! I'm no OpenLDAP guru here.) Clients are using
pam_ldap and nss_ldap to get the users and authenticate them in LDAP.
Right now hosts query only the primary LDAP server, that is the
address set on the "host" variable of /etc/ldap.conf. Changing
password with "passwd" works fine, and the password is correctly
replicated to the secondary server.

Now, first thing, I wanted to load balance between the two servers.
The way I did it was to register a Round-Robin DNS record, with one A
entry for each server IP, and I used that entry in the "host" variable
of /etc/ldap.conf. Everything worked. Queries going each time to a
different server. I was expecting to have problems changing passwords,
but amazingly it worked. Apparently when a password change request
goes to the second server, that server will do a query on the first
server to do the password change, and then (through slurpd) the change
gets replicated on the second one. Everything great. (Is there a better
configuration for pam_ldap and nss_ldap on /etc/ldap.conf for load
balancing other than round-robin DNS?)

Now, I was reading that syncrepl is superior to slurpd, and that
syncrepl is the preferred method of replication. I actually saw that
it's true when I saw that it actually replicated the master without
having to stop it and copy the dbs (which is necessary with slurpd.) I
even saw that in OpenLDAP 2.4.x slurpd is deprecated/discontinued and
only syncrepl is supported.

So I'm trying to migrate from slurpd to syncrepl.

And so far everything is working fine in my test environments.

This is what I have configured on the master:

overlay syncprov
syncprov-checkpoint 1 10
syncprov-sessionlog 100

And on the slave:

syncrepl rid=1
       provider=ldap://ldap1.mydomain.com
       type=refreshAndPersist
       searchbase="dc=mydomain,dc=com"
       schemachecking=off
       bindmethod=simple
       binddn="cn=Manager,dc=mydomain,dc=com"
       credentials=xxxxxxxxxxx
updateref ldap://ldap1.mydomain.com/



It works with queries, and when I do an update on the master, it
replicates fine to the slave.

But when I try to do some change on the slave, that's what I get:

$ ldapdelete -H ldap://ldap2.mydomain.com/ -D
cn=Manager,dc=mydomain,dc=com \
       -w XXXXXXX -x uid=usertodelete,ou=Users,dc=mydomain,dc=com

ldap_delete: Referral (10)
       referrals:

ldap://ldap1.mydomain.com/uid=usertodelete,ou=Users,dc=mydomain,dc=com



I would like to have something closer to what happens when using
slurpd, which seems to be more transparent to clients. I tried to set
"updatedn" but slapd complained that it is supported when using
slurpd.

I also tried to start configuring overlay on the slave and syncrepl on
the master, but when I do that I can't run updates on either side,
both of them end up being read-only. I read that on OpenLDAP 2.4.x
Administration Guide, on the section about multi-master replication,
but I then saw that multi-master replication is supposed to work only
on 2.4.x, and not on 2.3.x, so that's apparently not an option.

So I ask: is there a way to configure OpenLDAP so that the slave
(running syncrepl) can send updates to the master when receives from a
client?

Or (not as good but still an option): If I use "updateref" to send
Referral, how can I make sure the tools (ldapdelete, ldapmodify,
ldapadd, ...) actually *follow* the referral (I looked for that in man
pages and didn't find any obvious options for that)? And more
important, will pam_ldap and nss_ldap follow those referrals when
changing the password? Do I have to set something on /etc/ldap.conf
for that?

Upgrade to 2.4.x is something I would like to avoid, since I would
rather stick with what is supported by CentOS 5.

Sorry for the long e-mail! Any help and advices will be appreciated.

Thanks a lot!
Filipe