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

Re: openldap problem with synchronization



Am Fri, 3 Jan 2014 11:20:27 +0100
schrieb Robert Mach <mach.robert@gmail.com>:

> Unfortunately I can't do an update as this is production environment.
> 
> What is weird is that if I preform ldapsearch from the external to the
> internal server (Provider) with exact same properties and are
> configured in syncrepl configuration I see the updated data
> correctly, therefore the problem is not writing access rights or
> something like that. And the data is correctly updated when Consumer
> is started after the database of the Consumer is deleted.

There are numerous bugs in 2.3 syncrepl. At least you should try to
setup delta synchronisation and refreshAndPersist operation.
http://www.openldap.org/doc/admin24/replication.html#Delta-syncrep

-Dieter


> 
> On Fri, Jan 3, 2014 at 9:34 AM, Dieter KlÃnter <dieter@dkluenter.de>
> wrote:
> 
> > Am Fri, 3 Jan 2014 08:56:27 +0100
> > schrieb Robert Mach <mach.robert@gmail.com>:
> >
> > >        Hello,
> > > I have troubles using openldap replication in Centos 6.4. and
> > > Centos 5.3 I have two server with following version of openldap
> > > from centos repository configures as multimaster replication
> > > (internal servers):
> > >
> > > openldap-servers-2.4.23-32.el6_4.1.x86_64
> > > openldap-clients-2.4.23-32.el6_4.1.x86_64
> > > openldap-2.4.23-32.el6_4.1.x86_64
> > >
> > > Then I have one external server with following products:
> > > openldap-servers-2.3.43-12.el5_5.3
> > > openldap-clients-2.3.43-12.el5_5.3
> > > openldap-2.3.43-12.el5_5.3
> > >
> > > Then two internal servers are configured as multi-master
> > > replication and everything is working fine. The external server
> > > is configures as slave replication from one of those internal
> > > servers using the following configuration:
> > >
> > > CODE: SELECT ALL
> > > database        bdb
> > > suffix          "o=test,c=cz"
> > > rootdn          "cn=Manager,o=test,c=cz"
> > > directory       /var/local/ldap/test.cz
> > >
> > > index entryCSN,entryUUID                eq
> > > index objectClass                       eq,pres
> > > index ou,cn,mail                        eq,pres,sub
> > >
> > > syncrepl rid=132
> > >   provider=ldaps://xxxxx.xxx.xxx
> > >   type=refreshOnly
> > >   interval=00:00:01:00
> > >   searchbase="o=test,c=cz"
> > >   filter="(!(objectclass=simpleSecurityObject))"
> > >   scope=sub
> > >   updatedn="cn=SyncMaster,o=test,c=cz"
> > >   bindmethod=sasl
> > >   saslmech=external
> > >
> > >
> > attrs="objectClass,cn,sn,ou,o,mail,serialNumber,userCertificate,cACertificate,certificateRevocationList,authorityRevocationList,entrustPolicyCertificate,crossCertificatePair"
> > >   schemachecking=on
> > >
> > >
> > > There is a problem with replication from internal server to
> > > external. If I delete the database of external server and start
> > > the consumer, everything is correctly replicated from the
> > > provider (internal server) to the consumer. Therefore I assume,
> > > that the replication is configured correctly. But if the servers
> > > are running for a while and changes are made on the Provider
> > > (internal server) some data are not replicated to the consumer.
> > > More precisely the contextCSN of the root of the tree of consumer
> > > (external server) is updated and is  the same as on the
> > > Provider(internal server), but some entries lower in the three
> > > are not replicated correctly, both the entry entryCSN and the
> > > entry data itself are not updated on the Consumer.
> > >
> > > Do you have any idea where could be the problem?
> >
> > Just update to 2.4.38 and read the CHANGES file.
> >
> > -Dieter
> >
> > --
> > Dieter KlÃnter | Systemberatung
> > http://dkluenter.de
> > GPG Key ID:DA147B05
> > 53Â37'09,95"N
> > 10Â08'02,42"E
> >
> >



-- 
Dieter KlÃnter | Systemberatung
http://dkluenter.de
GPG Key ID:DA147B05
53Â37'09,95"N
10Â08'02,42"E