openldap-bugs October 2010

openldap-bugs@openldap.org

38 participants
86 discussions

(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

(ITS#6685) VLV implementation and compatibility
by sebastien.bahloul＠gmail.com 25 Oct '10

25 Oct '10

Full_Name: Sebastien Bahloul Version: HEAD OS: Linux RHEL 5 URL: ftp://ftp.openldap.org/incoming/sbahloul-101026.patch Submission from: (NULL) (2a01:e35:2ebe:f470:222:fbff:fe34:f796) Hi, OpenLDAP VLV implementation seems not to be fully compliant with latest draft. Use case has been identify through JNDI - JDK 1.5, (whereas it seems to be functional in ldapsearch) : javax.naming.NamingException [Root exception is com.sun.jndi.ldap.Ber$DecodeException: Encountered ASN.1 tag 2 (expected tag 10)] After doing some network captures between different directories implementation, it seems that there is a BER encoding error on the VLV response error code : Global VLV control response ASN1 dump (through openssl asn1parse) : 0:d=0 hl=2 l= 50 cons: SEQUENCE 2:d=1 hl=2 l= 24 prim: OCTET STRING :2.16.840.1.113730.3.4.10 28:d=1 hl=2 l= 22 prim: OCTET STRING 0000 - 30 14 02 01 00 02 02 00-aa 02 01 00 04 08 10 0a 0............... 0010 - 82 15 .. 0016 - <SPACES/NULS> Included octet string VLV control response ASN1 dump : 0:d=0 hl=2 l= 20 cons: SEQUENCE 2:d=1 hl=2 l= 1 prim: INTEGER :00 5:d=1 hl=2 l= 2 prim: INTEGER :AA 9:d=1 hl=2 l= 1 prim: INTEGER :00 12:d=1 hl=2 l= 8 prim: OCTET STRING 0000 - 10 0a 82 15 .... 0008 - <SPACES/NULS> According to latest VLV draft (seems to be version 4) in section 5.2, return type for error code (last 00 in this dump) must be an enumerated type (tag type 10). In OpenLDAP response, error code is encoded as an integer (tag type 2). I suggest to fix this by changing ber_printf(..."{iii ... to ber_printf(..."{iie ... in sssvlv.c:198. Regards,

1 0

Re: (ITS#6684) Patch for autogroup overlay
by hyc＠symas.com 25 Oct '10

25 Oct '10

norbert(a)pueschel.net wrote: > Full_Name: Norbert Pueschel > Version: HEAD > OS: Solaris > URL: http://www.pueschel.net/openldap/norbert-pueschel-autogroup-25102010.tar > Submission from: (NULL) (80.152.154.98) > > > When starting to use the autogroup-overlay from the contrib directory, I > stumbled over some issues: > > 1) Using non-DN-valued URIs for autogroup does not work correctly, even > with the latest version from HEAD. Especially changing group member is > not tracked. > > 2) Using the memberOf-overlay for constructing autogroups does not work > > 3) autogroup crashes slaptools (e.g. slaptest) when used together with > the ppolicy-overlay. > > 4) The Makefile install the overlay into the wrong directory (lib, > should be libexec) > > I have invested some time and found fixes for all these problems; see > the URL for the patch I uploaded. > > Please read the contributing Guidelines http://www.openldap.org/devel/contributing.html and provide a suitable IPR notice. -- -- 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#6684) Patch for autogroup overlay
by norbert＠pueschel.net 25 Oct '10

25 Oct '10

Full_Name: Norbert Pueschel Version: HEAD OS: Solaris URL: http://www.pueschel.net/openldap/norbert-pueschel-autogroup-25102010.tar Submission from: (NULL) (80.152.154.98) When starting to use the autogroup-overlay from the contrib directory, I stumbled over some issues: 1) Using non-DN-valued URIs for autogroup does not work correctly, even with the latest version from HEAD. Especially changing group member is not tracked. 2) Using the memberOf-overlay for constructing autogroups does not work 3) autogroup crashes slaptools (e.g. slaptest) when used together with the ppolicy-overlay. 4) The Makefile install the overlay into the wrong directory (lib, should be libexec) I have invested some time and found fixes for all these problems; see the URL for the patch I uploaded.

1 0

(ITS#6683) DDS fails with expired branches
by petteri.stenius＠ubisecure.com 25 Oct '10

25 Oct '10

Full_Name: Version: 2.4.23 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (195.197.205.34) Hello, I have a directory with branches of dynamicObject entries. It looks like if the entryExpireTimestamp value is the same on objects within a branch then DDS search for expired objects will only find the top-most object. This results in remove failing with message DDS dn="cn=top,cn=root,dc=test" is non-leaf; deferring. To reproduce OpenLDAP 2.4.23, Berkeley DB 4.6.21 Use slapadd to prepare directory with following dn: cn=Root,dc=test objectClass: top objectClass: applicationProcess cn: Root dn: cn=top,cn=Root,dc=test objectClass: top objectClass: device objectClass: dynamicObject entryTTL: 60 entryExpireTimestamp: 20101024113626Z cn: top dn: cn=leaf1,cn=top,cn=Root,dc=test objectClass: top objectClass: device objectClass: dynamicObject entryTTL: 60 entryExpireTimestamp: 20101024113626Z cn: leaf1 dn: cn=leaf2,cn=top,cn=Root,dc=test objectClass: top objectClass: device objectClass: dynamicObject entryTTL: 60 entryExpireTimestamp: 20101024113626Z cn: leaf2 dn: cn=leaf3,cn=top,cn=Root,dc=test objectClass: top objectClass: device objectClass: dynamicObject entryTTL: 60 entryExpireTimestamp: 20101024113626Z cn: leaf3 Relevant slapd.conf entries database bdb suffix "cn=Root,dc=test" rootdn "cn=Root,dc=test" rootpw "password" overlay dds dds-default-ttl 3600 dds-min-ttl 60 dds-interval 60 dds-state true index entryExpireTimestamp eq,pres access to dn.subtree="cn=Root,dc=test" by users write by * read Running "slapd -d 1 -d 256" produces following put_filter: "(&(objectClass=dynamicObject)(entryExpireTimestamp<=20101025082446Z))" put_filter: AND put_filter_list "(objectClass=dynamicObject)(entryExpireTimestamp<=20101025082446Z)" put_filter: "(objectClass=dynamicObject)" put_filter: simple put_simple_filter: "objectClass=dynamicObject" put_filter: "(entryExpireTimestamp<=20101025082446Z)" put_filter: simple put_simple_filter: "entryExpireTimestamp<=20101025082446Z" ber_scanf fmt ({mm}) ber: ber_scanf fmt ({mm}) ber: => bdb_search bdb_dn2entry("cn=root,dc=test") => bdb_dn2id("cn=root,dc=test") <= bdb_dn2id: got id=0x1 entry_decode: "cn=Root,dc=test" <= entry_decode(cn=Root,dc=test) search_candidates: base="cn=root,dc=test" (0x00000001) scope=2 => bdb_dn2idl("cn=root,dc=test") => bdb_equality_candidates (objectClass) => key_read <= bdb_index_read: failed (-30989) <= bdb_equality_candidates: id=0, first=0, last=0 => bdb_equality_candidates (objectClass) => key_read <= bdb_index_read 4 candidates <= bdb_equality_candidates: id=4, first=2, last=5 => bdb_inequality_candidates (entryExpireTimestamp) => key_read <= bdb_index_read 1 candidates => key_read <= bdb_index_read: failed (-30989) <= bdb_inequality_candidates: id=1, first=2, last=2 bdb_search_candidates: id=1 first=2 last=2 entry_decode: "cn=top,cn=Root,dc=test" <= entry_decode(cn=top,cn=Root,dc=test) => bdb_dn2id("cn=top,cn=root,dc=test") <= bdb_dn2id: got id=0x2 send_ldap_result: conn=-1 op=0 p=0 bdb_dn2entry("cn=top,cn=root,dc=test") => bdb_dn2id_children("cn=top,cn=root,dc=test") <= bdb_dn2id_children("cn=top,cn=root,dc=test"): (0) send_ldap_result: conn=-1 op=0 p=0 DDS dn="cn=top,cn=root,dc=test" is non-leaf; deferring. DDS expired=0 ldapsearch "(entryExpireTimestamp=*)" produces dn: cn=top,cn=Root,dc=test entryExpireTimestamp: 20101024113626Z dn: cn=leaf1,cn=top,cn=Root,dc=test entryExpireTimestamp: 20101024113626Z dn: cn=leaf2,cn=top,cn=Root,dc=test entryExpireTimestamp: 20101024113626Z dn: cn=leaf3,cn=top,cn=Root,dc=test entryExpireTimestamp: 20101024113626Z where ldapsearch "(entryExpireTimestamp<=20101024113626Z)" only finds dn: cn=top,cn=Root,dc=test entryExpireTimestamp: 20101024113626Z If I change all timestamps to distinct values then expiration of complete branches works as expected. Thanks, Petteri

1 0

← Newer
1
2
3
4
5
6
7
8
9
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs October 2010