openldap-bugs

openldap-bugs@openldap.org

1 participants
20959 discussions

Re: (ITS#6160) slapadd man page doesn't note indexing
by quanah＠zimbra.com 05 Jun '09

05 Jun '09

--On Friday, June 05, 2009 9:25 PM +0100 Gavin Henry <gavin.henry(a)gmail.com> wrote: > Is there a SEE ALSO? > > Will check and amend. Regardless of SEE ALSO, it should note that it indexes the database while adding it. ;) SEE ALSO ldap(3), ldif(5), slapcat(8), ldapadd(1), slapd(8) Should probably have slapindex in the SEE ALSO as well. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6160) slapadd man page doesn't note indexing
by gavin.henry＠gmail.com 05 Jun '09

05 Jun '09

Is there a SEE ALSO? Will check and amend. On 05/06/2009, quanah(a)openldap.org <quanah(a)openldap.org> wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.16 > OS: NA > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.29.239) > > > The man page for slapadd does not note that it also performs indexing while > adding the database. While this is fairly obvious to those of us > experienced > with using OpenLDAP, it is non-obvious to new users. > > > -- Sent from my mobile device http://www.suretecsystems.com/services/openldap/ http://www.suretectelecom.com

1 0

(ITS#6160) slapadd man page doesn't note indexing
by quanah＠OpenLDAP.org 05 Jun '09

05 Jun '09

Full_Name: Quanah Gibson-Mount Version: 2.4.16 OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) The man page for slapadd does not note that it also performs indexing while adding the database. While this is fairly obvious to those of us experienced with using OpenLDAP, it is non-obvious to new users.

1 0

Re: (ITS#6157) unAbandonable operations aren't.
by h.b.furuseth＠usit.uio.no 04 Jun '09

04 Jun '09

Caught cancel(cancel) and cancel/abandon(abandon/bind/unbind), partly fixed cancel(cn=config update) problem, without doing this: > Suggested partual fix - add this possible value for o_cancel: > #define SLAP_CANCEL_INVALID 0x04 /* like 0 but prevents Cancel */ Still need something that to fix cancel(cn=config update) completely. syncrepl/syncprov, starttls not yet addressed. Also cancel(cancel) still behaves in a non-RFC way. Correct fix would require resetting o_abandon, which seems unsafe. Who knows what has already reacted to it. Will update this patch for the remaining issues later: > Something like this: > http://folk.uio.no/hbf/OpenLDAP/cancel-cancel.txt -- Hallvard

1 0

Re: (ITS#6056) Samba4 breaks OpenLDAP over ldapi
by hyc＠symas.com 04 Jun '09

04 Jun '09

Howard Chu wrote: > Andrew Bartlett wrote: >> I agree, we might be jumping at different shadows here, but your patches >> did fix something... > > I see what you're describing now, with the kvm set with 2 CPUs. It appears to > be a bug caused by the recent patch for connection_hangup() processing. > Running slapd with -d15 in your test shows that a connection is closed shortly > after being established and becoming readable. The bug is (probably) that we > queued the reader but processed the hangup immediately, thus closing the > connection before the reader executes. I'm not exactly sure why this is > causing the problem on your test, since it looks like your client is closing > the socket before waiting for the reply. But certainly this is the right area. > With the connection problem out of the way, the remaining slapd crash appeared to be due to some type of heap corruption, but the usual suite of tools (valgrind, efence, LBER_MEMORY_DEBUG, etc.) didn't ever reproduce the problem. On the assumption that this was related to a stack overwrite I recompiled libldap_r with a 12MB stack size instead of the default 8MB and that still didn't change the outcome. On the assumption that there was some other race condition involved, I set slapd to only 2 threads (from default of 16) to try and limit the possibilities there. This caused the crash to occur much more quickly, and using libumem it became obvious that refint was accessing already-freed memory. So it turns out that the patch for rev 1.41 (ITS#5428) to make this into a global overlay was incorrect; it moved the loop that processed its work queue into a new function so that it could be called multiple times, but it was still using that code basically as-is, which freed its queue as it operated. (Because originally the queue was only walked once.) Part of the reason the bug was so hard to reproduce is because it tended to only show up when the queue got fairly long, and that only happened if slapd was too busy. (Thus, forcing only 2 threads made it occur sooner.) -- -- 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#6152) proxycache enhancements
by mhardin＠symas.com 04 Jun '09

04 Jun '09

On Jun 4, 2009, at 9:15 AM, masarati(a)aero.polimi.it wrote: > Just in case, before it becomes totally incompatible with HEAD code, I > have a patch I never committed, it's about making pcache admin- > friendly if > it makes any sense. > > It adds: > > - a (persistent) counter that reports, for each query, how many > times it > evaluated to answerable That's very useful. Any thoughts about how to determine pcache's overall 'hit rate'? > > > - "proxycache-" prefixed statements are passed to the private > database. > This allows to avoid ambiguities when applying general database > directives > in slapd.conf. In fact, it is not clear whether they apply to the > proxy > database or to the cache database. Also useful. > > > If they make sense, I'd like to commit them before slapo-pcache > enhancement begins. I agree. > > > p. > > > -Matt

1 0

Re: (ITS#6152) proxycache enhancements
by masarati＠aero.polimi.it 04 Jun '09

04 Jun '09

Just in case, before it becomes totally incompatible with HEAD code, I have a patch I never committed, it's about making pcache admin-friendly if it makes any sense. It adds: - a (persistent) counter that reports, for each query, how many times it evaluated to answerable - "proxycache-" prefixed statements are passed to the private database. This allows to avoid ambiguities when applying general database directives in slapd.conf. In fact, it is not clear whether they apply to the proxy database or to the cache database. If they make sense, I'd like to commit them before slapo-pcache enhancement begins. p.

1 0

Re: (ITS#6152) proxycache enhancements
by mhardin＠symas.com 03 Jun '09

03 Jun '09

On a related note, any solution using pcache for disconnected operation should also be able to cache bind operations. This is a digest of a conversation I had with Howard about that: Currently pcache always forwards binds to the db beneath it. These will fail in disconnected cases. One solution is to give the pcache identity read privs to the userpassword, but for security and design reasons that won't fly in most installations. Another solution is to add bind caching to pcache, and that is what is described below. Bind caching functionality can be integrated with pcache, provided that we can meet some conditions: 1. Guarantee that the object being bound against is already in pcache when it passes the bind through. 2. Have an attribute in the cached object where pcache can store a hashed version (e.g. SSHA) of the password it got from the user and verified against the underlying database. Remember that we must verify it against the underlying db before we can write it to cache. Most applications performing LDAP authentication will first search for the object to which they're intending to bind. This will cause condition (1) to be satisfied, but this is not good enough because it is not guaranteed that all applications will first search for the object to which they're binding- some applications build the bind DN 'blindly' using string substitution rules or even hard-coded bind DNs. This is wrong, but it's the way things are. Therefore, pcache itself should search for the object being being bound to and populate the cache with the search result. The details of how the object is added to the cache remain to be determined. Satisfying (1) provides the opportunity to construct an proxyattrset that includes a (possibly dummy) attribute in which the hashed validated password can be stored, thus satisfying condition (2). The userPassword attribute can probably be used most of the time for this, since it will either be returned form the server either empty or with a value of '*'. The "do bind caching directive" might refer to a proxyattrset constructed for this purpose. Bind caching will interact with TTR, but the details are as yet undetermined. To round out the solution, we should also process pwdModify exops as follows: For pwdModify exops, pcache would could operate as a 'write-through' cache, first making sure the object in the cache is current. If the write-through to the underlying database succeeds, then the object in the cache is also updated. Otherwise the exop fails and any cached copy is left unaltered. -Matt Matthew Hardin Symas Corporation - The LDAP Guys http://www.symas.com

1 0

Re: (ITS#6158) syncprov: assert causing slapd to core dump
by quanah＠zimbra.com 03 Jun '09

03 Jun '09

--On Wednesday, June 03, 2009 7:22 AM +0000 jonathan(a)phillipoux.net wrote: > Will this patch make it into RE23 for a possible maintenance release of > 2.3? There will be no further releases of OpenLDAP 2.3. You should at this point be working on migrating to the OpenLDAP 2.4 release. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6157) unAbandonable operations aren't.
by h.b.furuseth＠usit.uio.no 03 Jun '09

03 Jun '09

Suggested partual fix - add this possible value for o_cancel: #define SLAP_CANCEL_INVALID 0x04 /* like 0 but prevents Cancel */ Something like this: http://folk.uio.no/hbf/OpenLDAP/cancel-cancel.txt Does not reject abandon(Cancel/StartTLS), would need to extend o_cancel with yet another value. That's ugly enough already, so I let that wait. connection_abandon() in particular isn't invalid client action, but it shouldn't be worse than causing a surprising result code or not response before closing the connection. Does not address syncprov's Cancel handler. I don't know if the bconfig.c pathces are correct, but need to reject cancel before (reacting to) thread pool pauses there and maybe in syncrepl/syncprov. -- Hallvard

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