openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

Re: (ITS#6696) back-sql and pagedResultsControl can be extremely heavy due to no LIMIT
by masarati＠aero.polimi.it 09 Nov '10

09 Nov '10

Andrew.Gray(a)unlv.edu wrote: > Full_Name: Andrew Gray > Version: 2.4.17 > OS: Debian 5.0 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (131.216.14.1) > > > On receiving LDAP queries with a pagedResultsControl (in this case with a size > of 250), back-sql generates an extremely inefficient query for every iteration > in the form of: > > SELECT DISTINCT ldap_entries.id,people.local_id,text('UNLVexpperson') AS > objectClass,ldap_entries.dn AS dn FROM ldap_entries,people,ldap_entry_objclasses > WHERE people.local_ > id=ldap_entries.keyval AND ldap_entries.oc_map_id=1 AND upper(ldap_entries.dn) > LIKE upper('%'||'%OU=PEOPLE,DC=UNLV,DC=EDU') AND ldap_entries.id>250 AND (2=2 OR > (ldap_entries.id=ldap_entry_objclasses.entry_id AND ldap_entry_objclasses.oc_ > name='UNLVexpperson')) > > (this repeats for id>250, id>500, id>750, etc. etc.) > > Ideally (IMO) there really should be a SQL LIMIT applied here, as in this case > slapd gets back a few tens of thousands of rows on every iteration, and the > memory usage explodes and eventually gets killed. Using back-sql on large databases along with pagedResult control is not advisable. Limiting the number of entries returned by each query is not viable as well, since some entries might not mathc the LDAP filter, or ACLs or so, possibly leading to less than pageSize entries returned within one page. PagedResults could be removed from back-sql, and dealt with by an overlay that simply pages results returned by back-sql in a single internal search; probably this is the preferable approach, since it would also result in a reduction of the complexity of back-sql. However, I have little interest in improving back-sql, so patches are welcome, as usual... p.

1 0

Re: (ITS#6697) Could OpenLdap automatically generate SSHA Hashed userPassword?
by masarati＠aero.polimi.it 09 Nov '10

09 Nov '10

changhong_sun(a)yahoo.cn wrote: > Full_Name: Chang Hong Sun > Version: 2.4.23 > OS: SuSe Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (220.248.0.145) > > > Hi All, > > I've installed OpenLdap 2.4.23 in SUSE Linux, and find that: > 1) The OpenLdap supports the SSHA Hash Algorithm by default: could import or > accept the creation of the Users with the {SSHA}/{SHA} Hashed userPassword. > 2) The OpenLdap provides a command "slappasswd" to generate the hashed password, > while it seems that it is not able to generate the password by the OpenLdap > server automatically: after I created a user without Hashed userPassword, I > checked the data and found that the password keep unchanged and hasn't been > Hashed. > > My question is: > Is it possible to make some configuration, so that the OpenLdap server could > automatically transfer the userPassword to Hashed format? Please direct software usage questions to openldap-technical(a)openldap.org; the ITS is intended to track software bugs. This ITS will be closed. p.

1 0

(ITS#6697) Could OpenLdap automatically generate SSHA Hashed userPassword?
by changhong_sun＠yahoo.cn 09 Nov '10

09 Nov '10

Full_Name: Chang Hong Sun Version: 2.4.23 OS: SuSe Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (220.248.0.145) Hi All, I've installed OpenLdap 2.4.23 in SUSE Linux, and find that: 1) The OpenLdap supports the SSHA Hash Algorithm by default: could import or accept the creation of the Users with the {SSHA}/{SHA} Hashed userPassword. 2) The OpenLdap provides a command "slappasswd" to generate the hashed password, while it seems that it is not able to generate the password by the OpenLdap server automatically: after I created a user without Hashed userPassword, I checked the data and found that the password keep unchanged and hasn't been Hashed. My question is: Is it possible to make some configuration, so that the OpenLdap server could automatically transfer the userPassword to Hashed format? Thanks and Best Regards, Sun Chang Hong

1 0

Re: (ITS#6683) DDS fails with expired branches
by hyc＠symas.com 09 Nov '10

09 Nov '10

Petteri.Stenius(a)ubisecure.com wrote: > Hello, > > Further investigation shows this issue is caused by operator LE search > failing with indexed attributes. Also this indexed search issue is NOT > limited to DDS.=20 > > I have reproduced the issue with integerOrderingMatch and > generalizedTimeOrderingMatch.=20 > > The piece of code I find suspicious is in servers/back-bdb/idl.c, > somewhere in the middle it reads > > /* skip presence key on range inequality lookups */ > while (rc =3D=3D 0&& kptr->size !=3D len) { > rc =3D cursor->c_get( cursor, kptr,&data, flags | > DB_NEXT_NODUP ); > } > > If I remove this block then LE search works as expected with indexed > attributes. The key here seems to be the DB_NEXT_NODUP flag. This flag > causes the iterator block a few lines below to return partial matches. That implies that there's something else corrupt in the index, because the presence key will never be the same size as an equality key. > > Thanks, > Petteri > > -----Original Message----- > From: openldap-bugs-bounces(a)OpenLDAP.org > [mailto:openldap-bugs-bounces@OpenLDAP.org] On Behalf Of > petteri.stenius(a)ubisecure.com > Sent: Monday, October 25, 2010 1:35 PM > To: openldap-its(a)openldap.org > Subject: (ITS#6683) DDS fails with expired branches > > Full_Name:=20 > 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=3D"cn=3Dtop,cn=3Droot,dc=3Dtest" is non-leaf; deferring. > > > To reproduce > > OpenLDAP 2.4.23, Berkeley DB 4.6.21 > > Use slapadd to prepare directory with following > > dn: cn=3DRoot,dc=3Dtest > objectClass: top > objectClass: applicationProcess > cn: Root > > dn: cn=3Dtop,cn=3DRoot,dc=3Dtest > objectClass: top > objectClass: device > objectClass: dynamicObject > entryTTL: 60 > entryExpireTimestamp: 20101024113626Z > cn: top > > dn: cn=3Dleaf1,cn=3Dtop,cn=3DRoot,dc=3Dtest > objectClass: top > objectClass: device > objectClass: dynamicObject > entryTTL: 60 > entryExpireTimestamp: 20101024113626Z > cn: leaf1 > > dn: cn=3Dleaf2,cn=3Dtop,cn=3DRoot,dc=3Dtest > objectClass: top > objectClass: device > objectClass: dynamicObject > entryTTL: 60 > entryExpireTimestamp: 20101024113626Z > cn: leaf2 > > dn: cn=3Dleaf3,cn=3Dtop,cn=3DRoot,dc=3Dtest > objectClass: top > objectClass: device > objectClass: dynamicObject > entryTTL: 60 > entryExpireTimestamp: 20101024113626Z > cn: leaf3 > > > Relevant slapd.conf entries > > database bdb > suffix "cn=3DRoot,dc=3Dtest" > rootdn "cn=3DRoot,dc=3Dtest" > 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=3D"cn=3DRoot,dc=3Dtest" > by users write > by * read > > > Running "slapd -d 1 -d 256" produces following > > put_filter: > "(&(objectClass=3DdynamicObject)(entryExpireTimestamp<=3D20101025082446Z)= > )" > put_filter: AND > put_filter_list > "(objectClass=3DdynamicObject)(entryExpireTimestamp<=3D20101025082446Z)" > put_filter: "(objectClass=3DdynamicObject)" > put_filter: simple > put_simple_filter: "objectClass=3DdynamicObject" > put_filter: "(entryExpireTimestamp<=3D20101025082446Z)" > put_filter: simple > put_simple_filter: "entryExpireTimestamp<=3D20101025082446Z" > ber_scanf fmt ({mm}) ber: > ber_scanf fmt ({mm}) ber: > =3D> bdb_search > bdb_dn2entry("cn=3Droot,dc=3Dtest") > =3D> bdb_dn2id("cn=3Droot,dc=3Dtest") > <=3D bdb_dn2id: got id=3D0x1 > entry_decode: "cn=3DRoot,dc=3Dtest" > <=3D entry_decode(cn=3DRoot,dc=3Dtest) > search_candidates: base=3D"cn=3Droot,dc=3Dtest" (0x00000001) scope=3D2 > =3D> bdb_dn2idl("cn=3Droot,dc=3Dtest") > =3D> bdb_equality_candidates (objectClass) > =3D> key_read > <=3D bdb_index_read: failed (-30989) > <=3D bdb_equality_candidates: id=3D0, first=3D0, last=3D0 > =3D> bdb_equality_candidates (objectClass) > =3D> key_read > <=3D bdb_index_read 4 candidates > <=3D bdb_equality_candidates: id=3D4, first=3D2, last=3D5 > =3D> bdb_inequality_candidates (entryExpireTimestamp) > =3D> key_read > <=3D bdb_index_read 1 candidates > =3D> key_read > <=3D bdb_index_read: failed (-30989) > <=3D bdb_inequality_candidates: id=3D1, first=3D2, last=3D2 > bdb_search_candidates: id=3D1 first=3D2 last=3D2 > entry_decode: "cn=3Dtop,cn=3DRoot,dc=3Dtest" > <=3D entry_decode(cn=3Dtop,cn=3DRoot,dc=3Dtest) > =3D> bdb_dn2id("cn=3Dtop,cn=3Droot,dc=3Dtest") > <=3D bdb_dn2id: got id=3D0x2 > send_ldap_result: conn=3D-1 op=3D0 p=3D0 > bdb_dn2entry("cn=3Dtop,cn=3Droot,dc=3Dtest") > =3D> bdb_dn2id_children("cn=3Dtop,cn=3Droot,dc=3Dtest") > <=3D bdb_dn2id_children("cn=3Dtop,cn=3Droot,dc=3Dtest"): (0) > send_ldap_result: conn=3D-1 op=3D0 p=3D0 > DDS dn=3D"cn=3Dtop,cn=3Droot,dc=3Dtest" is non-leaf; deferring. > DDS expired=3D0 > > > ldapsearch "(entryExpireTimestamp=3D*)" produces > > dn: cn=3Dtop,cn=3DRoot,dc=3Dtest > entryExpireTimestamp: 20101024113626Z > > dn: cn=3Dleaf1,cn=3Dtop,cn=3DRoot,dc=3Dtest > entryExpireTimestamp: 20101024113626Z > > dn: cn=3Dleaf2,cn=3Dtop,cn=3DRoot,dc=3Dtest > entryExpireTimestamp: 20101024113626Z > > dn: cn=3Dleaf3,cn=3Dtop,cn=3DRoot,dc=3Dtest > entryExpireTimestamp: 20101024113626Z > > > where ldapsearch "(entryExpireTimestamp<=3D20101024113626Z)" only finds > > dn: cn=3Dtop,cn=3DRoot,dc=3Dtest > entryExpireTimestamp: 20101024113626Z > > > If I change all timestamps to distinct values then expiration of > complete > branches works as expected. > > > Thanks, > Petteri > > > -- -- 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#6683) DDS fails with expired branches
by Petteri.Stenius＠ubisecure.com 08 Nov '10

08 Nov '10

Hello, Further investigation shows this issue is caused by operator LE search failing with indexed attributes. Also this indexed search issue is NOT limited to DDS.=20 I have reproduced the issue with integerOrderingMatch and generalizedTimeOrderingMatch.=20 The piece of code I find suspicious is in servers/back-bdb/idl.c, somewhere in the middle it reads /* skip presence key on range inequality lookups */ while (rc =3D=3D 0 && kptr->size !=3D len) { rc =3D cursor->c_get( cursor, kptr, &data, flags | DB_NEXT_NODUP ); } If I remove this block then LE search works as expected with indexed attributes. The key here seems to be the DB_NEXT_NODUP flag. This flag causes the iterator block a few lines below to return partial matches. Thanks, Petteri -----Original Message----- From: openldap-bugs-bounces(a)OpenLDAP.org [mailto:openldap-bugs-bounces@OpenLDAP.org] On Behalf Of petteri.stenius(a)ubisecure.com Sent: Monday, October 25, 2010 1:35 PM To: openldap-its(a)openldap.org Subject: (ITS#6683) DDS fails with expired branches Full_Name:=20 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=3D"cn=3Dtop,cn=3Droot,dc=3Dtest" is non-leaf; deferring. To reproduce OpenLDAP 2.4.23, Berkeley DB 4.6.21 Use slapadd to prepare directory with following dn: cn=3DRoot,dc=3Dtest objectClass: top objectClass: applicationProcess cn: Root dn: cn=3Dtop,cn=3DRoot,dc=3Dtest objectClass: top objectClass: device objectClass: dynamicObject entryTTL: 60 entryExpireTimestamp: 20101024113626Z cn: top dn: cn=3Dleaf1,cn=3Dtop,cn=3DRoot,dc=3Dtest objectClass: top objectClass: device objectClass: dynamicObject entryTTL: 60 entryExpireTimestamp: 20101024113626Z cn: leaf1 dn: cn=3Dleaf2,cn=3Dtop,cn=3DRoot,dc=3Dtest objectClass: top objectClass: device objectClass: dynamicObject entryTTL: 60 entryExpireTimestamp: 20101024113626Z cn: leaf2 dn: cn=3Dleaf3,cn=3Dtop,cn=3DRoot,dc=3Dtest objectClass: top objectClass: device objectClass: dynamicObject entryTTL: 60 entryExpireTimestamp: 20101024113626Z cn: leaf3 Relevant slapd.conf entries database bdb suffix "cn=3DRoot,dc=3Dtest" rootdn "cn=3DRoot,dc=3Dtest" 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=3D"cn=3DRoot,dc=3Dtest" by users write by * read Running "slapd -d 1 -d 256" produces following put_filter: "(&(objectClass=3DdynamicObject)(entryExpireTimestamp<=3D20101025082446Z)= )" put_filter: AND put_filter_list "(objectClass=3DdynamicObject)(entryExpireTimestamp<=3D20101025082446Z)" put_filter: "(objectClass=3DdynamicObject)" put_filter: simple put_simple_filter: "objectClass=3DdynamicObject" put_filter: "(entryExpireTimestamp<=3D20101025082446Z)" put_filter: simple put_simple_filter: "entryExpireTimestamp<=3D20101025082446Z" ber_scanf fmt ({mm}) ber: ber_scanf fmt ({mm}) ber: =3D> bdb_search bdb_dn2entry("cn=3Droot,dc=3Dtest") =3D> bdb_dn2id("cn=3Droot,dc=3Dtest") <=3D bdb_dn2id: got id=3D0x1 entry_decode: "cn=3DRoot,dc=3Dtest" <=3D entry_decode(cn=3DRoot,dc=3Dtest) search_candidates: base=3D"cn=3Droot,dc=3Dtest" (0x00000001) scope=3D2 =3D> bdb_dn2idl("cn=3Droot,dc=3Dtest") =3D> bdb_equality_candidates (objectClass) =3D> key_read <=3D bdb_index_read: failed (-30989) <=3D bdb_equality_candidates: id=3D0, first=3D0, last=3D0 =3D> bdb_equality_candidates (objectClass) =3D> key_read <=3D bdb_index_read 4 candidates <=3D bdb_equality_candidates: id=3D4, first=3D2, last=3D5 =3D> bdb_inequality_candidates (entryExpireTimestamp) =3D> key_read <=3D bdb_index_read 1 candidates =3D> key_read <=3D bdb_index_read: failed (-30989) <=3D bdb_inequality_candidates: id=3D1, first=3D2, last=3D2 bdb_search_candidates: id=3D1 first=3D2 last=3D2 entry_decode: "cn=3Dtop,cn=3DRoot,dc=3Dtest" <=3D entry_decode(cn=3Dtop,cn=3DRoot,dc=3Dtest) =3D> bdb_dn2id("cn=3Dtop,cn=3Droot,dc=3Dtest") <=3D bdb_dn2id: got id=3D0x2 send_ldap_result: conn=3D-1 op=3D0 p=3D0 bdb_dn2entry("cn=3Dtop,cn=3Droot,dc=3Dtest") =3D> bdb_dn2id_children("cn=3Dtop,cn=3Droot,dc=3Dtest") <=3D bdb_dn2id_children("cn=3Dtop,cn=3Droot,dc=3Dtest"): (0) send_ldap_result: conn=3D-1 op=3D0 p=3D0 DDS dn=3D"cn=3Dtop,cn=3Droot,dc=3Dtest" is non-leaf; deferring. DDS expired=3D0 ldapsearch "(entryExpireTimestamp=3D*)" produces dn: cn=3Dtop,cn=3DRoot,dc=3Dtest entryExpireTimestamp: 20101024113626Z dn: cn=3Dleaf1,cn=3Dtop,cn=3DRoot,dc=3Dtest entryExpireTimestamp: 20101024113626Z dn: cn=3Dleaf2,cn=3Dtop,cn=3DRoot,dc=3Dtest entryExpireTimestamp: 20101024113626Z dn: cn=3Dleaf3,cn=3Dtop,cn=3DRoot,dc=3Dtest entryExpireTimestamp: 20101024113626Z where ldapsearch "(entryExpireTimestamp<=3D20101024113626Z)" only finds dn: cn=3Dtop,cn=3DRoot,dc=3Dtest entryExpireTimestamp: 20101024113626Z If I change all timestamps to distinct values then expiration of complete branches works as expected. Thanks, Petteri

1 0

Re: (ITS#6693) Value dependent ACL issues
by rhafer＠suse.de 08 Nov '10

08 Nov '10

Hm, that patch was obviously wrong. Even though it resulted in working value-dependent ACLs, it completely broke ACL caching. This patch should work better: ------------------------------------------------------------------- --- a/servers/slapd/slap.h +++ b/servers/slapd/slap.h @@ -1557,6 +1557,7 @@ typedef struct AccessControlState { /* Value dependent acl where processing can restart */ AccessControl *as_vd_acl; + int as_vd_acl_present; int as_vd_acl_count; slap_mask_t as_vd_mask; @@ -1567,7 +1568,7 @@ typedef struct AccessControlState { /* True if started to process frontend ACLs */ int as_fe_done; } AccessControlState; -#define ACL_STATE_INIT { NULL, ACL_NONE, NULL, 0, ACL_PRIV_NONE, -1, 0 } +#define ACL_STATE_INIT { NULL, ACL_NONE, NULL, 0, 0, ACL_PRIV_NONE, -1, 0 } typedef struct AclRegexMatches { int dn_count; --- a/servers/slapd/acl.c +++ b/servers/slapd/acl.c @@ -220,7 +220,7 @@ slap_access_allowed( state = &acl_state; if ( state->as_desc == desc && state->as_access == access && - state->as_vd_acl != NULL ) + state->as_vd_acl_present ) { a = state->as_vd_acl; count = state->as_vd_acl_count; @@ -405,7 +405,7 @@ access_allowed_mask( if ( state->as_desc == desc && state->as_access == access && state->as_result != -1 && - state->as_vd_acl == NULL ) + !state->as_vd_acl_present ) { Debug( LDAP_DEBUG_ACL, "=> access_allowed: result was in cache (%s)\n", @@ -615,7 +615,8 @@ slap_acl_get( continue; } - if ( state->as_vd_acl == NULL ) { + if ( !state->as_vd_acl_present ) { + state->as_vd_acl_present = 1; state->as_vd_acl = prev; state->as_vd_acl_count = *count - 1; ACL_PRIV_ASSIGN ( state->as_vd_mask, *mask ); @@ -714,7 +715,8 @@ slap_acl_get( * Record value-dependent access control state */ #define ACL_RECORD_VALUE_STATE do { \ - if( state && state->as_vd_acl == NULL ) { \ + if( state && !state->as_vd_acl_present ) { \ + state->as_vd_acl_present = 1; \ state->as_vd_acl = a; \ state->as_vd_acl_count = count; \ ACL_PRIV_ASSIGN( state->as_vd_mask, *mask ); \ ------------------------------------------------------------------- Comments welcome. Ralf

1 0

Re: (ITS#6686) VLV overlay fails to handle multiple search operations per LDAP connection
by raphael.ouazana＠linagora.com 05 Nov '10

05 Nov '10

Hi ! Le Ven 29 octobre 2010 11:12, hyc(a)symas.com a écrit : > I guess as long as you observe the svi_max config parameter, there's no > reason > not to adopt your suggestion. Feel free to followup here with your patch > for > review. Here is the patch: ftp://ftp.openldap.org/incoming/raphael-ouazana-101105-sssvlv-multiple-requ… It applies to HEAD of today. If you need it, I can send you a patch for RE24 too. The patch includes the modification of the man page. Legal notice: This patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in this following patch were developed by Raphael Ouazana raphael.ouazana(a)linagora.com. These modifications are not subject to any license of Linagora. The attached modifications to OpenLDAP Software are subject to the following notice: Copyright 2010 Raphael Ouazana, Linagora Redistribution and use in source and binary forms, with or without modification, are permitted only as authorized by the OpenLDAP Public License. Regards, Raphaël Ouazana

1 0

Re: (ITS#6657) back-sql segfault in backsql_search
by david＠dasz.at 05 Nov '10

05 Nov '10

On 11/5/2010 12:03 PM, Howard Chu wrote: > david(a)dasz.at wrote: >> This is a multi-part message in MIME format. >> --------------050908020600020509000208 >> Content-Type: text/plain; charset=ISO-8859-1; format=flowed >> Content-Transfer-Encoding: 7bit >> >> Hi, >> >> I've tried to rebuild the slapd (from the debian sources) with >> -DSLAP_NO_SL_MALLOC=1, but this build doesn't even manage to finish the >> test-suite which is automatically run. > > You should never build code with this flag. It's for OpenLDAP developers > only, and I personally am deeply opposed to its existence. Its effect on > the code is fundamentally wrong. Dear Howard, does that mean I've wasted a day for nothing? Do you have any better ideas how to debug/fix the original issue? David -- dasz.at OG Tel: +43 (0)664 2602670 Web: http://dasz.at Klosterneuburg UID: ATU64260999 FB-Nr.: FN 309285 g FB-Gericht: LG Korneuburg

1 0

ITS#6657
by hyc＠symas.com 05 Nov '10

05 Nov '10

> To: david(a)dasz.at > Cc: openldap-its(a)openldap.org > > Please > > - rebuild with -DSLAP_NO_SL_MALLOC=1 (you only need to recompile sl_malloc.c) This is not helpful. As noted in #6691, the offending allocation is memory residing on the stack. Changing any malloc behavior will have no effect on any stack-based memory use. > - run slapd under valgrind --tool=memcheck --leak-check=full and minimal > loglevel (e.g. -d stats) > > - send valgrind's output (if anything surfaces) > > Thanks, p. > -- -- 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#6657) back-sql segfault in backsql_search
by hyc＠symas.com 05 Nov '10

05 Nov '10

david(a)dasz.at wrote: > This is a multi-part message in MIME format. > --------------050908020600020509000208 > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > Content-Transfer-Encoding: 7bit > > Hi, > > I've tried to rebuild the slapd (from the debian sources) with > -DSLAP_NO_SL_MALLOC=1, but this build doesn't even manage to finish the > test-suite which is automatically run. You should never build code with this flag. It's for OpenLDAP developers only, and I personally am deeply opposed to its existence. Its effect on the code is fundamentally wrong. -- -- 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

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