openldap-bugs

openldap-bugs@openldap.org

1 participants
20962 discussions

Re: (ITS#7405) Improve refint documentation
by hyc＠symas.com 27 Sep '12

27 Sep '12

quanah(a)OpenLDAP.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.32 > OS: NA > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (74.196.25.250) > > > As per debian bug#688857: > > Modifications made by refint are not replicated. They neither update the > modification timestamp nor the CSN used for replication. This is serious > data loss, because the replicas gets out of sync pretty quickly. There > seems to be no way to recover from this discrepancy without doing a > complete replication. > > While this seems to be known, it is not documented at all in the > man-pages related to the refint and memberof overlays. Also it violates > the principle of least surprise, because the changes are not limited to > operational attributes. slapo-refint(5) manpage updated in master. slapo-memberof(5) was updated in 2.4.26 (ITS#6915) so at least that part of the bug report is invalid. -- -- 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#7405) Improve refint documentation
by quanah＠OpenLDAP.org 26 Sep '12

26 Sep '12

Full_Name: Quanah Gibson-Mount Version: 2.4.32 OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (74.196.25.250) As per debian bug#688857: Modifications made by refint are not replicated. They neither update the modification timestamp nor the CSN used for replication. This is serious data loss, because the replicas gets out of sync pretty quickly. There seems to be no way to recover from this discrepancy without doing a complete replication. While this seems to be known, it is not documented at all in the man-pages related to the refint and memberof overlays. Also it violates the principle of least surprise, because the changes are not limited to operational attributes.

1 0

Re: (ITS#7404) back-ldap connection cache error
by hyc＠symas.com 26 Sep '12

26 Sep '12

hyc(a)OpenLDAP.org wrote: > Full_Name: Howard Chu > Version: RE24/master > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (37.19.96.255) > Submitted by: hyc > > > back-ldap resets the local DN of a connection after a Bind request, even if the > Bind failed. Subsequent operations for that DN will reuse this connection, even > though it hasn't bound successfully. This is clearly wrong. Hm, false alarm. back-ldap is correct here. Something else is lying about its identity... -- -- 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#7404) back-ldap connection cache error
by hyc＠OpenLDAP.org 26 Sep '12

26 Sep '12

Full_Name: Howard Chu Version: RE24/master OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (37.19.96.255) Submitted by: hyc back-ldap resets the local DN of a connection after a Bind request, even if the Bind failed. Subsequent operations for that DN will reuse this connection, even though it hasn't bound successfully. This is clearly wrong.

1 0

(ITS#7403) back-ldap idassert always overrides
by hyc＠OpenLDAP.org 26 Sep '12

26 Sep '12

Full_Name: Howard Chu Version: RE24/master OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (37.19.96.255) Submitted by: hyc If an idassert-bind directive has been configured, idassert processing is always performed, even if a direct bind has occurred. In effect, back-ldap always behaves as if flags=override was set in the idassert configuration. This is not the documented or intended behavior. A fix is coming shortly.

1 0

RE: (ITS#7401) OpenLDAP 2.4.32 - deadlock issues
by quanah＠zimbra.com 25 Sep '12

25 Sep '12

--On Tuesday, September 25, 2012 4:22 PM +0000 vb4607(a)att.com wrote: > Thank you so much for the quick reply. We are a bit hesitant to try > 4.7.25 as it is a 4 year old product. What about version 5.1 (5.1.29) as > it is mentioned on your Web site > (http://www.openldap.org/software/release/readme.html)? I've been using BDB 4.7.25 (+all patches) for several years, and it has been quite stable. No deadlocks. This version is used on all Zimbra deployments across the world, with plenty of customers having millions of entry DBs. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

RE: (ITS#7401) OpenLDAP 2.4.32 - deadlock issues
by vb4607＠att.com 25 Sep '12

25 Sep '12

Thank you so much for the quick reply. We are a bit hesitant to try 4.7.25 as it is a 4 year old product. What about version 5.1 (5.1.29) as it is mentioned on your Web site (http://www.openldap.org/software/release/readme.html)? Sincerely, Venkatesh -----Original Message----- From: Howard Chu [mailto:hyc@symas.com] Sent: Tuesday, September 25, 2012 11:19 AM To: BAGLODI, VENKATESH Cc: openldap-its(a)openldap.org Subject: Re: (ITS#7401) OpenLDAP 2.4.32 - deadlock issues vb4607(a)att.com wrote: > Full_Name: Venkatesh Baglodi > Version: 2.4.32 > OS: Red Hat Enterprise Linux Server release 5.5 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (144.160.226.53) > > > We have been facing occasional deadlock issues when using OpenLDAP in > multi-master mode (4 servers). It looks like deadlocks are occuring on > objectClass index (eq). We have been using OpenLDAP 2.4.32 with hdb backend > (BerkelyDB v5.3.21) on Red Hat Enterprise Linux Server release 5.5 (Tikanga). We > tried to upload the DB stat reports on ftp.openldap.org/incoming/, but looks > like the server is out of disk space. Some of the traces are provided below: Your traces look much the same as ITS#7378. However, as noted in followup#4 to that report, there's no code path in back-bdb/hdb that can legitimately cause this situation. Can you switch to BDB 4.7.25 and still reproduce the problem? -- -- 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#7402)
by agarcia＠tempel.es 25 Sep '12

25 Sep '12

This is a multi-part message in MIME format. --------------080808010700020804030601 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit And sldapd change the shema from: attributetype ( 2.5.4.6 NAME ( 'c' 'countryName' ) DESC 'RFC2256: ISO-3166 country 2-letter code' SUP name SINGLE-VALUE ) to : # RFC 4519 definition ('countryName' in X.500 and RFC2256) attributetype ( 2.5.4.6 NAME ( 'c' 'countryName' ) DESC 'RFC4519: two-letter ISO-3166 country code' SUP name SYNTAX 1.3.6.1.4.1.1466.115.121.1.11 SINGLE-VALUE ) Thanks a lot for your quick reply, c=Net is not really Country (just a TLD) but I used it in previous slapd version a worked well! Thanks --------------080808010700020804030601 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit <html> <head> <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> </head> <body bgcolor="#FFFFFF" text="#000000"> And sldapd change the shema from: <blockquote>attributetype ( 2.5.4.6 NAME ( 'c' 'countryName' )         DESC 'RFC2256: ISO-3166 country 2-letter code'         SUP name SINGLE-VALUE ) </blockquote> to : <blockquote># RFC 4519 definition ('countryName' in X.500 and RFC2256) attributetype ( 2.5.4.6 NAME ( 'c' 'countryName' )         DESC 'RFC4519: two-letter ISO-3166 country code'         SUP name         SYNTAX 1.3.6.1.4.1.1466.115.121.1.11         SINGLE-VALUE ) </blockquote> Thanks a lot for your quick reply, c=Net is not really Country (just a TLD) but I used it in previous slapd version a worked well! Thanks </body> </html> --------------080808010700020804030601--

1 0

Re: (ITS#7402) Invalid DN 21
by Pierangelo Masarati 25 Sep '12

25 Sep '12

> I've configured my DB suffix at /etc/openldap/slapd.conf > >> suffix "o=Iddover, c=Net" > > But slapd doesn't like the dn, if I've used "cn=Iddover, cn=Net" slapd start > normally. "Net" is invalid per "c" syntax. The ITS is intended for software bugs; please direct usage error questions to openldap-technical. This ITS will be closed. p.

1 0

Re: (ITS#7401) OpenLDAP 2.4.32 - deadlock issues
by hyc＠symas.com 25 Sep '12

25 Sep '12

vb4607(a)att.com wrote: > Full_Name: Venkatesh Baglodi > Version: 2.4.32 > OS: Red Hat Enterprise Linux Server release 5.5 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (144.160.226.53) > > > We have been facing occasional deadlock issues when using OpenLDAP in > multi-master mode (4 servers). It looks like deadlocks are occuring on > objectClass index (eq). We have been using OpenLDAP 2.4.32 with hdb backend > (BerkelyDB v5.3.21) on Red Hat Enterprise Linux Server release 5.5 (Tikanga). We > tried to upload the DB stat reports on ftp.openldap.org/incoming/, but looks > like the server is out of disk space. Some of the traces are provided below: Your traces look much the same as ITS#7378. However, as noted in followup#4 to that report, there's no code path in back-bdb/hdb that can legitimately cause this situation. Can you switch to BDB 4.7.25 and still reproduce the problem? -- -- 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

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