--On Friday, March 14, 2014 2:07 PM +0100 Marc Haber mh+openldap-technical@zugschlus.de wrote:
On Thu, Mar 13, 2014 at 11:03:22AM -0700, Quanah Gibson-Mount wrote:
Known issue with 2.4.31. Solution is to upgrade and stop using the crap shipped by Debian.
Please watch your language: it was the OpenLDAP project that released this "crap" a while ago.
Debian makes very specific decisions to:
a) Not update what they ship to address known issues (The debian openldap package list is littered with bug reports with pointers to the upstream ITSes)
b) Link to a TLS implementation that is known to be utterly flawed (https://symas.com/software-design-and-trustworthiness/)
So don't try and lecture me about the decisions made by Debian. What they ship is crap, and what they ship could be fixed to not be crap. End of story.
--Quanah
--
Quanah Gibson-Mount Architect - Server Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
--On Friday, March 14, 2014 2:07 PM +0100 Marc Haber mh+openldap-technical@zugschlus.de wrote:
On Thu, Mar 13, 2014 at 11:03:22AM -0700, Quanah Gibson-Mount wrote:
Known issue with 2.4.31. Solution is to upgrade and stop using the crap shipped by Debian.
Please watch your language: it was the OpenLDAP project that released this "crap" a while ago.
Debian makes very specific decisions to:
a) Not update what they ship to address known issues (The debian openldap package list is littered with bug reports with pointers to the upstream ITSes)
b) Link to a TLS implementation that is known to be utterly flawed (https://symas.com/software-design-and-trustworthiness/)
So don't try and lecture me about the decisions made by Debian. What they ship is crap, and what they ship could be fixed to not be crap. End of story.
--Quanah
--
Quanah Gibson-Mount Architect - Server Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
-- This message has been scanned for viruses and dangerous content, and is believed to be clean. Message id: 08B276014D5.A01BA
The date on the CSN is tomorrow's date. This was taken from the log shortly before 10 PM CST.
do_syncrep2: rid=005 CSN too old, ignoring 20140318025932.803264Z#000000#002#000000
So how can the CSN be too old?
Thanks, Eric
This communication and any attachments are confidential, protected by Communications Privacy Act 18 USCS � 2510, solely for the use of the intended recipient, and may contain legally privileged material. If you are not the intended recipient, please return or destroy it immediately. Thank you.
--On March 17, 2014 at 10:02:33 PM -0500 espeake@oreillyauto.com wrote:
The date on the CSN is tomorrow's date. This was taken from the log shortly before 10 PM CST.
do_syncrep2: rid=005 CSN too old, ignoring 20140318025932.803264Z#000000#002#000000
So how can the CSN be too old?
Well, since the CSN is based off timezone "Z" (http://www.timeanddate.com/library/abbreviations/timezones/military/z.html) that should give you some idea. I imagine you can figure it out from there. I also assume you keep your systems clocks tightly sync'd, as that is a documented requirement for syncreplication.
--Quanah
Yes all of our servers are sync'd very tightly. In going through all of our user data and diff'ing it out. I see in most instances the information is current on two of three servers when there is a discrepancy. So I have correct data on the servers and back to my original question, is there a way to make the nodes go through compare and update the data? How can I force a manual sync between the nodes?
Thanks, Eric Speake Web Systems Administrator O'Reilly Auto Parts (417) 862-2674 Ext. 1975
From: Quanah Gibson-Mount quanah@zimbra.com To: espeake@oreillyauto.com Cc: openldap-technical@openldap.org Date: 03/17/2014 10:40 PM Subject: Re: Question on replication files. Sent by: openldap-technical-bounces@OpenLDAP.org
--On March 17, 2014 at 10:02:33 PM -0500 espeake@oreillyauto.com wrote:
The date on the CSN is tomorrow's date. This was taken from the log shortly before 10 PM CST.
do_syncrep2: rid=005 CSN too old, ignoring 20140318025932.803264Z#000000#002#000000
So how can the CSN be too old?
Well, since the CSN is based off timezone "Z" (< http://www.timeanddate.com/library/abbreviations/timezones/military/z.html
)
that should give you some idea. I imagine you can figure it out from there. I also assume you keep your systems clocks tightly sync'd, as that is a documented requirement for syncreplication.
--Quanah
-- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
-- This message has been scanned for viruses and dangerous content, and is believed to be clean. Message id: 0A81160141D.AC6CA
This communication and any attachments are confidential, protected by Communications Privacy Act 18 USCS � 2510, solely for the use of the intended recipient, and may contain legally privileged material. If you are not the intended recipient, please return or destroy it immediately. Thank you.
--On Tuesday, March 18, 2014 8:32 AM -0500 espeake@oreillyauto.com wrote:
Yes all of our servers are sync'd very tightly. In going through all of our user data and diff'ing it out. I see in most instances the information is current on two of three servers when there is a discrepancy. So I have correct data on the servers and back to my original question, is there a way to make the nodes go through compare and update the data? How can I force a manual sync between the nodes?
man slapd. It discusses the options on how to start the process and forcing it to re-sync the DB.
--Quanah
--
Quanah Gibson-Mount Architect - Server Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
Hi!
I guess once you identified the entries out of sync, do a dummy change with ldapmodify the doesn't change a value (i.e. replace an attribute's value with the current value) on a master server. Then watch whether the other servers get updated... If that doesn't work, hunt for the bug...
Regards, Ulrich
espeake@oreillyauto.com schrieb am 18.03.2014 um 13:32 in Nachricht
OFFF997815.9C450A54-ON86257C9F.00448AFA-86257C9F.0044D5F1@LocalDomain:
Yes all of our servers are sync'd very tightly. In going through all of our user data and diff'ing it out. I see in most instances the information is current on two of three servers when there is a discrepancy. So I have correct data on the servers and back to my original question, is there a way to make the nodes go through compare and update the data? How can I force a manual sync between the nodes?
Thanks, Eric Speake Web Systems Administrator O'Reilly Auto Parts (417) 862-2674 Ext. 1975
From: Quanah Gibson-Mount quanah@zimbra.com To: espeake@oreillyauto.com Cc: openldap-technical@openldap.org Date: 03/17/2014 10:40 PM Subject: Re: Question on replication files. Sent by: openldap-technical-bounces@OpenLDAP.org
--On March 17, 2014 at 10:02:33 PM -0500 espeake@oreillyauto.com wrote:
The date on the CSN is tomorrow's date. This was taken from the log shortly before 10 PM CST.
do_syncrep2: rid=005 CSN too old, ignoring 20140318025932.803264Z#000000#002#000000
So how can the CSN be too old?
Well, since the CSN is based off timezone "Z" (< http://www.timeanddate.com/library/abbreviations/timezones/military/z.html
)
that should give you some idea. I imagine you can figure it out from there. I also assume you keep your systems clocks tightly sync'd, as that is a documented requirement for syncreplication.
--Quanah
-- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc
Zimbra :: the leader in open source messaging and collaboration
-- This message has been scanned for viruses and dangerous content, and is believed to be clean. Message id: 0A81160141D.AC6CA
This communication and any attachments are confidential, protected by Communications Privacy Act 18 USCS § 2510, solely for the use of the
intended
recipient, and may contain legally privileged material. If you are not the intended recipient, please return or destroy it immediately. Thank you.
openldap-technical@openldap.org
-
espeake＠oreillyauto.com -
Quanah Gibson-Mount -
Ulrich Windl