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.
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.
Long term, I'm planning to replace all this infrastructure to FreeIPA
(http://www.freeipa.org/) which is supposed to be a more robust
product, but that is going to take a while, so I'm trying to at least
do the best I can with what I have now.
Sorry for the long e-mail! Any help and advices will be appreciated.
Thanks a lot!
Filipe
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
