openldap-bugs

openldap-bugs@openldap.org

1 participants
20960 discussions

(ITS#5077) syncrepl.add_cmp() infinite loop on swapped values
by donn＠u.washington.edu 06 Aug '07

06 Aug '07

Full_Name: Donn Cave Version: 2.4.4 OS: Red Hat Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (128.95.135.150) In "while" loop at 2656, I find old->a_vals are like [..., a, b, ...] and new->a_vals are like [..., b, a, ...]. Matches are found at old [i] == new [k = j+1] and old [k = i+1] == new [j], but this just shows that neither an add nor a delete is called for, and the loop end is reached without having incremented i or j. Actual attribute values I'm looking at right now in the debugger are eduPersonAffiliation: old [ member, alum, employee, faculty ], new [ member, alum, faculty, employee ]. I built the replica from a slapcat dump on the idle master, started the slapd syncrepl client and applied a lot of normal modifications to the master, until it hit the infinite loop. It has been a recurrent problem.

1 0

Re: Contribution: Active Directory Password Cache (ITS#5042)
by kurt＠OpenLDAP.org 06 Aug '07

06 Aug '07

On Aug 6, 2007, at 7:31 PM, ando(a)sys-net.it wrote: > 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. s/to act as a replacement/to defer external authentication to saslauthd or the like/ In slapd(8), we deferred verification against external password stores to saslauthd via the {SASL} userPassword mechanism, thus avoiding needing to implement and support each possible external password store (such as a KDC). This module should likewise avoid supporting (some subset of) external passwords stores. saslauthd(8) can easily be extended (or replaced) to support additional password stores as needed. As provided in Cyrus SASL today, it supports both LDAP and Kerberos as external password stores. > > 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.

1 0

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

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