[Date Prev][Date Next] [Chronological] [Thread] [Top]

RE: Re: Replica:can't insert entry from slave server



Hello all,
Through the website of OpenLDAP, the admin document introduce the Sample replication scenario:

1. The LDAP client submits an LDAP modify operation to the slave slapd.
2. The slave slapd returns a referral to the LDAP client referring the client to the master slapd.
3. The LDAP client submits the LDAP modify operation to the master slapd.
4. The master slapd performs the modify operation, writes out the change to its replication log file and returns a success code to the client.
5. The slurpd process notices that a new entry has been appended to the replication log file, reads the replication log entry, and sends the change to the slave slapd via LDAP.
6. The slave slapd performs the modify operation and returns a success code to the slurpd process.

After I followed the instructions, I can only succeed in adding entries from master with the successful replication to the slave, but failed when I submit an LDAP add operation to the slave slapd with the rootdn of master server. It seems that something about the referrals is wrong. 

Could You give me some advice?

Best regards

Richard Mou 
mou_tao@cvicse.com 
+86 531 2963478-6575

>From: John Beamon <jbeamon@franklinamerican.com>
>To: openldap-software@OpenLDAP.org
>Subject: Re: Replica:can't insert entry from slave server
>Date: Tue, 13 May 2003 08:42:21 -0500
>
>
>richard mou wrote:
> > I got problems:
> > This is a LAN, ldap master server "master", ldap replica slave server
> > "slave".
> > The slapd.conf on master(192.168.12.132) is:
> > database        ldbm
> > suffix          "dc=mt,dc=com"
> > rootdn          "cn=beijing,dc=mt,dc=com"
> > rootpw          secret
> > access to * by dn.base="cn=Slave,dc=mt,dc=com" write
> >         by  dn.base="cn=beijing,dc=mt,dc=com" write
> >         by  dn.base="cn=shanghai,dc=mt,dc=com" write
> >        by * read
> > directory       /etc/openldap/ldap
> > replica host=192.168.12.134:389
> >         bindmethod=simple credentials=secret
> >         binddn="cn=Slave,dc=mt,dc=com"
> >
> > The slapd.conf on slave(192.168.12.132) is:
> > database        ldbm
> > suffix          "dc=mt,dc=com"
> > rootdn          "cn=shanghai,dc=mt,dc=com"
> > rootpw          secret
> > access to * by dn.base="cn=Slave,dc=mt,dc=com" write
> >         by  dn.base="cn=beijing,dc=mt,dc=com" write
> >         by  dn.base="cn=shanghai,dc=mt,dc=com" write
> >         by * read
> > updatedn        "cn=Slave,dc=mt,dc=com"
> > updateref       192.168.12.132:389
> >
> > I have added the users with objectClass "top" and "person":
> > shanghai,beijing, slave
> >
> > Now, the replica from master to slave is good, but the replica from
> > slave to master is not running:
> > ldapadd -D "cn=shanghai,dc=mt,dc=com" -x -w secret -f person.ldif
> > adding new entry "cn=sh02,dc=mt,dc=com"
> > ldapadd: update failed: cn=sh02,dc=mt,dc=com
> > ldap_add: Referral (10)
> >         referrals:
> >                 192.168.12.132:389
> >
> > I got the same error when binding "cn=beijing,dc=mt, dc=com".
> > While, I can succeed when binding "cn=slave, dc=mt,dc=com", but the
> > entry is only inserted into the slave server, not able to be inserted
> > into the master.
> >
> > What is wrong?
> > Anyone can help me?
>
>I just worked through this myself.  New to LDAP, newer to the list.
>
>When you bind to the slave as the updatedn, the slave mistakes you for a
>replication request from the server, as if the server's already been
>updated.  That's why it updates the slave without populating back up.
>
>As for replication from the slave up, this is my experience.  I've read
>that this feature doesn't work yet in the openldap-2.x series.  I've
>read that the ldap client softwares in that distribution do not follow
>referrals, and that has been my practical experience as well.  At this
>time, I have updates to the master replicating out to slaves through TLS
>sessions, but I cannot update by talking to a slave.
>
>Your mileage may vary.  Experts with other experience are welcome to
>chime in and enlighten us both.
>
>John Beamon
>