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?
Thank you,
Rob
Hi,
it's depends on interval=00:00:01:00 time.
On Fri, Jan 3, 2014 at 1:26 PM, Robert Mach mach.robert@gmail.com wrote:
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?
Thank you,
Rob
Hello,
yes you are right, the Consumer checks every minute the provider, but only the contextCSN on the Consumer is updated, not the actual data in the tree.
I studied the logs on the Provider more in detail.... as the Provider is providing data for the 2nd internal server (in multi-master replication) as well as for the external server. After a change in the Provider's tree both Consumer connect within one minute, the internal server sees the change whereas the external server doesn't:
Jan 3 09:17:04 ldapip slapd[20499]: conn=269275 op=1 SRCH base="o=test,c=cz" scope=2 deref=0 filter="(!(objectClass=simpleSecurityObject))" Jan 3 09:17:04 ldapip slapd[20499]: conn=269275 op=1 SRCH attr=cn sn ou o mail serialNumber userCertificate cACertificate certificateRevocationList authorityRevocationList entrustPolicyCertificate crossCertificatePair objectClass structuralObjectClass entryCSN Jan 3 09:17:04 ldapip slapd[20499]: conn=269275 op=1 SEARCH RESULT tag=101 err=0 *nentries=0* text=
versus
Jan 3 09:17:08 ldapip slapd[20499]: conn=269276 op=2 SRCH base="o=test,c=cz" scope=2 deref=0 filter="(objectClass=*)" Jan 3 09:17:08 ldapip slapd[20499]: conn=269276 op=2 SRCH attr=* + Jan 3 09:17:08 ldapip slapd[20499]: conn=269276 op=2 SEARCH RESULT tag=101 err=0 *nentries=28* text=
Robert
On Fri, Jan 3, 2014 at 9:17 AM, Vikas Parashar para.vikas@gmail.com wrote:
Hi,
it's depends on interval=00:00:01:00 time.
On Fri, Jan 3, 2014 at 1:26 PM, Robert Mach mach.robert@gmail.com wrote:
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?
Thank you,
Rob
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
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.
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
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
--On Friday, January 03, 2014 11:20 AM +0100 Robert Mach mach.robert@gmail.com wrote:
Unfortunately I can't do an update as this is production environment.
If you insist on using the utterly broken and outdated packages from RHEL, then you need to seek support from them.
If you want a working production OpenLDAP system and are unable to compile OpenLDAP yourself, then I would advise either using the packages from Symas (http://www.symas.com) or the LTB project (http://ltb-project.org/wiki/download#openldap).
No one here will be able to help you resolve the fact that what RHEL ships is fundamentally broken.
I also suggest reading the OpenLDAP change log:
http://www.openldap.org/software/release/changes.html
--Quanah
--
Quanah Gibson-Mount Architect - Server Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
Quanah Gibson-Mount quanah@zimbra.com schrieb am 03.01.2014 um 17:16 in
Nachricht <66A60B29B058A2AC7D60FBE1@[192.168.1.2]>:
--On Friday, January 03, 2014 11:20 AM +0100 Robert Mach mach.robert@gmail.com wrote:
Unfortunately I can't do an update as this is production environment.
If you insist on using the utterly broken and outdated packages from RHEL, then you need to seek support from them.
Maybe once people are convinced that the current version actually has less bugs than the previous versions, people may have a stronger tendency towards newer versions. MHO.
If you want a working production OpenLDAP system and are unable to compile OpenLDAP yourself, then I would advise either using the packages from Symas (http://www.symas.com) or the LTB project (http://ltb-project.org/wiki/download#openldap).
No one here will be able to help you resolve the fact that what RHEL ships is fundamentally broken.
I also suggest reading the OpenLDAP change log:
http://www.openldap.org/software/release/changes.html
--Quanah
--
Quanah Gibson-Mount Architect - Server Zimbra, Inc.
Zimbra :: the leader in open source messaging and collaboration
Ulrich Windl wrote:
Quanah Gibson-Mount quanah@zimbra.com schrieb am 03.01.2014 um 17:16 in
Nachricht <66A60B29B058A2AC7D60FBE1@[192.168.1.2]>:
--On Friday, January 03, 2014 11:20 AM +0100 Robert Mach mach.robert@gmail.com wrote:
Unfortunately I can't do an update as this is production environment.
If you insist on using the utterly broken and outdated packages from RHEL, then you need to seek support from them.
Maybe once people are convinced that the current version actually has less bugs than the previous versions, people may have a stronger tendency towards newer versions. MHO.
Ulrich, what exactly are you pointing at?
Everyone who is running a OpenLDAP server should keep an eye of file CHANGES in source distribution.
Personally I reported some really nasty bugs which were fixed in more recent releases.
Ciao, Michael.
openldap-technical@openldap.org
-
Dieter Klünter -
Michael Ströder -
Quanah Gibson-Mount -
Robert Mach -
Ulrich Windl -
Vikas Parashar