guitaristx
asked on
OpenLDAP replication problems
I'm configuring a pair of servers, called tome and lexicon, that are going to serve as master and slave LDAP servers, respectively.
However, when I log into lexicon with an LDAP client, and make changes, the changes don't propagate downward to tome. Furthermore, when I log onto tome's console and use slapadd to make changes to its directory, those changes don't propagate up to lexicon.
I've gone through the slapd and slurpd Administrator's Guide, and it seems as though I've got everything configured properly, but I just can't seem to get the two servers to play nice with one another. Any ideas?
However, when I log into lexicon with an LDAP client, and make changes, the changes don't propagate downward to tome. Furthermore, when I log onto tome's console and use slapadd to make changes to its directory, those changes don't propagate up to lexicon.
I've gone through the slapd and slurpd Administrator's Guide, and it seems as though I've got everything configured properly, but I just can't seem to get the two servers to play nice with one another. Any ideas?
ahoffmann
have you configure as multi-master, or master-slave?
ASKER
master-slave.
As an update, I can make changes on the master, and they get propagated up to the slave, but the slave doesn't seem to be propagating its changes back to the master.
As an update, I can make changes on the master, and they get propagated up to the slave, but the slave doesn't seem to be propagating its changes back to the master.
ASKER
Another update - it seems as though referrals from the slave to the master are not happening.
slaves cannot propagate changes to the master, they are read-only
ASKER
I agree, in theory, a client should never make changes to a slave.
However, according to the slapd & slurpd Administrator's Guide, the slave refers the client to the master when changes are to be made. This is not happening, and I can't figure out why.
However, according to the slapd & slurpd Administrator's Guide, the slave refers the client to the master when changes are to be made. This is not happening, and I can't figure out why.
> .. the slave refers the client to the master when changes are
hmm, I know from iPlanet/Sune ONE that the slave (even if read-only) "caches" changes which are made to the master if that is uneachable somehow. They are written to the master when it comes back.
AFAIK with openLDAP you have to use multi-master for that.
hmm, I know from iPlanet/Sune ONE that the slave (even if read-only) "caches" changes which are made to the master if that is uneachable somehow. They are written to the master when it comes back.
AFAIK with openLDAP you have to use multi-master for that.
ASKER
I didn't see anything about that in the Admin Gude:
http://www.openldap.org/doc/admin22/replication.html
I just can't figure out why the referral isn't taking place.
http://www.openldap.org/doc/admin22/replication.html
I just can't figure out why the referral isn't taking place.
ASKER
Also, when I attempt to add a new record through the slave, I'm getting:
LDAP error code 80 -
no structuralObjectClass operational attribute
I've been googling the heck out of this error message, and I've come up with absolutely squat. GRRR! This is frustrating.
<raised point value>
LDAP error code 80 -
no structuralObjectClass operational attribute
I've been googling the heck out of this error message, and I've come up with absolutely squat. GRRR! This is frustrating.
<raised point value>
ASKER
Attempted using ldapadd from the console, got:
error code 53: unwilling to perform - no global superior knowledge
error code 53: unwilling to perform - no global superior knowledge
ASKER
Allright, I've solved my own problem. Here's the deal:
I was auth'ing as the replication user on the slave, so the slave thought that it was getting updates from the master. Therefore, it wasn't adding its own structuralObjectClass attributes, thinking that it would get them explicitly from me (supposedly, the master LDAP server). After making a different user to log in as, and making the ACL give me permission to write, I've got it rocking and rolling.
I was auth'ing as the replication user on the slave, so the slave thought that it was getting updates from the master. Therefore, it wasn't adding its own structuralObjectClass attributes, thinking that it would get them explicitly from me (supposedly, the master LDAP server). After making a different user to log in as, and making the ACL give me permission to write, I've got it rocking and rolling.
well done, someone here to grade guitaristx?
;-)
;-)
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.