openldap-bugs August 2007

openldap-bugs@openldap.org

42 participants
211 discussions

Re: Contribution: Active Directory Password Cache (ITS#5042)
by ando＠sys-net.it 06 Aug '07

06 Aug '07

Sebastian, Thanks for the contribution. I have a few comments (also gathered from others): 1) you should provide patches against HEAD code; there has been some limited changes in the API related to overlay initialization and so. 2) you could try to rework the overlay to avoid any specific reference to Active Directory, since your cache should apply to any remote system implementing Kerberos V. It could be abstracted even more, to act as a replacement of saslauthd, by allowing it to auth via LDAP, pam and more, not just Kerberos. 3) you should add a (configurable) TTL, so that the cache could eventually be notified of an account lockout at the remote server's side. 4) you should add support for dynamic configuration, so that the module can fit into the new configuration paradigm for possible release with 2.4. 5) you should follow coding guidelines (indentation and so) as in most of the code. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5073) Syncrepl spinlock
by quanah＠zimbra.com 06 Aug '07

06 Aug '07

--On August 6, 2007 5:01:08 PM +0000 quanah(a)zimbra.com wrote: > > > --On August 6, 2007 9:17:01 AM +0000 ando(a)sys-net.it wrote: > >> quanah(a)OpenLDAP.org wrote: >>> Full_Name: Quanah Gibson-Mount >>> Version: 2.3.37 >>> OS: Linux >>> URL: >>> Submission from: (NULL) (71.202.148.128) >>> >>> >>> If you create a syncrepl master that serves the "" base, and then set up >>> a syncrepl consumer to pull down "dc=example,dc=com", which does *not* >>> exist on the master, the replica will sit at 100% CPU, endlessly trying >>> to add nothing. >> >> I'm not observing this with either re23 nor HEAD. The initial search >> correctly fails with noSuchObject, and then both slapds sit at 0% CPU. >> Can you give further details? > > I'll look at reproducing it again. > > In this particular case, the master had a database rooted at "", with > some data around "cn=zimbra" contained in it. A replica was configured > as a syncrepl client, but with "dc=example,dc=com" as its base, by > mistake. This resulted in the CPU usage shooting to 100% on the replica, > and the logs showing it trying to add without success. Okay, I figured it out -- This is definitely a misconfiguration type scenario... The database is something like: database bdb base "dc=example,dc=com" ... Then the syncrepl config has: searchbase="" I'm not sure this is something that should be allowed -- where the search base is broader than the database. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5073) Syncrepl spinlock
by quanah＠zimbra.com 06 Aug '07

06 Aug '07

--On August 6, 2007 9:17:01 AM +0000 ando(a)sys-net.it wrote: > quanah(a)OpenLDAP.org wrote: >> Full_Name: Quanah Gibson-Mount >> Version: 2.3.37 >> OS: Linux >> URL: >> Submission from: (NULL) (71.202.148.128) >> >> >> If you create a syncrepl master that serves the "" base, and then set up >> a syncrepl consumer to pull down "dc=example,dc=com", which does *not* >> exist on the master, the replica will sit at 100% CPU, endlessly trying >> to add nothing. > > I'm not observing this with either re23 nor HEAD. The initial search > correctly fails with noSuchObject, and then both slapds sit at 0% CPU. > Can you give further details? I'll look at reproducing it again. In this particular case, the master had a database rooted at "", with some data around "cn=zimbra" contained in it. A replica was configured as a syncrepl client, but with "dc=example,dc=com" as its base, by mistake. This resulted in the CPU usage shooting to 100% on the replica, and the logs showing it trying to add without success. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5076) Spell checking man pages
by ghenry＠OpenLDAP.org 06 Aug '07

06 Aug '07

Full_Name: Gavin Henry Version: HEAD adn RE_23 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (80.229.93.1) Submitted by: ghenry Dear all, Just creating a ticket for CHANGES, as I'm running: aspell --lang=en_US -c on all our manpages in HEAD and RE_23. Will query if I haev any concerns. Gavin.

1 0

Re: ITS#5075
by ando＠sys-net.it 06 Aug '07

06 Aug '07

ando(a)sys-net.it wrote: > fixed in HEAD; please test. also fixed in re23; please test. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

ITS#5075
by ando＠sys-net.it 06 Aug '07

06 Aug '07

fixed in HEAD; please test. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

(ITS#5075) openldap is not compilable with newest glibc and -D_FORTIFY_SOURCE=2
by jsafranek＠redhat.com 06 Aug '07

06 Aug '07

Full_Name: Jan Safranek Version: 2.3.37 OS: Linux (Fedora rawhide) URL: http://people.redhat.com/jsafrane/openldap-2.3.37-fortify-open.patch Submission from: (NULL) (62.40.79.66) Recently we have integrated glibc 2.6.90 into Fedora Linux distribution and OpenLDAP is not compilable anymore. We use -D_FORTIFY_SOURCE=2 to check for common errors on compile time and this switch causes that open() in fcntl.h is not a function name but a macro in the new glibc headers. Berkeley DB often uses 'something->open(...)' to open database, which is expanded by the compiler using the macro from fcntl.h -> compilation error. Compilation can be easily fixed by using additional braces around open, like '(something->open)(...)'. I do not like open() being macro, but POSIX allows it and glibc guys seems to be quite strict in this. The new glibc shall be released in fall and all major distributions will use it sooner or later, therefore I would suggest to adapt few OpenLDAP sources to it.

1 0

Re: (ITS#5074) slapo-pcache's proxyattrset does not recognize "1.1" to describe an empty attribute set
by ando＠sys-net.it 06 Aug '07

06 Aug '07

zep-openldap-software(a)ni.enate.org wrote: > For an application which specifies LDAP_NO_ATTRS to the attributes parameter of > ldap_search_st(), it seems not possible to cache its results using > slapo-pcache. > > It would be great to be able to define within "overlay pcache", something like: > > proxyattrset 0 (1.1) > > or, simply > > proxyattrset 0 > > Which would match queries which provide LDAP_NO_ATTRS. This would allow the > ability to cache responses for routines which are interested only in the > presence of a result set, but not in the contents of that set, without the > additional overhead of trasnferring the result. I believe there's something odd in pcache's current behavior. In fact, right now "proxyattrset 0" is already a valid directive, but it implies "proxyattrset 0 *", which means all attributes. Unfortunately, this seems to only work if no attribute is requested, while it fails if a "*" is explicitly requested. I've modified the propxycache code in HEAD so that a "1.1" can only explicitly appear in a list if it's the only string. An empty attribute set is no longer valid, to avoid confusion about the meaning of non-explicit attribute sets. A "*" or a "+" can explicitly appear in a proxyattrset statement, resulting in the expected behavior. Use both to indicate that all attributes are in the set. Please test. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5073) Syncrepl spinlock
by ando＠sys-net.it 06 Aug '07

06 Aug '07

quanah(a)OpenLDAP.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.3.37 > OS: Linux > URL: > Submission from: (NULL) (71.202.148.128) > > > If you create a syncrepl master that serves the "" base, and then set up a > syncrepl consumer to pull down "dc=example,dc=com", which does *not* exist on > the master, the replica will sit at 100% CPU, endlessly trying to add nothing. I'm not observing this with either re23 nor HEAD. The initial search correctly fails with noSuchObject, and then both slapds sit at 0% CPU. Can you give further details? p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

(ITS#5074) slapo-pcache's proxyattrset does not recognize "1.1" to describe an empty attribute set
by zep-openldap-software＠ni.enate.org 04 Aug '07

04 Aug '07

Full_Name: Mike Malsman Version: 2.3.33 OS: FreeBSD 6 URL: Submission from: (NULL) (65.12.196.28) For an application which specifies LDAP_NO_ATTRS to the attributes parameter of ldap_search_st(), it seems not possible to cache its results using slapo-pcache. It would be great to be able to define within "overlay pcache", something like: proxyattrset 0 (1.1) or, simply proxyattrset 0 Which would match queries which provide LDAP_NO_ATTRS. This would allow the ability to cache responses for routines which are interested only in the presence of a result set, but not in the contents of that set, without the additional overhead of trasnferring the result.

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs August 2007