[Date Prev][Date Next]
Re: LDAP master+slave - strange behavour
On Tue, 2004-09-14 at 15:19, Alexei Monastyrnyi wrote:
> My slave server allows modify/delete of LDAP entries via
> ldapmodify/ldapdelete utilities, and sends strange error message when
> trying to use ldapadd.
> alien:alexeim> ldapadd -c -h ldap2.orcsoftware.com -D
> "cn=manager,dc=orcsoftware,dc=com" -W -f /tmp/cat35
> Enter LDAP Password:
> adding new entry "cn=cat3548,ou=Hosts,dc=orcsoftware,dc=com"
> ldap_add: Internal (implementation specific) error (80)
> additional info: no structuralObjectClass operational attribute
> I want to say that it does not try to use referral as it should. So
> master server becomes unaware of what slave does.
you are binding as cn=manager presumably this is your rootdn and
therefore can write all over your slave directory. bind as a different
object to do your work and you should get proper referrals. This is one
reason why slurpd should bind as a replication agent and not as the
rootdn. think of rootdn as a root account - dont su to root and then
complain because the file you just clobbered was supposed to be write
> The slave server does accept add/mod/del operation from the master. That
> is OK.
that shows that your replication setup is working
> The servers have almost equal configs, except master/slave parts. Both
> of them use the same schema files.
> Master server ldap.orcsoftware.com has
> replica host=ldap2.orcsoftware.com:389 bindmethod=simple
> binddn="cn=Manager,dc=orcsoftware,dc=com" credentials=<mamager_passwd>
not good (but it will work)
> replogfile /usr/local/var/openldap-slurp/replication.log
> Slave server ldap2.orcsoftware.com has
> updatedn "cn=Manager,dc=orcsoftware,dc=com
> updateref ldap://ldap.orcsoftware.com
> cachesize 2000
> Maybe someone will point out where I'm wrong?
iTSS Wallingford 01491 692445