openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

Re: (ITS#6660) paged result searches fail to deallocate memory until slapd shutdown
by quanah＠zimbra.com 28 Oct '10

28 Oct '10

--On Wednesday, October 27, 2010 4:54 PM +0000 quanah(a)zimbra.com wrote: > > If anyone else has some thoughts on why the entry cache is growing > unbounded, much appreciated. Just a further note -- To reproduce this, you have to have more than 2 cores. My system has 6, I don't know what the lower limit is (3,4, or 5) for reproduction. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6687) slaptest: bad configuration file!
by quanah＠zimbra.com 28 Oct '10

28 Oct '10

--On Wednesday, October 27, 2010 3:22 PM +0000 rakesh.rai(a)alico.com wrote: If you need help using and configuring OpenLDAP, then email openldap-technical(a)openldap.org. The ITS system is not the appropriate place for these types of questions. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6688) OpenLDAP 2.4.23 doesn't enforce ACLs on back-perl subordinate database
by mark.cave-ayland＠siriusit.co.uk 28 Oct '10

28 Oct '10

Full_Name: Mark Cave-Ayland Version: 2.4.23 OS: Linux/Debian URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.187.123.11) Hi all, We have an issue on one of our production systems whereby openldap is not enforcing the ACLs on a back-perl subordinate database. In this particular system, the membership of certain groups stored within LDAP is determined by some customised logic in a Perl module which dynamically generates LDAP objects with posixGroup/groupOfNames entries conditionally based upon the values of existing LDAP attributes within the tree. However, since these internal LDAP attribute lookups can be quite slow, we wish to hide them from all but a small minority of bind DNs. Unfortunately what we are finding is that the back-perl module is not respecting the ACLs in slapd.conf. The following files can be used to reproduce this issue with openldap 2.4.23: http://pastebin.siriusit.co.uk/perlacl/slapd.conf http://pastebin.siriusit.co.uk/perlacl/perlacl.ldif http://pastebin.siriusit.co.uk/perlacl/PerlACL.pm The password for both the "cn=admin,dc=my-domain,dc=com" and the "cn=restricted,dc=my-domain,dc=com" DNs is secret. The ACLs in the above slapd.conf look like this: access to dn.subtree="ou=perl,dc=my-domain,dc=com" by dn="cn=admin,dc=my-domain,dc=com" read by dn="cn=restricted,dc=my-domain,dc=com" none access to dn.subtree="ou=hidden,dc=my-domain,dc=com" by dn="cn=admin,dc=my-domain,dc=com" read by dn="cn=restricted,dc=my-domain,dc=com" none access to * by dn="cn=admin,dc=my-domain,dc=com" write by dn="cn=restricted,dc=my-domain,dc=com" read by * auth Using these ACLs, I would expect that cn=admin should be able to read the whole directory, whereas cn=restricted should not be able to see either the "ou=hidden,dc=my-domain,dc=com" DN subtree nor the "ou=perl,dc=my-domain,dc=com" DN subtree. However, performing an LDAP search binding as cn=restricted gives the following output: build@zeno:~$ ldapsearch -LLL -H ldap://localhost:10389 -D 'cn=restricted,dc=my-domain,dc=com' -b 'dc=my-domain,dc=com' -xW Enter LDAP Password: dn: dc=my-domain,dc=com objectClass: top objectClass: dcObject objectClass: organization o:: bXlkb21haW4uY29tIA== dc: my-domain dn: ou=real,dc=my-domain,dc=com objectClass: organizationalUnit objectClass: top ou: real dn: ou=realtest1,ou=real,dc=my-domain,dc=com objectClass: organizationalUnit objectClass: top ou: realtest1 dn: ou=realtest2,ou=real,dc=my-domain,dc=com objectClass: organizationalUnit objectClass: top ou: realtest2 dn: ou=realtest3,ou=real,dc=my-domain,dc=com objectClass: organizationalUnit objectClass: top ou: realtest3 dn: ou=realtest4,ou=real,dc=my-domain,dc=com objectClass: organizationalUnit objectClass: top ou: realtest4 dn: ou=realtest5,ou=real,dc=my-domain,dc=com objectClass: organizationalUnit objectClass: top ou: realtest5 dn: cn=restricted,dc=my-domain,dc=com objectClass: simpleSecurityObject objectClass: organizationalRole cn: restricted description: restricted user userPassword:: e1NIQX01ZW42RzZNZXpScm9UM1hLcWtkUE9tWS9CZlE9 dn: cn=admin,dc=my-domain,dc=com objectClass: simpleSecurityObject objectClass: organizationalRole cn:: YWRtaW4g description: admin user userPassword:: e1NIQX01ZW42RzZNZXpScm9UM1hLcWtkUE9tWS9CZlE9 dn: ou=perltest5,ou=perl,dc=my-domain,dc=com objectClass: organizationalUnit objectClass: top ou: perltest5 dn: ou=perltest4,ou=perl,dc=my-domain,dc=com objectClass: organizationalUnit objectClass: top ou: perltest4 dn: ou=perltest3,ou=perl,dc=my-domain,dc=com objectClass: organizationalUnit objectClass: top ou: perltest3 dn: ou=perltest2,ou=perl,dc=my-domain,dc=com objectClass: organizationalUnit objectClass: top ou: perltest2 dn: ou=perltest1,ou=perl,dc=my-domain,dc=com objectClass: organizationalUnit objectClass: top ou: perltest1 In other words, the "ou=hidden,dc=my-domain,dc=com" subtree is correctly hidden from the cn=restricted user, whereas the "ou=perl,dc=my-domain,dc=com" subtree is not.

1 0

Re: (ITS#6660) paged result searches fail to deallocate memory until slapd shutdown
by quanah＠zimbra.com 27 Oct '10

27 Oct '10

--On Thursday, September 30, 2010 4:59 PM +0000 quanah(a)zimbra.com wrote: > --On Thursday, September 30, 2010 11:14 AM +0000 masarati(a)aero.polimi.it > wrote: > >> There's no mention of overlays; I was wondering whether or not it could >> be related to some adverse interaction, e.g. with sssvlv, which has some >> paged-results specific code. Can you also post on overlays either global >> or specific to "olcDatabase={2}hdb"? > > There are no overlays being used. ;) As I said, a very vanilla config. Howard and I continue to examine this problem, but as yet, have found no solution nor insight into why the problem exists. It has nothing to do with paged results, and you can see the behavior relatively easily with a smaller DB than I was working with. Right now, I'm using a 1 million entry DB. If I execute two concurrent searches of the database with a 25,000 entry cache limit, that frees 1,000 entries on purge, at the end of those searches, we end up with: counted 1000087 entryInfos and 114476 entries, 0 notcached What this shows is that after the search completed, there are 114,476 entries in the entry cache, even though it only reports between 24,000 and 25,000. Repeated additional searches will continue to increase the number of cached entries until all memory is exhausted. The following code is used to count up the cached entries, and it is called from inside gdb via: call bdb_lru_count(&bdb->bi_cache) --- openldap-2.4.23/servers/slapd/back-bdb/cache.c.orig 2010-10-05 16:20:27.085259568 -0700 +++ openldap-2.4.23/servers/slapd/back-bdb/cache.c 2010-10-05 16:21:03.655255057 -0700 @@ -1530,6 +1530,35 @@ } #ifdef LDAP_DEBUG +static void +bdb_lru_count( Cache *cache ) +{ + EntryInfo *e; + int ei = 0, ent = 0, nc = 0; + + for ( e = cache->c_lrutail; ; ) { + ei++; + if ( e->bei_e ) { + ent++; + if ( e->bei_state & CACHE_ENTRY_NOT_CACHED ) + nc++; + } + e = e->bei_lrunext; + if ( e == cache->c_lrutail ) + break; + } + fprintf( stderr, "counted %d entryInfos and %d entries, %d notcached\n", + ei, ent, nc ); + ei = 0; + for ( e = cache->c_lrutail; ; ) { + ei++; + e = e->bei_lruprev; + if ( e == cache->c_lrutail ) + break; + } + fprintf( stderr, "counted %d entryInfos (on lruprev)\n", ei ); +} + #ifdef SLAPD_UNUSED static void bdb_lru_print( Cache *cache ) If anyone else has some thoughts on why the entry cache is growing unbounded, much appreciated. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6684)
by norbert＠pueschel.net 27 Oct '10

27 Oct '10

Updated TAR-file with (hopefully) sufficient copyright notice... http://www.pueschel.net/openldap/norbert-pueschel-autogroup-27102010.tar

1 0

(ITS#6687) slaptest: bad configuration file!
by rakesh.rai＠alico.com 27 Oct '10

27 Oct '10

Full_Name: Rakesh Version: 2.4.23 OS: Microsoft windows XP 2002 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (167.230.38.120) When I try to test OpenLdap it gives me an error as shown below. Have setup SYSCONFDIR in path and still I get this issue. C:\OpenLDAP>slaptest could not stat config file "%SYSCONFDIR%\slapd.conf": No such file or directory (2) slaptest: bad configuration file!

1 0

Re: (ITS#6686) VLV overlay fails to handle multiple search operations per LDAP connection
by sebastien.bahloul＠gmail.com 27 Oct '10

27 Oct '10

Hi Howard, Le mercredi 27 octobre 2010 15:03:36, Howard Chu a =E9crit : > sebastien.bahloul(a)gmail.com wrote: > > Full_Name: Sebastien Bahloul > > Version: HEAD > > OS: Linux RHEL 5 > > URL: > > Submission from: (NULL) (109.197.176.10) > >=20 > >=20 > > Hi, > >=20 > > I think there is a bug / limitation inside VLV implementation : it can > > not handle multiple search operation on a single connection. The first > > operation succeeds and next operations fail with the following message : > >=20 > > LDAP: error code 51 - Other sort requests already in progress > >=20 > > But I think this issue is more global. This implementation seems to be > > able to only handle a single VLV context per connection. >=20 > Correct, that is by design. >=20 > > If I am right, this is related with the indexing method of sort_conns > > structure which seems to be based only on the connection id. I suggest > > to implement a double indexing array by connection id / VLV context id. >=20 > I have no interest in extending this. It would require much more overhead > to protect the slapd from getting overloaded by too many such requests. In fact my suggestion was a question : I would like to contribute a patch t= o=20 add support for this way of using VLV. Is this feature extension as a doubl= e=20 indexed array an acceptable implementation from your point of vue ? To avoi= d=20 encountering such performance issues, I would add a new sssvlv parameter th= at=20 would authorize by default only a single VLV search request per connection. Regards, =2D-=20 Sebastien Bahloul @: sebastien.bahloul(a)gmail.com

1 0

Re: (ITS#6686) VLV overlay fails to handle multiple search operations per LDAP connection
by hyc＠symas.com 27 Oct '10

27 Oct '10

sebastien.bahloul(a)gmail.com wrote: > Full_Name: Sebastien Bahloul > Version: HEAD > OS: Linux RHEL 5 > URL: > Submission from: (NULL) (109.197.176.10) > > > Hi, > > I think there is a bug / limitation inside VLV implementation : it can not > handle multiple search operation on a single connection. The first operation > succeeds and next operations fail with the following message : > > LDAP: error code 51 - Other sort requests already in progress > But I think this issue is more global. This implementation seems to be able to > only handle a single VLV context per connection. Correct, that is by design. > If I am right, this is related with the indexing method of sort_conns structure > which seems to be based only on the connection id. I suggest to implement a > double indexing array by connection id / VLV context id. I have no interest in extending this. It would require much more overhead to protect the slapd from getting overloaded by too many such requests. -- -- 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#6686) VLV overlay fails to handle multiple search operations per LDAP connection
by sebastien.bahloul＠gmail.com 27 Oct '10

27 Oct '10

Full_Name: Sebastien Bahloul Version: HEAD OS: Linux RHEL 5 URL: Submission from: (NULL) (109.197.176.10) Hi, I think there is a bug / limitation inside VLV implementation : it can not handle multiple search operation on a single connection. The first operation succeeds and next operations fail with the following message : LDAP: error code 51 - Other sort requests already in progress My first guess was to remove / comment the following condition in sssvlv.c:757 : vc->vc_context != so->so_vcontext But I think this issue is more global. This implementation seems to be able to only handle a single VLV context per connection. If I am right, this is related with the indexing method of sort_conns structure which seems to be based only on the connection id. I suggest to implement a double indexing array by connection id / VLV context id. Regards,

1 0

Re: (ITS#6619) CSN too old
by heinz.hoelzl＠gvcc.net 27 Oct '10

27 Oct '10

I testet it also whithout a back-ldap The problem exists also if the provider is a "normal" slapd with "database hdb"

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