openldap-bugs

openldap-bugs@openldap.org

1 participants
21001 discussions

Re: (ITS#8125) MMR throws away valid changes causing drift
by quanah＠zimbra.com 15 May '15

15 May '15

--On Friday, May 15, 2015 8:39 PM +0100 Howard Chu <hyc(a)symas.com> wrote: > quanah(a)zimbra.com wrote: >> This is caused by modify ops: >> >> [zimbra@ldap02-dc01 xx]$ grep $20$ /var/log/zimbra.log >> May 15 08:35:46 ldap02-dc01 slapd[18167]: syncrepl_message_to_op: rid=201 >> be_modify uid=xxx,ou=people,dc=xxx,dc=com (20) > > Multiple TYPE_OR_VALUE_EXISTS errors indicate you're sending a lot of > mods that were already performed. Sounds more like a serverID or URL > misconfig here if there are actually only 2 servers talking. ServerID's are unique (2 & 3). There is no URL portion to the config, as we're not replicating cn=config. In 6 days, the servers have gotten totally out of sync with one another, and REFRESH mode isn't fixing it either. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#8125) MMR throws away valid changes causing drift
by hyc＠symas.com 15 May '15

15 May '15

quanah(a)zimbra.com wrote: > This is caused by modify ops: > > [zimbra@ldap02-dc01 xx]$ grep $20$ /var/log/zimbra.log > May 15 08:35:46 ldap02-dc01 slapd[18167]: syncrepl_message_to_op: rid=201 > be_modify uid=xxx,ou=people,dc=xxx,dc=com (20) Multiple TYPE_OR_VALUE_EXISTS errors indicate you're sending a lot of mods that were already performed. Sounds more like a serverID or URL misconfig here if there are actually only 2 servers talking. > May 15 08:47:44 ldap02-dc01 slapd[18167]: syncrepl_message_to_op: rid=201 > be_modify uid=xxx,ou=people,dc=yyy,dc=co,dc=za (20) > May 15 08:56:03 ldap02-dc01 slapd[18167]: syncrepl_message_to_op: rid=201 > be_modify uid=xxx,ou=people,dc=zzz,dc=co,dc=za (20) > May 15 09:31:12 ldap02-dc01 slapd[18167]: syncrepl_message_to_op: rid=201 > be_modify uid=xxx,ou=people,dc=www,dc=co,dc=za (20) > May 15 10:46:58 ldap02-dc01 slapd[18167]: syncrepl_message_to_op: rid=201 > be_modify uid=xxx,ou=people,dc=ppp,dc=co,dc=za (20) > May 15 13:44:11 ldap02-dc01 slapd[18167]: syncrepl_message_to_op: rid=201 > be_modify uid=xxx,ou=people,dc=rrr,dc=co,dc=za (20) > May 15 14:54:49 ldap02-dc01 slapd[18167]: syncrepl_message_to_op: rid=201 > be_modify uid=xxx,ou=people,dc=zzz,dc=com (20) > May 15 17:23:11 ldap02-dc01 slapd[18167]: syncrepl_message_to_op: rid=201 > be_modify uid=xxx,ou=people,dc=zzz,dc=com (20) > > So overall, there seems to be significant problems with RE24 in relation to > replication at this time. > > Clocks are tightly in sync. > > --Quanah > > -- > > Quanah Gibson-Mount > Platform Architect > Zimbra, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration > > > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#8125) MMR throws away valid changes causing drift
by quanah＠zimbra.com 15 May '15

15 May '15

--On Friday, May 15, 2015 7:25 PM +0000 quanah(a)zimbra.com wrote: > Clocks are tightly in sync. Seeing tons of "greater than snapshot errors". 108 so far today on one host, 144 on the other. Example of one: May 15 17:33:19 ldap01-dc01 slapd[31479]: Entry uid=xxxx,ou=people,dc=yyyy,dc=co,dc=za CSN 20150515153317.592677Z#000000#002#000000 greater than snapshot 20150515153317.320608Z#000000#002#000000 --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#8125) MMR throws away valid changes causing drift
by quanah＠zimbra.com 15 May '15

15 May '15

--On Monday, May 11, 2015 7:32 PM +0000 quanah(a)zimbra.com wrote: > --On Friday, May 08, 2015 7:56 PM +0000 quanah(a)zimbra.com wrote: > >> >> >> --On May 4, 2015 at 8:00:45 PM +0000 openldap-its(a)OpenLDAP.org wrote: >> >> >> In addition to the missing entries, multiple differences exist for >> existing entries as well. At this point, it seems that replication with >> 2.4.41 is entirely unsafe. > > The existing entry drift seems to be related to the locked up replication > that occured because of a bug in openssl. So the real issue is just the > entries that weren't created, which is a current known limitation of > syncrepl refresh that needs fixing. Unfortunately, I'm now seeing this at a second customer site with 2-node MMR, where it is running current RE24 (2.4.41). In this case: ldap01 and ldap02 were stopped openldap was upgraded from 2.4.39 to 2.4.41 ldap01's db was slapcat'd ldap02's db was erased ldap02's db was recreated from ldap01's slapcat Now they are having drift, and constant refresh troubles: [zimbra@ldap01-dc01 ~]$ grep REFRESH /var/log/zimbra.log May 15 08:56:02 ldap01-dc01 slapd[31479]: do_syncrep2: rid=201 delta-sync lost sync on (reqStart=20150515065528.000299Z,cn=accesslog), switching to REFRESH May 15 08:58:07 ldap01-dc01 slapd[31479]: do_syncrep2: rid=201 LDAP_RES_INTERMEDIATE - REFRESH_DELETE May 15 09:57:18 ldap01-dc01 slapd[31479]: do_syncrep2: rid=201 delta-sync lost sync on (reqStart=20150515075718.000081Z,cn=accesslog), switching to REFRESH May 15 10:46:57 ldap01-dc01 slapd[31479]: do_syncrep2: rid=201 delta-sync lost sync on (reqStart=20150515084653.000032Z,cn=accesslog), switching to REFRESH May 15 12:43:18 ldap01-dc01 slapd[31479]: do_syncrep2: rid=201 delta-sync lost sync on (reqStart=20150515104318.000049Z,cn=accesslog), switching to REFRESH May 15 16:32:19 ldap01-dc01 slapd[31479]: do_syncrep2: rid=201 delta-sync lost sync on (reqStart=20150515143211.000250Z,cn=accesslog), switching to REFRESH May 15 16:36:41 ldap01-dc01 slapd[31479]: do_syncrep2: rid=201 delta-sync lost sync on (reqStart=20150515143556.000046Z,cn=accesslog), switching to REFRESH May 15 17:23:10 ldap01-dc01 slapd[31479]: do_syncrep2: rid=201 delta-sync lost sync on (reqStart=20150515152310.000002Z,cn=accesslog), switching to REFRESH [zimbra@ldap02-dc01 xx]$ grep FRESH /var/log/zimbra.log May 15 08:35:46 ldap02-dc01 slapd[18167]: do_syncrep2: rid=201 delta-sync lost sync on (reqStart=20150515063539.000009Z,cn=accesslog), switching to REFRESH May 15 08:47:44 ldap02-dc01 slapd[18167]: do_syncrep2: rid=201 delta-sync lost sync on (reqStart=20150515064733.000043Z,cn=accesslog), switching to REFRESH May 15 08:56:03 ldap02-dc01 slapd[18167]: do_syncrep2: rid=201 delta-sync lost sync on (reqStart=20150515065528.000234Z,cn=accesslog), switching to REFRESH May 15 08:57:24 ldap02-dc01 slapd[18167]: do_syncrep2: rid=201 LDAP_RES_INTERMEDIATE - REFRESH_DELETE May 15 09:31:12 ldap02-dc01 slapd[18167]: do_syncrep2: rid=201 delta-sync lost sync on (reqStart=20150515073112.000086Z,cn=accesslog), switching to REFRESH May 15 10:46:58 ldap02-dc01 slapd[18167]: do_syncrep2: rid=201 delta-sync lost sync on (reqStart=20150515084653.000003Z,cn=accesslog), switching to REFRESH May 15 13:44:11 ldap02-dc01 slapd[18167]: do_syncrep2: rid=201 delta-sync lost sync on (reqStart=20150515114405.000313Z,cn=accesslog), switching to REFRESH May 15 14:54:49 ldap02-dc01 slapd[18167]: do_syncrep2: rid=201 delta-sync lost sync on (reqStart=20150515125448.000002Z,cn=accesslog), switching to REFRESH May 15 17:23:11 ldap02-dc01 slapd[18167]: do_syncrep2: rid=201 delta-sync lost sync on (reqStart=20150515152311.000035Z,cn=accesslog), switching to REFRESH This is caused by modify ops: [zimbra@ldap02-dc01 xx]$ grep $20$ /var/log/zimbra.log May 15 08:35:46 ldap02-dc01 slapd[18167]: syncrepl_message_to_op: rid=201 be_modify uid=xxx,ou=people,dc=xxx,dc=com (20) May 15 08:47:44 ldap02-dc01 slapd[18167]: syncrepl_message_to_op: rid=201 be_modify uid=xxx,ou=people,dc=yyy,dc=co,dc=za (20) May 15 08:56:03 ldap02-dc01 slapd[18167]: syncrepl_message_to_op: rid=201 be_modify uid=xxx,ou=people,dc=zzz,dc=co,dc=za (20) May 15 09:31:12 ldap02-dc01 slapd[18167]: syncrepl_message_to_op: rid=201 be_modify uid=xxx,ou=people,dc=www,dc=co,dc=za (20) May 15 10:46:58 ldap02-dc01 slapd[18167]: syncrepl_message_to_op: rid=201 be_modify uid=xxx,ou=people,dc=ppp,dc=co,dc=za (20) May 15 13:44:11 ldap02-dc01 slapd[18167]: syncrepl_message_to_op: rid=201 be_modify uid=xxx,ou=people,dc=rrr,dc=co,dc=za (20) May 15 14:54:49 ldap02-dc01 slapd[18167]: syncrepl_message_to_op: rid=201 be_modify uid=xxx,ou=people,dc=zzz,dc=com (20) May 15 17:23:11 ldap02-dc01 slapd[18167]: syncrepl_message_to_op: rid=201 be_modify uid=xxx,ou=people,dc=zzz,dc=com (20) So overall, there seems to be significant problems with RE24 in relation to replication at this time. Clocks are tightly in sync. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#8145) The olcThreadQueues config element is not documented
by quanah＠zimbra.com 15 May '15

15 May '15

--On Friday, May 15, 2015 12:50 PM +0000 elecharny(a)gmail.com wrote: > You migth object that the reference is what's in the man page, but then, > how possibly can we detect missing parts in the documentation?" You're either using a Symas or Zimbra openldap build to test against, both of which backport 2.5 features not generally available in stock OpenLDAP 2.4. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#8145) The olcThreadQueues config element is not documented
by hyc＠symas.com 15 May '15

15 May '15

Emmanuel Lécharny wrote: > Le 15/05/15 13:40, Howard Chu a écrit : >> elecharny(a)apache.org wrote: >>> Full_Name: Emmanuel L.charny >>> Version: 2.4.40 >>> OS: >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (83.202.0.248) >>> >>> >>> The olcThreadQueues AttributeType is part of the olcGlobal >>> OvjectClass since >>> 2.4.36, where it's has been added. >>> A man slapd-config provides no information on this parameter. >> >> You're mistaken. The olcThreadQueues feature has not been included in >> any official 2.4 release, it is a 2.5 feature. >> > Sadly, I can't comment on an ITS. So here it is : > > "It may not be official, but it's present in the code base since 2.4.36, > it's also present as a MAY attribute in the olcGlobal ObjectClass. No. You misunderstand - it is *NOT* present in the 2.4 source tree. It has *never* been present in the 2.4 source tree. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#8145) The olcThreadQueues config element is not documented
by elecharny＠gmail.com 15 May '15

15 May '15

Le 15/05/15 13:40, Howard Chu a écrit : > elecharny(a)apache.org wrote: >> Full_Name: Emmanuel L.charny >> Version: 2.4.40 >> OS: >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (83.202.0.248) >> >> >> The olcThreadQueues AttributeType is part of the olcGlobal >> OvjectClass since >> 2.4.36, where it's has been added. >> A man slapd-config provides no information on this parameter. > > You're mistaken. The olcThreadQueues feature has not been included in > any official 2.4 release, it is a 2.5 feature. > Sadly, I can't comment on an ITS. So here it is : "It may not be official, but it's present in the code base since 2.4.36, it's also present as a MAY attribute in the olcGlobal ObjectClass. There is no way for me to know that it's a 2.5 feature, if it's in 2.4 branch, and if it's not documented as so. This is not really convenient, as I'm basing the OpenLDAP configuration editor on the content of the existing ObjectClasses. You migth object that the reference is what's in the man page, but then, how possibly can we detect missing parts in the documentation?"

1 0

Re: (ITS#8145) The olcThreadQueues config element is not documented
by hyc＠symas.com 15 May '15

15 May '15

elecharny(a)apache.org wrote: > Full_Name: Emmanuel L.charny > Version: 2.4.40 > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (83.202.0.248) > > > The olcThreadQueues AttributeType is part of the olcGlobal OvjectClass since > 2.4.36, where it's has been added. > A man slapd-config provides no information on this parameter. You're mistaken. The olcThreadQueues feature has not been included in any official 2.4 release, it is a 2.5 feature. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#8145) The olcThreadQueues config element is not documented
by elecharny＠apache.org 15 May '15

15 May '15

Full_Name: Emmanuel L.charny Version: 2.4.40 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (83.202.0.248) The olcThreadQueues AttributeType is part of the olcGlobal OvjectClass since 2.4.36, where it's has been added. A man slapd-config provides no information on this parameter.

1 0

Re: (ITS#8140) ssf is hard coded to log as zero, even if it is non-zero
by quanah＠zimbra.com 15 May '15

15 May '15

--On Tuesday, May 12, 2015 7:58 PM +0000 quanah(a)zimbra.com wrote: > --On Tuesday, May 12, 2015 1:18 PM +0000 hyc(a)symas.com wrote: > >> Works as designed. The Bind op itself didn't provide any security, so it >> contributed 0 to the session's ssf. The preceding StartTLS request >> actually established a security layer, and it correctly logs the ssf >> from that. > > I think overall the design is problematic. "ssf" is generally supposed to > indicate the overall security of the connection, regardless of the step. > Perhaps for 2.5 and later, we could modify the logging line to be > something more like: > > May 11 02:28:06 ldap01 slapd[33839]: conn=153266 op=1 BIND > dn="uid=zimbra,cn=admins,cn=zimbra" mech=SIMPLE bind_ssf=0 ssf=256 > > > So that the overall SSF of the connection is reflected, and we're > indicating that specifically the BIND op added nothing to SSF. > > This would be useful for ldapi:/// connections as well, as there are zero > ssf indicators logged at all outside of the bind op: > > May 12 02:30:19 ldap01 slapd[33839]: conn=169357 fd=85 ACCEPT from > PATH=/opt/zimbra/data/ldap/state/run/ldapi > (PATH=/opt/zimbra/data/ldap/state/run/ldapi) > May 12 02:30:19 ldap01 slapd[33839]: conn=169357 op=0 BIND > dn="uid=zimbra,cn=admins,cn=zimbra" method=128 > May 12 02:30:19 ldap01 slapd[33839]: conn=169357 op=0 BIND > dn="uid=zimbra,cn=admins,cn=zimbra" mech=SIMPLE ssf=0 > May 12 02:30:19 ldap01 slapd[33839]: conn=169357 op=0 RESULT tag=97 err=0 > text= > > > Even though I have: > > olcLocalSSF: 128 > > in my config DB > > I.e., I think it would be better to show: > > May 12 02:30:19 ldap01 slapd[33839]: conn=169357 op=0 BIND > dn="uid=zimbra,cn=admins,cn=zimbra" mech=SIMPLE bind_ssf=0 ssf=128 > > in this case. Per Howard: we should update the SASL Bind log to use bind_ssf= as well --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs