openldap-bugs September 2012

openldap-bugs@openldap.org

29 participants
107 discussions

Re: (ITS#7246) Addition of FedFS schema LDIF
by chuck.lever＠oracle.com 27 Sep '12

27 Sep '12

It appears that the schema LDIF files shipped with OpenLDAP are strictly for basic LDAP attribute type and object class definitions. Everything else is considered a "user schema," including schemas for implementing a DNS or NIS backend, and so on. It appears to me that FedFS would fall into this latter category, and thus should not be included in the packaged schema. Comments?

1 0

Re: (ITS#7385) back_mdb ENOSPC error returned from mdb_node_add incorrectly
by hyc＠symas.com 27 Sep '12

27 Sep '12

marco(a)schirrmeister.net wrote: > On Sep 18, 2012, at 1:59 PM, hyc(a)symas.com wrote: > >> Marco Schirrmeister wrote: >>> I pulled latest RE24 on Sep 15th and now I get this. >>> >>> ... >>> indexing id=00010d0e >>> indexing id=00010d0f >>> 5056de89 => mdb_tool_entry_reindex: txn_commit failed: Unknown error 18446744073709520830 (-30786) >> >> That was fixed yesterday in commit 8bb10add2465eee34e79abeaa62011e3e234effb. >> Please pull RE24 again today and try again, it should all be working fine. > > Just tested with latest RE24 > > indexing id=00010d0e > indexing id=00010d0f > 50587b72 => mdb_tool_entry_reindex: txn_commit failed: MDB_PAGE_FULL: Internal error - page has no more space (-30786) Thanks for your help, this is now fixed in master. -- -- 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#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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs September 2012