- openldap-bugs - openldap.org

Re: (ITS#4801) segfault in dynlist
by quanah＠stanford.edu 11 Jan '07

11 Jan '07

--On Thursday, January 11, 2007 8:57 PM +0000 quanah(a)stanford.edu wrote: > > > --On Thursday, January 11, 2007 9:53 PM +0100 Pierangelo Masarati > <ando(a)sys-net.it> wrote: > >> quanah(a)stanford.edu wrote: >>> Full_Name: Quanah Gibson-Mount >>> Version: 2.3.32 >>> OS: Linux 2.6 (64-bit) >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (171.64.19.81) >>> >> I'm not seeing anything like that, neither with HEAD nor with re23. It >> might be worth having a bit more details on your configuration, since >> that resulting from test044 (which basically complies with the info you >> provided) doesn't even hit that line of code (because rs->sr_flags == 0). >> So there must be something in between that causes the entry to be freed. >> That could be slapo-dynlist in some cases, but also slapo-translucent, >> slapo-collect, slapo-rwm or slapo-valsort. I guess at this point you >> should share the conf, the data and the op that's causing trouble. > > The search I'm performing is: Okay, I can confirm it works as expected once valsort is no longer used.... --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

Re: (ITS#4801) segfault in dynlist
by quanah＠stanford.edu 11 Jan '07

11 Jan '07

--On Thursday, January 11, 2007 9:53 PM +0100 Pierangelo Masarati <ando(a)sys-net.it> wrote: > quanah(a)stanford.edu wrote: >> Full_Name: Quanah Gibson-Mount >> Version: 2.3.32 >> OS: Linux 2.6 (64-bit) >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (171.64.19.81) >> > I'm not seeing anything like that, neither with HEAD nor with re23. It > might be worth having a bit more details on your configuration, since > that resulting from test044 (which basically complies with the info you > provided) doesn't even hit that line of code (because rs->sr_flags == 0). > So there must be something in between that causes the entry to be freed. > That could be slapo-dynlist in some cases, but also slapo-translucent, > slapo-collect, slapo-rwm or slapo-valsort. I guess at this point you > should share the conf, the data and the op that's causing trouble. The search I'm performing is: ldapsearch -LLL -Q -h ldap-dev1.stanford.edu -b "cn=groups,cn=applications,dc=stanford,dc=edu" the slapd.conf is as follows, and the group configurations are as previously noted. My principal has full read into the LDAP database, so the only ACL parsed is access to * for it. I am using valsort, so perhaps it is an interaction between those two? # $Id: slapd.conf.dev,v 1.7 2007/01/11 00:05:44 quanah Exp $ # # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # include /usr/local/etc/openldap/schema/core.schema include /usr/local/etc/openldap/schema/cosine.schema include /usr/local/etc/openldap/schema/dyngroup.schema include /usr/local/etc/openldap/schema/krb5-kdc.schema include /usr/local/etc/openldap/schema/inetorgperson.schema include /usr/local/etc/openldap/schema/misc.schema include /usr/local/etc/openldap/schema/nis.schema include /usr/local/etc/openldap/schema/eduperson.schema include /usr/local/etc/openldap/schema/suacct.schema include /usr/local/etc/openldap/schema/superson.schema include /usr/local/etc/openldap/schema/suapplication.schema # Allow V2 binds allow bind_v2 # Use star cert TLSCertificateFile /usr/local/etc/openldap/stardomain.crt TLSCertificateKeyFile /usr/local/etc/openldap/stardomain.key TLSCACertificateFile /usr/local/etc/openldap/comodo.pem # Define global ACLs include /usr/local/etc/openldap/slapd.acl # pidfile /var/run/slapd.pid argsfile /var/run/slapd.args # Set the default search base for clients that don't specify a base. defaultsearchbase "dc=stanford,dc=edu" # Turn gentlehup off, it takes too long. gentlehup off # Read slapd.conf(5) for possible values loglevel 256 # Set the number of threads (8 seems to work best) threads 8 # Set the number of threads to use in tool mode tool-threads 2 # Set the timeout for idle connections #idletimeout 30 # SASL conf sasl-realm stanford.edu sasl-authz-policy both sasl-regexp uid=(.*)/cgi,cn=stanford.edu,cn=gssapi,cn=auth ldap:///cn=cgi,cn=applications,dc=stanford,dc=edu??sub?krb5PrincipalName=$1/cgi@stanford.edu sasl-regexp uid=service/(.*),cn=stanford.edu,cn=gssapi,cn=auth ldap:///cn=Service,cn=Applications,dc=stanford,dc=edu??sub?krb5PrincipalName=service/$1@stanford.edu sasl-regexp uid=webauth/(.*),cn=stanford.edu,cn=gssapi,cn=auth ldap:///cn=Webauth,cn=Applications,dc=stanford,dc=edu??sub?krb5PrincipalName=webauth/$1@stanford.edu sasl-regexp uid=(.*),cn=stanford.edu,cn=gssapi,cn=auth ldap:///uid=$1,cn=Accounts,dc=stanford,dc=edu??sub?suSeasStatus=active # Load dynamic backend modules: modulepath /usr/local/lib/openldap moduleload back_hdb.la moduleload back_monitor.la moduleload valsort.la moduleload dynlist.la ####################################################################### # stanford.edu database definitions ####################################################################### database hdb suffix "dc=stanford,dc=edu" rootdn "cn=manager,dc=stanford,dc=edu" # Valsort Overlay overlay valsort valsort-attr ou cn=people,dc=stanford,dc=edu weighted valsort-attr suAffiliation cn=people,dc=stanford,dc=edu weighted valsort-attr suDisplayAffiliation cn=people,dc=stanford,dc=edu weighted # Dynlist Overlay overlay dynlist dynlist-attrset groupOfURLS memberURL member # Let ldapadmin have limitless searches limits group="cn=ldapadmin,cn=applications,dc=stanford,dc=edu" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited # Let the Athletics principal have limitless searches limits dn.exact="cn=athletics,cn=service,cn=applications,dc=stanford,dc=edu" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited # Let the Authority audit principal have limitless searches limits dn.exact="cn=workgroup-audit,cn=service,cn=applications,dc=stanford,dc=edu" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited # Let the Registry Data Auditor principal have limitless searches limits dn.exact="cn=RegistryDataAuditor,cn=Service,cn=Applications,dc=stanford,dc=edu" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited # Let the ispace prinicpal have a search of 5000 entries limits dn.exact="cn=ispace,cn=Service,cn=Applications,dc=stanford,dc=edu" time.soft=unlimited time.hard=unlimited size.soft=5000 size.hard=5000 # Let the GSB person principal have unlimited searches limits dn.exact="cn=gsb-person,cn=service,cn=applications,dc=stanford,dc=edu" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited # Save the time that the entry gets modified lastmod on include /usr/local/etc/openldap/syncrepl.conf # Set the location of where the database storage files go. directory /var/lib/ldap dbconfig set_cachesize 3 536870912 1 dbconfig set_lg_regionmax 262144 dbconfig set_lg_bsize 2097152 dbconfig set_lg_dir /var/log/bdb dbconfig set_lk_max_locks 3000 dbconfig set_lk_max_objects 1500 dbconfig set_lk_max_lockers 1500 # # Automatically remove log files that are no longer needed. dbconfig set_flags DB_LOG_AUTOREMOVE # # Setting set_tas_spins reduces resource contention from multiple clients on systems with multiple CPU's. dbconfig set_tas_spins 1 # Checkpoint the database to prevent transaction loss in unclean shutdowns, and speed up slapd shutdowns. checkpoint 1024 5 # Entries to cache in memory cachesize 50000 # IDL Entries to cache in memory idlcachesize 50000 # Entries to free up when cache gets full cachefree 1000 # Change the sub_any index length from 4 to 3 so that searches like *lee* work. index_substr_any_len 3 # Indices to maintain index default eq index cn eq,sub index dc index displayName index entryUUID index givenName eq,sub index homePhone eq,sub index krb5PrincipalName index mail eq,sub index mobile eq,sub index modifyTimestamp index o index objectClass index pager eq,sub index sn eq,sub,approx index suAffiliation index suCalendarStatus index suCardNumber pres,eq index suCN eq,sub index suDialinStatus index suDisplayAffiliation index suEmailPager eq,sub index suGeneralID eq,sub index suGivenName eq,sub index suGwAffilFax1 eq,sub index suGwAffilFax2 eq,sub index suGwAffilFax3 eq,sub index suGwAffilFax4 eq,sub index suGwAffilFax5 eq,sub index suGwAffilPhone1 eq,sub index suGwAffilPhone2 eq,sub index suGwAffilPhone3 eq,sub index suGwAffilPhone4 eq,sub index suGwAffilPhone5 eq,sub index suKerberosStatus index suLelandStatus index suLocalPhone eq,sub index suMaildrop index suOtherName index suPermanentPhone eq,sub index suPrimaryOrganizationID index suPrivilegeGroup eq,sub index suProxyCardNumber pres,eq index suRegID index suRegisteredName eq,sub index suResidencePhone eq,sub index suSearchID index suSeasStatus index suSeasSunetID index suSN eq,sub,approx index suSunetID index suUniqueIdentifier index suUnivID index suVisibAffilAddress1 index suVisibAffilAddress2 index suVisibAffilAddress3 index suVisibAffilAddress4 index suVisibAffilAddress5 index suVisibAffilFax1 index suVisibAffilFax2 index suVisibAffilFax3 index suVisibAffilFax4 index suVisibAffilFax5 index suVisibAffiliation1 index suVisibAffiliation2 index suVisibAffiliation3 index suVisibAffiliation4 index suVisibAffiliation5 index suVisibAffilPhone1 index suVisibAffilPhone2 index suVisibAffilPhone3 index suVisibAffilPhone4 index suVisibAffilPhone5 index suVisibEmail index suVisibFacsimileTelephoneNumber index suVisibHomeAddress index suVisibHomePage index suVisibHomePhone index suVisibIdentity index suVisibLocalAddress index suVisibMailAddress index suVisibMailCode index suVisibMobilePhone index suVisibPagerEmail index suVisibPagerPhone index suVisibPermanentAddress index suVisibProfile index suVisibStreet index suVisibSunetID index suVisibTelephoneNumber index telephoneNumber eq,sub index uid pres,eq index uidNumber ####################################################################### # back-monitor database definitions ####################################################################### database monitor reverse-lookup on -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

Re: (ITS#4801) segfault in dynlist
by ando＠sys-net.it 11 Jan '07

11 Jan '07

quanah(a)stanford.edu wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.3.32 > OS: Linux 2.6 (64-bit) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (171.64.19.81) > I'm not seeing anything like that, neither with HEAD nor with re23. It might be worth having a bit more details on your configuration, since that resulting from test044 (which basically complies with the info you provided) doesn't even hit that line of code (because rs->sr_flags == 0). So there must be something in between that causes the entry to be freed. That could be slapo-dynlist in some cases, but also slapo-translucent, slapo-collect, slapo-rwm or slapo-valsort. I guess at this point you should share the conf, the data and the op that's causing trouble. p. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. 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#4801) segfault in dynlist
by quanah＠stanford.edu 11 Jan '07

11 Jan '07

--On Thursday, January 11, 2007 12:18 AM +0000 quanah(a)stanford.edu wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.3.32 > OS: Linux 2.6 (64-bit) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (171.64.19.81) > > > I decided to start playing with the dynlist overlay, but it cores slapd: I removed all my custom patches, and validated this happens in stock 2.3.32: (gdb) bt #0 0x00002b3947cbb3e3 in __db_shalloc (p=Variable "p" is not available. ) at ../dist/../env/db_salloc.c:157 #1 0x00002b3947cd8e2d in __memp_alloc (dbmp=0x2b3946abe2a0, memreg=0x2b3946abe1c0, mfp=0x2b3a43d2beb8, len=16543, offsetp=0x0, retp=0x414fc000) at ../dist/../mp/mp_alloc.c:94 #2 0x00002b3947cda2f6 in __memp_fget (dbmfp=0x2b39479af960, pgnoaddr=0x414fc0fc, flags=0, addrp=Variable "addrp" is not available. ) at ../dist/../mp/mp_fget.c:348 #3 0x00002b3947c66e3b in __bam_search (dbc=0x2b3947aee400, root_pgno=101187584, key=0x414fc310, flags=1409, stop=1, recnop=0x0, exactp=0x414fc224) at ../dist/../btree/bt_search.c:307 #4 0x00002b3947c5bc75 in __bam_c_search (dbc=0x2b3947aee400, root_pgno=0, key=0x414fc310, flags=28, exactp=0x414fc224) at ../dist/../btree/bt_cursor.c:2547 #5 0x00002b3947c5cc86 in __bam_c_get (dbc=0x2b3947aee400, key=0x414fc310, data=0x414fc2f0, flags=28, pgnop=0x414fc2b4) at ../dist/../btree/bt_cursor.c:962 #6 0x00002b3947ca74f0 in __db_c_get (dbc_arg=0x2b3947aee740, key=0x414fc310, data=0x414fc2f0, flags=28) at ../dist/../db/db_cam.c:643 #7 0x00002b3947b1b92e in hdb_id2entry (be=Variable "be" is not available. ) at id2entry.c:125 #8 0x00002b3947b20911 in hdb_cache_find_id (op=0x4167cd30, tid=0x0, id=376099, eip=0x4167c890, islocked=1, locker=26, lock=0x4167c820) at cache.c:760 #9 0x00002b3947b14034 in hdb_search (op=0x4167cd30, rs=0x4167cf00) at search.c:695 #10 0x0000000000477c6b in overlay_op_walk (op=0x4167cd30, rs=0x4167cf00, which=op_search, oi=0x2b39479ca530, on=0x0) at backover.c:508 #11 0x0000000000477fc5 in over_op_func (op=0x4167cd30, rs=0x4167cf00, which=op_search) at backover.c:560 #12 0x00002b394802c336 in dynlist_response (op=0x2aaaab0e03c8, rs=0x417feee0) at dynlist.c:463 #13 0x0000000000477afa in over_back_response (op=0x2aaaab0e03c8, rs=0x417feee0) at backover.c:236 #14 0x0000000000434eea in slap_send_search_entry (op=0x2aaaab0e03c8, rs=0x417feee0) at result.c:717 #15 0x00002b3947b14714 in hdb_search (op=0x2aaaab0e03c8, rs=0x417feee0) at search.c:878 #16 0x0000000000477c6b in overlay_op_walk (op=0x2aaaab0e03c8, rs=0x417feee0, which=op_search, oi=0x2b39479ca530, on=0x0) at backover.c:508 #17 0x0000000000477fc5 in over_op_func (op=0x2aaaab0e03c8, rs=0x417feee0, which=op_search) at backover.c:560 #18 0x00000000004293d2 in fe_op_search (op=0x2aaaab0e03c8, rs=0x417feee0) at search.c:355 #19 0x0000000000429c12 in do_search (op=0x2aaaab0e03c8, rs=0x417feee0) at search.c:217 #20 0x00000000004278b9 in connection_operation (ctx=dwarf2_read_address: Corrupted DWARF expression. ) at connection.c:1132 #21 0x0000000000427ca6 in connection_read_thread (ctx=0x417ff030, argv=Variable "argv" is not available. ) at connection.c:1260 #22 0x00002b3945688794 in ldap_int_thread_pool_wrapper (xpool=0x2b3946ee0080) at tpool.c:478 -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

Re: (ITS#4804) slapd shutdown hang
by Kurt＠OpenLDAP.org 11 Jan '07

11 Jan '07

At 10:13 AM 1/11/2007, kurt(a)OpenLDAP.org wrote: >Full_Name: Kurt Zeilenga >Version: HEAD >OS: FreeBSD 4 >URL: ftp://ftp.openldap.org/incoming/ >Submission from: (NULL) (71.80.218.136) > > >In current HEAD (as well as for the last couple of days), slapd(8) has been >consistently (every time) been hanging on shutdown. For instance, when running >test000, gdb shows: >> thread apply all bt >Thread 2 (process 71085, thread 2): >#0 0x28fc0197 in _thread_kern_sched () from /usr/lib/libc_r.so.4 >#1 0x28fc09e5 in _thread_kern_sched_state_unlock () from /usr/lib/libc_r.so.4 >#2 0x28fc296d in pthread_cond_timedwait () from /usr/lib/libc_r.so.4 >#3 0x28fa959b in _thread_gc () from /usr/lib/libc_r.so.4 >#4 0x28f824d8 in _thread_start () from /usr/lib/libc_r.so.4 >#5 0x0 in ?? () > >Thread 1 (process 71085, thread 1): >#0 0x28fc1914 in __sys_poll () from /usr/lib/libc_r.so.4 >#1 0x28fc0df9 in _thread_kern_sched_state_unlock () from /usr/lib/libc_r.so.4 >#2 0x28fc07ae in _thread_kern_scheduler () from /usr/lib/libc_r.so.4 >#3 0x0 in ?? () > >The last few log messages are: >daemon: shutdown requested and initiated. >slapd shutdown: waiting for 0 threads to terminate >slapd shutdown: initiated >====> bdb_cache_release_all >slapd destroy: freeing system resources. > >I suspect a recent (in the last week or so) is the cause... I complete rebuild seems have cured this problem. Kurt

1 0

(ITS#4804) slapd shutdown hang
by kurt＠OpenLDAP.org 11 Jan '07

11 Jan '07

Full_Name: Kurt Zeilenga Version: HEAD OS: FreeBSD 4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (71.80.218.136) In current HEAD (as well as for the last couple of days), slapd(8) has been consistently (every time) been hanging on shutdown. For instance, when running test000, gdb shows: > thread apply all bt Thread 2 (process 71085, thread 2): #0 0x28fc0197 in _thread_kern_sched () from /usr/lib/libc_r.so.4 #1 0x28fc09e5 in _thread_kern_sched_state_unlock () from /usr/lib/libc_r.so.4 #2 0x28fc296d in pthread_cond_timedwait () from /usr/lib/libc_r.so.4 #3 0x28fa959b in _thread_gc () from /usr/lib/libc_r.so.4 #4 0x28f824d8 in _thread_start () from /usr/lib/libc_r.so.4 #5 0x0 in ?? () Thread 1 (process 71085, thread 1): #0 0x28fc1914 in __sys_poll () from /usr/lib/libc_r.so.4 #1 0x28fc0df9 in _thread_kern_sched_state_unlock () from /usr/lib/libc_r.so.4 #2 0x28fc07ae in _thread_kern_scheduler () from /usr/lib/libc_r.so.4 #3 0x0 in ?? () The last few log messages are: daemon: shutdown requested and initiated. slapd shutdown: waiting for 0 threads to terminate slapd shutdown: initiated ====> bdb_cache_release_all slapd destroy: freeing system resources. I suspect a recent (in the last week or so) is the cause...

1 0

Re: (ITS#4796) Contribution: JLDAP support for simple paging of results (RFC 2696)
by radovan＠skolnik.info 11 Jan '07

11 Jan '07

Hello! I have added the following to NOTICE file inside the provided .zip file: This patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Radovan Skolnik radovan(a)skolnik.info. These modifications are not subject to any license of TEMPEST, a.s. I, Radovan Skolnik, hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice. I hope that is OK. Best regards Radovan Skolnik On Tuesday 09 January 2007 04:14, Kurt D. Zeilenga wrote: > At 03:28 PM 1/6/2007, radovan(a)skolnik.info wrote: > >Full_Name: Radovan Skolnik > >Version: JLDAP CVS version > >OS: Windows/Java > >URL: http://www.skolnik.info/LDAPPagedResults.zip > >Submission from: (NULL) (82.119.120.128) > > > > > >Hello, > > > >I hope this is the right place to make this submission ;-) Recently I > > found that JLDAP does not support simple paging mechanism via control as > > stated in RFC2696 (control OID 1.2.840.113556.1.4.319). So I made an > > attempt to implement it and it seems to me it works as it's supposed to. > > I would like to contribute it to the project for the benefit of others. > > The files can be found at > >http://www.skolnik.info/LDAPPagedResults.zip If there is something more > > needed from me please let me know. > > Your submission lacks both a notice of origin and a > rights statement, as required of contributions. See > <http://www.openldap.org/devel/contributing.html#notice>. > Though submissions such as this should be in the form > of patch file (with notices placed above the patch in the > file), a zip file is acceptable. In this case, just place > the required notice and statement in a file called NOTICE. > > Please revise. -- Kurt

1 0

(ITS#4803) slapacl(8) man page still mentions the "defaultaccess" directive
by ando＠sys-net.it 11 Jan '07

11 Jan '07

Full_Name: Pierangelo Masarati Version: HEAD/re23 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (131.175.154.35) Submitted by: ando AFAICT it was removed since 2.1... p.

1 0

(ITS#4802) refint mutex bug
by h.b.furuseth＠usit.uio.no 11 Jan '07

11 Jan '07

Full_Name: Hallvard B Furuseth Version: HEAD OS: Linux URL: Submission from: (NULL) (129.240.202.105) overlays/refint.c:refint_close() does refint_data *id = on->on_bi.bi_private; memset( id, 0, sizeof(*id)); which overwrites id->qmutex. Then refint_db_destroy() does ldap_pvt_thread_mutex_destroy( &id->qmutex ); which can fail. I don't know what the required lifetime for that mutex is - if refint_close() must preserve it, or if it can destroy it and set on->on_bi.bi_private = NULL (so refint_db_destroy will do nothing), or something else.

1 0

(ITS#4801) segfault in dynlist
by quanah＠stanford.edu 11 Jan '07

11 Jan '07

Full_Name: Quanah Gibson-Mount Version: 2.3.32 OS: Linux 2.6 (64-bit) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (171.64.19.81) I decided to start playing with the dynlist overlay, but it cores slapd: (gdb) bt #0 0x00002ae069ec2545 in raise () from /lib/libc.so.6 #1 0x00002ae069ec3cce in abort () from /lib/libc.so.6 #2 0x00002ae069ebc362 in __assert_fail () from /lib/libc.so.6 #3 0x00000000004307e5 in entry_clean (e=Variable "e" is not available. ) at entry.c:462 #4 0x00000000004307f9 in entry_free (e=0x2aaaaaf20df0) at entry.c:485 #5 0x00000000004358c7 in slap_send_search_entry (op=0x4167cd30, rs=0x4167cf00) at result.c:1205 #6 0x00002ae06b7d4914 in hdb_search (op=0x4167cd30, rs=0x4167cf00) at search.c:878 #7 0x000000000047872b in overlay_op_walk (op=0x4167cd30, rs=0x4167cf00, which=op_search, oi=0x2ae06b68a530, on=0x0) at backover.c:508 #8 0x0000000000478a85 in over_op_func (op=0x4167cd30, rs=0x4167cf00, which=op_search) at backover.c:560 #9 0x00002ae06bcec336 in dynlist_response (op=0x2aaaab0e0710, rs=0x417feee0) at dynlist.c:463 #10 0x00000000004785ba in over_back_response (op=0x2aaaab0e0710, rs=0x417feee0) at backover.c:236 #11 0x000000000043542a in slap_send_search_entry (op=0x2aaaab0e0710, rs=0x417feee0) at result.c:717 #12 0x00002ae06b7d4914 in hdb_search (op=0x2aaaab0e0710, rs=0x417feee0) at search.c:878 #13 0x000000000047872b in overlay_op_walk (op=0x2aaaab0e0710, rs=0x417feee0, which=op_search, oi=0x2ae06b68a530, on=0x0) at backover.c:508 #14 0x0000000000478a85 in over_op_func (op=0x2aaaab0e0710, rs=0x417feee0, which=op_search) at backover.c:560 #15 0x0000000000429602 in fe_op_search (op=0x2aaaab0e0710, rs=0x417feee0) at search.c:355 #16 0x0000000000429e42 in do_search (op=0x2aaaab0e0710, rs=0x417feee0) at search.c:217 #17 0x0000000000427ae9 in connection_operation (ctx=Variable "ctx" is not available. ) at connection.c:1132 #18 0x0000000000427ed6 in connection_read_thread (ctx=0x417ff030, argv=Variable "argv" is not available. My group definition is: dn: cn=stanford-staff,cn=groups,cn=applications,dc=stanford,dc=edu objectClass: groupOfURLs cn: stanford-staff memberURL: ldap:///cn=people,dc=stanford,dc=edu??sub?(suprivilegegroup=stanford:staff) and my configuration is: # Dynlist Overlay overlay dynlist dynlist-attrset groupOfURLS memberURL

1 0

Re: (ITS#4800) ldapmodify.c:parse_ldif_control() broken
by h.b.furuseth＠usit.uio.no 10 Jan '07

10 Jan '07

Howard Chu writes: >> Looks like a test case which uses controls is also needed. > > Good idea. Will you add one? Well, Real Soon Now:-) You may have noticed that I'm a bit behind on what I _intended_ to do with OpenLDAP... -- Regards, Hallvard

1 0

Re: (ITS#4800) ldapmodify.c:parse_ldif_control() broken
by hyc＠symas.com 10 Jan '07

10 Jan '07

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: HEAD > OS: Linux > URL: > Submission from: (NULL) (129.240.202.105) > Submitted by: hallvard > > > tools/ldapmodify.c:parse_ldif_control() uses variable s uninitialized - > the variable which supposedly contains the control. Fixed... > Looks like a test case which uses controls is also needed. Good idea. Will you add one? -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

(ITS#4800) ldapmodify.c:parse_ldif_control() broken
by h.b.furuseth＠usit.uio.no 10 Jan '07

10 Jan '07

Full_Name: Hallvard B Furuseth Version: HEAD OS: Linux URL: Submission from: (NULL) (129.240.202.105) Submitted by: hallvard tools/ldapmodify.c:parse_ldif_control() uses variable s uninitialized - the variable which supposedly contains the control. Buggy since ver 1.189 Fri Nov 24 16:05:45 2006 UTC, by hyc: "Parser rewrite: use liblutil's ldif_read_record instead of read_one_record track line numbers across entire LDIF instead of just for a single entry, to allow easier locating of errors. (we can also add the -j jump option later.) split Add/Modify parse paths, precompute size of pmods instead of continuously using realloc. Entry processing is now linear time instead of n^2 with entry size." Looks like a test case which uses controls is also needed.

1 0

Re: (ITS#4494) connections are not asynchrounous
by ando＠sys-net.it 10 Jan '07

10 Jan '07

lrm(a)interlinknetworks.com wrote: > I have patched the 2.3.20 code to make all connections non-blocking. I > did not address referrals, and I'm sure there are other features I > overlooked as well. > > Would it be helpful to see what I have done to get around the problem? > I would be happy to send you a patch. Sure. If you want it to be considered for inclusion in OpenLDAP, please use the ITS (continuing this ITS may be an option). Usually, we request that patches are applied to HEAD code; 2.3.20 might be recent enough wrt/ libldap. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. 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#4648) ldap_pvt_put_filter() succeeds on certain incorrect ldap filters
by hyc＠symas.com 10 Jan '07

10 Jan '07

john.bowers(a)quest.com wrote: > Full_Name: John Bowers > Version: 2.3.27 > OS: Suse Linux 9.1 > URL: ftp://ftp.openldap.org/incoming/john-bowers-06-08-23.patch > Submission from: (NULL) (192.41.88.6) > > > The ldap_search code uses ldap_pvt_put_filter() to add the search filter to the > search request. Certain (if I am not enirely mistaken) invalid search filters > are successfully added by the ldap_pvt_put_filter() code. An example of this > type of search filter follows: > > "(objectclass=group)(cn=test)" I've committed a simpler fix to CVS HEAD. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4494) connections are not asynchrounous
by lrm＠interlinknetworks.com 10 Jan '07

10 Jan '07

I have patched the 2.3.20 code to make all connections non-blocking. I did not address referrals, and I'm sure there are other features I overlooked as well. Would it be helpful to see what I have done to get around the problem? I would be happy to send you a patch. That's all for now, --Larry Morris Interlink Networsk, LLC. lrm(a)interlinknetworks.com On Tue, 2007-01-09 at 19:23, Pierangelo Masarati wrote: > Larry Morris wrote: > > Your efforts are appreciated. > > > > Please see my additional responses inline below. > > > > My single-threaded application requires that multiple connection > > attempts may be in-progress simultaneously, in conjunction with other > > activities that need timely attention. In other words, I need to have > > multiple connections in non-blocking SSL_connect() at the same time, > > with the application doing select() on all the LDAP connection sockets > > as needed. The fix you have provided will allow this? > > > No, at a first glance it's not going to have any impact on that portion > of code. I'll try to sort out if and how anything similar can be done > in that area. > > What is the time-frame for this to be available in a "stable" version? > > > There's no definite timeframe. It's not going to appear in OpenLDAP > 2.3, since it's feature frozen and this does not represent a significant > bug fix, but rather a new, marginal feature. 2.4 is on its way, and > this code will surely be in the next 2.4 release. Whether this will be > still alpha or release, I have no idea right now. > > p. > > > > Ing. Pierangelo Masarati > OpenLDAP Core Team > > SysNet s.n.c. > 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#4799) kbind removal
by Kurt＠OpenLDAP.org 10 Jan '07

10 Jan '07

At 04:48 PM 1/9/2007, Kurt(a)OpenLDAP.org wrote: >At 02:23 PM 1/9/2007, quanah(a)OpenLDAP.org wrote: >>Full_Name: Quanah Gibson-Mount >>Version: HEAD/2.4 >>OS: NA >>URL: ftp://ftp.openldap.org/incoming/ >>Submission from: (NULL) (171.66.155.86) >> >> >>kbind was slated for removal in 2.2, but was missed. Before 2.4 goes out, kbind >>should be finally removed from HEAD & 2.4. > >There is no KBIND support in current HEAD. s/no/no longer/ Ando had me thinking I had already axed it. But it's now axed. Kurt

1 0

Re: (ITS#4799) kbind removal
by Kurt＠OpenLDAP.org 10 Jan '07

10 Jan '07

At 02:23 PM 1/9/2007, quanah(a)OpenLDAP.org wrote: >Full_Name: Quanah Gibson-Mount >Version: HEAD/2.4 >OS: NA >URL: ftp://ftp.openldap.org/incoming/ >Submission from: (NULL) (171.66.155.86) > > >kbind was slated for removal in 2.2, but was missed. Before 2.4 goes out, kbind >should be finally removed from HEAD & 2.4. There is no KBIND support in current HEAD. Kurt

1 0

Re: (ITS#4494) connections are not asynchrounous
by ando＠sys-net.it 10 Jan '07

10 Jan '07

Larry Morris wrote: > Your efforts are appreciated. > > Please see my additional responses inline below. > > My single-threaded application requires that multiple connection > attempts may be in-progress simultaneously, in conjunction with other > activities that need timely attention. In other words, I need to have > multiple connections in non-blocking SSL_connect() at the same time, > with the application doing select() on all the LDAP connection sockets > as needed. The fix you have provided will allow this? > No, at a first glance it's not going to have any impact on that portion of code. I'll try to sort out if and how anything similar can be done in that area. > What is the time-frame for this to be available in a "stable" version? > There's no definite timeframe. It's not going to appear in OpenLDAP 2.3, since it's feature frozen and this does not represent a significant bug fix, but rather a new, marginal feature. 2.4 is on its way, and this code will surely be in the next 2.4 release. Whether this will be still alpha or release, I have no idea right now. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. 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#4799) kbind removal
by quanah＠OpenLDAP.org 09 Jan '07

09 Jan '07

Full_Name: Quanah Gibson-Mount Version: HEAD/2.4 OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (171.66.155.86) kbind was slated for removal in 2.2, but was missed. Before 2.4 goes out, kbind should be finally removed from HEAD & 2.4.

1 0

Re: (ITS#4494) connections are not asynchrounous
by lrm＠interlinknetworks.com 09 Jan '07

09 Jan '07

Your efforts are appreciated. Please see my additional responses inline below. My single-threaded application requires that multiple connection attempts may be in-progress simultaneously, in conjunction with other activities that need timely attention. In other words, I need to have multiple connections in non-blocking SSL_connect() at the same time, with the application doing select() on all the LDAP connection sockets as needed. The fix you have provided will allow this? What is the time-frame for this to be available in a "stable" version? That's all for now, --Larry Morris Interlink Networks, LLC. lrm(a)interlinknetworks.com On Mon, 2007-01-08 at 08:39, Pierangelo Masarati wrote: > Is it an option for you to use Start TLS instead of ldaps? In this I could try using ldap_start_tls() as a quick-and-dirty test to verify that you have fixed the connection issues, but it is not acceptable for our production use. We must support LDAPv2, which does not allow the use of start TLS. Are you planning to support this for ldaps: URLs in the future? Do you need/want me to verify that using start TLS with your patches fixes the connection issues? I would prefer to hold off until the ldaps: support is in place. > case, code in right HEAD should fix all non-blocking issues, as soon as > you specify a network timeout and LDAP_OPT_CONNECT_ASYNC (undocumented > yet, it's been committed just hours ago). What is the "right HEAD" CVS branch? Do I have access to that branch via anonymous CVS? I am not very familiar with CVS, a sample command line to retrieve the correct sources would be quite helpful. > > The usage I suggest is to set LDAP_OPT_NETWORK_TIMEOUT to a positive > value; then set LDAP_OPT_CONNECT_ASYNC to TRUE before performing the > first operation, and reset it to FALSE after the first operation > succeeds. In your case, the first operation would be ldap_start_tls[_s](3). Can I leave LDAP_OPT_CONNECT_ASYNC set to TRUE always? I would like referrals, if used, to be non-blocking as well. Could you make this automatic in ldap_int_tls_start()?

1 0

Re: (ITS#4796) Contribution: JLDAP support for simple paging of results (RFC 2696)
by Kurt＠OpenLDAP.org 09 Jan '07

09 Jan '07

At 03:28 PM 1/6/2007, radovan(a)skolnik.info wrote: >Full_Name: Radovan Skolnik >Version: JLDAP CVS version >OS: Windows/Java >URL: http://www.skolnik.info/LDAPPagedResults.zip >Submission from: (NULL) (82.119.120.128) > > >Hello, > >I hope this is the right place to make this submission ;-) Recently I found that >JLDAP does not support simple paging mechanism via control as stated in RFC2696 >(control OID 1.2.840.113556.1.4.319). So I made an attempt to implement it and >it seems to me it works as it's supposed to. I would like to contribute it to >the project for the benefit of others. The files can be found at >http://www.skolnik.info/LDAPPagedResults.zip If there is something more needed >from me please let me know. Your submission lacks both a notice of origin and a rights statement, as required of contributions. See <http://www.openldap.org/devel/contributing.html#notice>. Though submissions such as this should be in the form of patch file (with notices placed above the patch in the file), a zip file is acceptable. In this case, just place the required notice and statement in a file called NOTICE. Please revise. -- Kurt

1 0

Re: (ITS#4797) back-bdb crashes during test34-translucent
by ando＠sys-net.it 08 Jan '07

08 Jan '07

ando(a)sys-net.it wrote: > Apparently, the cache lru is not initialized. Backtrace: > works for me, now. Thanks, p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. 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#4798) idassert mode=self doesn't proxyauthz for anonymous operations
by ando＠sys-net.it 08 Jan '07

08 Jan '07

Full_Name: Pierangelo Masarati Version: HEAD,re23 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando See <http://www.openldap.org/lists/openldap-software/200701/msg00062.html>. A fix is coming.

1 0

Re: (ITS#4783) ldap_sasl_bind() is not asynchronous
by ando＠sys-net.it 08 Jan '07

08 Jan '07

ando(a)sys-net.it wrote: > fcusack(a)fcusack.com wrote: >> But still you can do the bind async, and just close the fd on the client >> side on timeout. I don't see why connect() timeout can't be handled >> the same way. (ignoring the problem that there is no API call AFAICT >> to just drop the connection) >> > I'll note that there's been some interest in that area --- I loosely > have the same need (see > <http://www.openldap.org/lists/openldap-devel/200611/msg00000.html>) but > unfortunately it's not in my priority list, considering that it might > have relevant impact on the client library. Eventually, this got on top of my priority list, and it's now implemented in HEAD. One needs to: - set LDAP_OPT_NETWORK_TIMEOUT to a value greater than 0 - set LDAP_OPT_CONNECT_ASYNC to TRUE - perform the first operation asynchronously (e.g. ldap_sasl_bind(3)) the library call might return LDAP_X_CONNECTING if poll(2)'ing after connect(2) didn't succeed yet and LDAP_OPT_NETWORK_TIMEOUT didn't expire yet. In that case, the client should resubmit the request until it either succeeds or LDAP_OPT_NETWORK_TIMEOUT expires. Note that, right now, there's no means to set LDAP_OPT_CONNECT_ASYNC other than via ldap_set_option(3), and none is foreseen, because only specially crafted clients would be able to handle LDAP_X_CONNECTING appropriately. Please test. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. 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#4797) back-bdb crashes during test34-translucent
by ando＠sys-net.it 08 Jan '07

08 Jan '07

Full_Name: Pierangelo Masarati Version: HEAD OS: Linux SuSE 10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (131.175.154.35) Submitted by: ando Apparently, the cache lru is not initialized. Backtrace: masarati@xxx:~/yyy/ldap-devel/tests> gdb ../servers/slapd/slapd core.1900 GNU gdb 6.3 <snip> #0 0x00000000004f9e13 in bdb_cache_delete_internal (cache=0x817b50, e=0x8efbc0, decr=1) at cache.c:1240 1240 LRU_DEL( cache, e ); (gdb) bt #0 0x00000000004f9e13 in bdb_cache_delete_internal (cache=0x817b50, e=0x8efbc0, decr=1) at cache.c:1240 #1 0x00000000004f9bdf in bdb_cache_delete (bdb=0x817af0, e=0x8c5bf8, locker=2147483683, lock=0x41801820) at cache.c:1155 #2 0x00000000004fde8f in bdb_delete (op=0x8d94e0, rs=0x41801d50) at delete.c:520 #3 0x00000000004b0011 in overlay_op_walk (op=0x8d94e0, rs=0x41801d50, which=op_delete, oi=0x819310, on=0x0) at backover.c:507 #4 0x00000000004b0215 in over_op_func (op=0x8d94e0, rs=0x41801d50, which=op_delete) at backover.c:559 #5 0x00000000004b035f in over_op_delete (op=0x8d94e0, rs=0x41801d50) at backover.c:611 #6 0x00000000004580ca in fe_op_delete (op=0x8d94e0, rs=0x41801d50) at delete.c:180 #7 0x0000000000457cbc in do_delete (op=0x8d94e0, rs=0x41801d50) at delete.c:91 #8 0x0000000000438689 in connection_operation (ctx=0x41801e90, arg_v=0x8d94e0) at connection.c:1128 #9 0x0000000000438b6c in connection_read_thread (ctx=0x41801e90, argv=0xd) at connection.c:1256 #10 0x0000000000592587 in ldap_int_thread_pool_wrapper (xpool=0x7d99a0) at tpool.c:704 #11 0x00002aaaab0befa5 in start_thread () from /lib64/tls/libpthread.so.0 #12 0x00002aaaab28acb2 in clone () from /lib64/tls/libc.so.6 #13 0x0000000000000000 in ?? () <snip> (gdb) p cache[0] $1 = {c_eifree = 0x0, c_idtree = 0x8ebaa0, c_lruhead = 0x0, c_lrutail = 0x0, c_dntree = {bei_parent = 0x0, bei_id = 0, bei_lockpad = 0 '\0', bei_state = 128, bei_finders = 0, bei_nrdn = {bv_len = 0, bv_val = 0x0}, bei_e = 0x0, bei_kids = 0x8ec040, bei_kids_mutex = {__m_reserved = 0, __m_count = 0, __m_owner = 0x0, __m_kind = 0, __m_lock = {__status = 0, __spinlock = 0}}, bei_lrunext = 0x0, bei_lruprev = 0x0}, c_maxsize = 1000, c_cursize = 4, c_minfree = 1, c_eiused = 3, c_leaves = 1, c_purging = 0, c_locker = 6, c_rwlock = 0x817db0, c_lru_mutex = { __m_reserved = 1, __m_count = 0, __m_owner = 0x100000771, __m_kind = 0, __m_lock = {__status = 0, __spinlock = 0}}, c_count_mutex = { __m_reserved = 0, __m_count = 0, __m_owner = 0x0, __m_kind = 0, __m_lock = {__status = 0, __spinlock = 0}}, c_eifree_mutex = { __m_reserved = 0, __m_count = 0, __m_owner = 0x0, __m_kind = 0, __m_lock = {__status = 0, __spinlock = 0}}} (gdb) p e[0] $2 = {bei_parent = 0x8e2cc0, bei_id = 7, bei_lockpad = 0 '\0', bei_state = 139, bei_finders = 0, bei_nrdn = {bv_len = 11, bv_val = 0x8e26f0 "uid=someguy"}, bei_e = 0x8c5bf8, bei_kids = 0x0, bei_kids_mutex = {__m_reserved = 1, __m_count = 0, __m_owner = 0x100000771, __m_kind = 0, __m_lock = {__status = 0, __spinlock = 0}}, bei_lrunext = 0x0, bei_lruprev = 0x0}

1 0

Re: (ITS#4494) connections are not asynchrounous
by ando＠sys-net.it 08 Jan '07

08 Jan '07

lrm(a)interlinknetworks.com wrote: > I have already tried this. It does not have any affect on SSL connection > negotitation. > > There is a very interseting comment in the code which indicates someone was > aware of the problem. From the 2.3.20 source distribution, file > libraries/libldap/tls.c (line 1445): > > /* > * Fortunately, the lib uses blocking io... > */ > if ( ldap_int_tls_connect( ld, conn ) < 0 ) { > ld->ld_errno = LDAP_CONNECT_ERROR; > return (ld->ld_errno); > } > > And in ldap_int_tls_connect(), there is a call to SSL_connect( ssl ) that has no > provision for asynchronous operation. There is no setting of the non-blocking > option that I can find in this code sequence. > > > To reproduce the problem, simply point your ldaps: URL to a TCP server port that > accepts connections, and does nothing with them. The LDAP client will hang > forever (or until the server ephemeral port is closed). Is it an option for you to use Start TLS instead of ldaps? In this case, code in right HEAD should fix all non-blocking issues, as soon as you specify a network timeout and LDAP_OPT_CONNECT_ASYNC (undocumented yet, it's been committed just hours ago). The usage I suggest is to set LDAP_OPT_NETWORK_TIMEOUT to a positive value; then set LDAP_OPT_CONNECT_ASYNC to TRUE before performing the first operation, and reset it to FALSE after the first operation succeeds. In your case, the first operation would be ldap_start_tls[_s](3). p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. 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#4786) back-sql searching with dn attribute selected causes object class violation
by ando＠sys-net.it 08 Jan '07

08 Jan '07

robb(a)wtg.cw.com wrote: > Pierangelo Masarati wrote: >> In any case, since the behavior you report is very data and meta-data >> dependent, you don't provide enough info for debugging, and at a very >> first glance this is not indicative of a software bug. > > Pierangelo, > > the problem is indeed with the meta-data: > > the object at the root of the sql tree "dc=sql,dc=example,dc=org" was > defined purely as dcObject, it needs a structural objectClass in order > to be valid. > > If we define it as an organizationalUnit and dcObject (using > ldap_entry_objclasses) then all works as expected. > > Oddly doing the opposite doesn't seem to work. Because somewhere a constraint stepped in, which requires objectClasses in ldap_objectclasses to be structural; it makes sense, all in all. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. 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#4786) back-sql searching with dn attribute selected causes object class violation
by robb＠wtg.cw.com 08 Jan '07

08 Jan '07

Pierangelo Masarati wrote: > In any case, since the behavior you report is very data and meta-data > dependent, you don't provide enough info for debugging, and at a very > first glance this is not indicative of a software bug. Pierangelo, the problem is indeed with the meta-data: the object at the root of the sql tree "dc=sql,dc=example,dc=org" was defined purely as dcObject, it needs a structural objectClass in order to be valid. If we define it as an organizationalUnit and dcObject (using ldap_entry_objclasses) then all works as expected. Oddly doing the opposite doesn't seem to work. Many thanks, Rob -- Robert Brooks, Network Manager, Cable & Wireless UK <robb(a)wtg.cw.com> http://wtg.cw.com/ Tel: +44 (0)20 7339 8600 Fax: +44 (0)20 7339 8601 - "What was your username again?" - BOFH -

1 0

(ITS#4796) Contribution: JLDAP support for simple paging of results (RFC 2696)
by radovan＠skolnik.info 07 Jan '07

07 Jan '07

Full_Name: Radovan Skolnik Version: JLDAP CVS version OS: Windows/Java URL: http://www.skolnik.info/LDAPPagedResults.zip Submission from: (NULL) (82.119.120.128) Hello, I hope this is the right place to make this submission ;-) Recently I found that JLDAP does not support simple paging mechanism via control as stated in RFC2696 (control OID 1.2.840.113556.1.4.319). So I made an attempt to implement it and it seems to me it works as it's supposed to. I would like to contribute it to the project for the benefit of others. The files can be found at http://www.skolnik.info/LDAPPagedResults.zip If there is something more needed from me please let me know. Best regards Radovan Skolnik

1 0

Re: (ITS#4795) dsiallow bind_simple_unprotected
by hyc＠symas.com 30 Dec '06

30 Dec '06

hugo.monteiro(a)fct.unl.pt wrote: > Full_Name: Hugo Monteiro > Version: 2.3.27 > OS: GNU/Linux Debian Sarge > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (85.139.79.96) > > > Though it's been deprecated for a long time now, the documentation still referes > to dsiallow bind_simple_unprotected, leading people into mistake, and some > headaches. Hm, according to CVS, it was removed from the release man page slapd.conf(5) in 2.1.21, May 2003. There's certainly no trace of it in the 2.3.27 man page. Ah, it's still in the Admin Guide... You should be more specific next time. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

(ITS#4795) dsiallow bind_simple_unprotected
by hugo.monteiro＠fct.unl.pt 30 Dec '06

30 Dec '06

Full_Name: Hugo Monteiro Version: 2.3.27 OS: GNU/Linux Debian Sarge URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (85.139.79.96) Though it's been deprecated for a long time now, the documentation still referes to dsiallow bind_simple_unprotected, leading people into mistake, and some headaches. Keep up the good work. Cheers, Hugo Monteiro.

1 0

Re: (ITS#4786) back-sql searching with dn attribute selected causes object class violation
by ando＠sys-net.it 28 Dec '06

28 Dec '06

robb(a)wtg.cw.com wrote: > Full_Name: Robert Brooks > Version: 2.3.31 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (62.49.19.14) > > > an ldapsearch like this works > > ldapsearch -x -b "dc=sql,dc=example,dc=org" "cn=Robert Brooks" cn > > dn: uid=robb(a)example.org,dc=sql,dc=example,dc=org > cn: Robert Brooks > > # search result > search: 2 > result: 0 Success > > # numResponses: 2 > # numEntries: 1 > > however this does not: > > ldapsearch -x -b "dc=sql,dc=example,dc=org" "cn=Robert Brooks" dn cn > > # search result > search: 2 > result: 65 Object class violation > > # numResponses: > This is working just fine in HEAD/re23 (using the built-in test data): bash-3.00$ ../clients/tools/ldapsearch -x -H ldap://:9011 -b dc=example,dc=com -LLL cn=*mit* cn dn # refldap://localhost:9012/dc=example,dc=com??sub dn: cn=Mitya Kovalev,dc=example,dc=com cn: Mitya Kovalev That's why I suspect it's related to some issue (or inconsistency) within your data/metadata. Could you post more? p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. 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#4785) back-sql objectclass searches fail unless there is data in ldap_entry_objclasses
by ando＠sys-net.it 28 Dec '06

28 Dec '06

robb(a)wtg.cw.com wrote: > objectclass searches fail (with back-sql/mysql) if there is no data in the > ldap_entry_objclasses table. Just a simple dummy entry like this is enough to > fix the problem. > I see. A solution I see would be to use UNION to merge the results of a query with and one without the outer join to ldap_entry_objclasses. This, however, requires some extensive code manipulation, and likely would be much less efficient, so I believe the workaround of having one row in ldap_entry_objclasses is better. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. 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#4783) ldap_sasl_bind() is not asynchronous
by fcusack＠fcusack.com 28 Dec '06

28 Dec '06

On December 28, 2006 10:06:40 AM +0100 Pierangelo Masarati <ando(a)sys-net.it> wrote: > Frank Cusack wrote: >> >> Oh, in that case I am definitely missing a lot. Since my understanding >> of the timeout value passed to ldap_sasl_bind() is that it is a *bind* >> timeout, which I assumed would be because some artibrary SASL mechanism >> might take some arbitrarily long amount of time. If there is no bind >> timeout, then why is LDAP_OPT_NETWORK_TIMEOUT implemented? The timeout >> passed to ldap_sasl_bind() should just be the connect() timeout then. > ldap_sasl_bind() cannot be passed any timeout. What timeout are you > referring to? grrr ... I would have sworn there was a timeout arg! I must have confused it with ldap_search(). The Netscape API does not have a timeout arg either. I'd implemented my thread wrapper (w/ timeout) before I learned of the LDAP_OPT_NETWORK_TIMEOUT option (LDAP_X_OPT_CONNECT_TIMEOUT for Netscape API). I guess when I found that option, I falsely remembered that ldap_sasl_bind_s() had a timeout arg. > I must disagree with the above. As far as I understand. > LDAP_OPT_NETWORK_TIMEOUT does what you expect: it makes connect() time > out as required. ldap_sasl_bind() should return as soon as the packet > with the request has been sent, and the rest of the timeout policy for > the bind only part should be dealt with by the client using the > ldap_result() timeout arg as appropriate. I've recently tested that > behavior for customers who wanted some certain timelimit on all > operations, not just searches, and that required some extensive > modifications to the proxy backends, but the client library (libldap) was > not touched at all. In that case, the code basically uses > ldap_sasl_bind() to wrap simple binds (that's what the proxy backends > mostly do), and using LDAP_OPT_NETWORK_TIMEOUT makes it work as expected. > I can't speak for truly SASL bind as I didn't experiment timeouts with > that. Sounds right. In the case of a truly SASL bind where there might be a long delay, async ldap_sasl_bind() should be enough. Thanks for your patience. -frank

1 0

(ITS#4794) Value return filters leak
by ando＠sys-net.it 28 Dec '06

28 Dec '06

Full_Name: Pierangelo Masarati Version: HEAD,re23 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (87.28.220.33) Members of the vrf list are malloc'ed on the heap but freed as if in the thread's slab.

1 0

Re: (ITS#4783) ldap_sasl_bind() is not asynchronous
by ando＠sys-net.it 28 Dec '06

28 Dec '06

Frank Cusack wrote: > > Oh, in that case I am definitely missing a lot. Since my understanding > of the timeout value passed to ldap_sasl_bind() is that it is a *bind* > timeout, which I assumed would be because some artibrary SASL mechanism > might take some arbitrarily long amount of time. If there is no bind > timeout, then why is LDAP_OPT_NETWORK_TIMEOUT implemented? The timeout > passed to ldap_sasl_bind() should just be the connect() timeout then. ldap_sasl_bind() cannot be passed any timeout. What timeout are you referring to? >> ldap_initialize() doesn't actually establish any connection, >> it just sets up the handler, and the connection is established by the >> first operation that requires it. the asynchronous bind, muck like any >> other asynchronous operation, simply returns after sending the packet(s) >> containing the request. > > That much I do understand. (Although I thought the async bind() > functions > weren't actually implemented async.) They are. > >> But, of course, the first of them requires the >> connection to be established, and that's where LDAP_OPT_NETWORK_TIMEOUT >> comes into play. Doing a really asynchronous connect() implies >> returning >> some sort of LDAP_X_INPROGRESS, keeping track of the status of the >> connection and polling it for response for each subsequent call until >> the >> connection is established before actually sending any request. In this >> sense the change should be intrusive: in this design, client code should >> be able to handle the LDAP_X_INPROGRESS return code and resubmit the >> request until the connection is ready. A "smarter" design would cache >> the request, poll for connect() response during calls to ldap_result(), >> and submit the actual request when the connection is established. > > Sure, I understand that also (now). > > What I'm saying is that most folks probably don't really need an async > connect(), they just need a non-blocking one that returns in some known > amount of time. LDAP_OPT_NETWORK_TIMEOUT doesn't do that, since it > only controls the connect() part, and not the subsequent bind (important > since you can only get to connect() via the ldap_bind() or other > calls, ie > there is no ldap_connect() and ldap_open() is deprecated). But a new > LDAP_OPT_CONNECT_BIND_TIMEOUT option could do it. I must disagree with the above. As far as I understand. LDAP_OPT_NETWORK_TIMEOUT does what you expect: it makes connect() time out as required. ldap_sasl_bind() should return as soon as the packet with the request has been sent, and the rest of the timeout policy for the bind only part should be dealt with by the client using the ldap_result() timeout arg as appropriate. I've recently tested that behavior for customers who wanted some certain timelimit on all operations, not just searches, and that required some extensive modifications to the proxy backends, but the client library (libldap) was not touched at all. In that case, the code basically uses ldap_sasl_bind() to wrap simple binds (that's what the proxy backends mostly do), and using LDAP_OPT_NETWORK_TIMEOUT makes it work as expected. I can't speak for truly SASL bind as I didn't experiment timeouts with that. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. 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#4783) ldap_sasl_bind() is not asynchronous
by fcusack＠fcusack.com 28 Dec '06

28 Dec '06

On December 28, 2006 9:34:36 AM +0100 Pierangelo Masarati <ando(a)sys-net.it> wrote: > fcusack(a)fcusack.com wrote: >> I did find LDAP_OPT_NETWORK_TIMEOUT, which I didn't try, but which is >> close to the desired functionality. AFAICT it implements a *separate* >> timeout for the connect() (and maybe unbind/close()?) part of an ldap >> connection. Why someone would want to distinguish between connect() >> and bind I don't know, especially when they don't get feedback about >> how long connect() took. >> >> It should be easy (?) to add something like LDAP_OPT_CONNECT_BIND_TIMEOUT >> which would be the total time for connect() and bind, given that >> non-blocking connect() is already implemented. That would probably >> solve a lot of folk's need for a working async bind. >> >> > I think you're missing a point: there's no bind timeout because there's > no need for it. The delay (or the hang) you likely see when dong > ldap_sasl_bind() is actually spent doing a connect() to establish a > connection. Oh, in that case I am definitely missing a lot. Since my understanding of the timeout value passed to ldap_sasl_bind() is that it is a *bind* timeout, which I assumed would be because some artibrary SASL mechanism might take some arbitrarily long amount of time. If there is no bind timeout, then why is LDAP_OPT_NETWORK_TIMEOUT implemented? The timeout passed to ldap_sasl_bind() should just be the connect() timeout then. > ldap_initialize() doesn't actually establish any connection, > it just sets up the handler, and the connection is established by the > first operation that requires it. the asynchronous bind, muck like any > other asynchronous operation, simply returns after sending the packet(s) > containing the request. That much I do understand. (Although I thought the async bind() functions weren't actually implemented async.) > But, of course, the first of them requires the > connection to be established, and that's where LDAP_OPT_NETWORK_TIMEOUT > comes into play. Doing a really asynchronous connect() implies returning > some sort of LDAP_X_INPROGRESS, keeping track of the status of the > connection and polling it for response for each subsequent call until the > connection is established before actually sending any request. In this > sense the change should be intrusive: in this design, client code should > be able to handle the LDAP_X_INPROGRESS return code and resubmit the > request until the connection is ready. A "smarter" design would cache > the request, poll for connect() response during calls to ldap_result(), > and submit the actual request when the connection is established. Sure, I understand that also (now). What I'm saying is that most folks probably don't really need an async connect(), they just need a non-blocking one that returns in some known amount of time. LDAP_OPT_NETWORK_TIMEOUT doesn't do that, since it only controls the connect() part, and not the subsequent bind (important since you can only get to connect() via the ldap_bind() or other calls, ie there is no ldap_connect() and ldap_open() is deprecated). But a new LDAP_OPT_CONNECT_BIND_TIMEOUT option could do it. -frank

1 0

Re: (ITS#4783) ldap_sasl_bind() is not asynchronous
by ando＠sys-net.it 28 Dec '06

28 Dec '06

fcusack(a)fcusack.com wrote: > Unfortunately I won't be able to contribute a patch as I've worked > around it in my application (I created a separate thread to handle > the ldap connect) so I can't afford to invest the time. Plus I needed > a solution that would work with the Netscape API as well as OpenLDAP. > > I did find LDAP_OPT_NETWORK_TIMEOUT, which I didn't try, but which is > close to the desired functionality. AFAICT it implements a *separate* > timeout for the connect() (and maybe unbind/close()?) part of an ldap > connection. Why someone would want to distinguish between connect() > and bind I don't know, especially when they don't get feedback about > how long connect() took. > > It should be easy (?) to add something like LDAP_OPT_CONNECT_BIND_TIMEOUT > which would be the total time for connect() and bind, given that > non-blocking connect() is already implemented. That would probably > solve a lot of folk's need for a working async bind. > > I think you're missing a point: there's no bind timeout because there's no need for it. The delay (or the hang) you likely see when dong ldap_sasl_bind() is actually spent doing a connect() to establish a connection. ldap_initialize() doesn't actually establish any connection, it just sets up the handler, and the connection is established by the first operation that requires it. the asynchronous bind, muck like any other asynchronous operation, simply returns after sending the packet(s) containing the request. But, of course, the first of them requires the connection to be established, and that's where LDAP_OPT_NETWORK_TIMEOUT comes into play. Doing a really asynchronous connect() implies returning some sort of LDAP_X_INPROGRESS, keeping track of the status of the connection and polling it for response for each subsequent call until the connection is established before actually sending any request. In this sense the change should be intrusive: in this design, client code should be able to handle the LDAP_X_INPROGRESS return code and resubmit the request until the connection is ready. A "smarter" design would cache the request, poll for connect() response during calls to ldap_result(), and submit the actual request when the connection is established. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. 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#4783) ldap_sasl_bind() is not asynchronous
by fcusack＠fcusack.com 28 Dec '06

28 Dec '06

On December 22, 2006 10:56:40 AM +0100 Pierangelo Masarati <ando(a)sys-net.it> wrote: > fcusack(a)fcusack.com wrote: >> But still you can do the bind async, and just close the fd on the client >> side on timeout. I don't see why connect() timeout can't be handled >> the same way. (ignoring the problem that there is no API call AFAICT >> to just drop the connection) >> > I'll note that there's been some interest in that area --- I loosely have > the same need (see > <http://www.openldap.org/lists/openldap-devel/200611/msg00000.html>) but > unfortunately it's not in my priority list, considering that it might > have relevant impact on the client library. Unfortunately I won't be able to contribute a patch as I've worked around it in my application (I created a separate thread to handle the ldap connect) so I can't afford to invest the time. Plus I needed a solution that would work with the Netscape API as well as OpenLDAP. I did find LDAP_OPT_NETWORK_TIMEOUT, which I didn't try, but which is close to the desired functionality. AFAICT it implements a *separate* timeout for the connect() (and maybe unbind/close()?) part of an ldap connection. Why someone would want to distinguish between connect() and bind I don't know, especially when they don't get feedback about how long connect() took. It should be easy (?) to add something like LDAP_OPT_CONNECT_BIND_TIMEOUT which would be the total time for connect() and bind, given that non-blocking connect() is already implemented. That would probably solve a lot of folk's need for a working async bind. -frank

1 0

(ITS#4793) connection_get race condition on Windows
by hyc＠OpenLDAP.org 27 Dec '06

27 Dec '06

Full_Name: Howard Chu Version: HEAD OS: Windows XP URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.168.84.21) Submitted by: hyc test039 was consistently failing in an assert() in slapd_set_read() called from connection_read(). The problem was that connection_get() was returning a connection structure that got closed and immediately reused. The problem may also be in RE23 since they're using the same connection manager now, but I haven't built RE23 on Windows recently to verify.

1 0

Re: (ITS#4791) privileged connections handling in proxy backends
by hyc＠symas.com 26 Dec '06

26 Dec '06

hyc(a)symas.com wrote: > ando(a)sys-net.it wrote: > >> The patch is coming. > > Something's missing... My fault, sorry. Had an old back-ldap.h. Builds fine now. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4791) privileged connections handling in proxy backends
by hyc＠symas.com 26 Dec '06

26 Dec '06

ando(a)sys-net.it wrote: > The patch is coming. Something's missing... gcc -g -O2 -I../../../include -I../../../../head/include -I.. -I../../../../head/servers/slapd/back-ldap/.. -I/usr/local/include -I/usr/local/BerkeleyDB.4.2/include -c ../../../../head/servers/slapd/back-ldap/config.c -o config.o ../../../../head/servers/slapd/back-ldap/config.c: In function `slap_idassert_authzfrom_parse': ../../../../head/servers/slapd/back-ldap/config.c:567: error: `LDAP_BACK_AUTH_AUTHZ_ALL' undeclared (first use in this function) ../../../../head/servers/slapd/back-ldap/config.c:567: error: (Each undeclared identifier is reported only once ../../../../head/servers/slapd/back-ldap/config.c:567: error: for each function it appears in.) -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: ITS#3707 filters
by hyc＠symas.com 25 Dec '06

25 Dec '06

hyc(a)symas.com wrote: > hyc(a)symas.com wrote: >> I've had a patch for the Filter handling sitting here half-finished for >> quite a while. The intent is to preserve all of the original filter data >> so that it can be reused directly. > > This is now in HEAD. I haven't yet caught all the cases in get_ssa or > get_mra that drop the info when validation fails, but otherwise it's > usable. Instead of using the distinct SLAPD_FILTER_COMPUTED type for > filter components with unknown attributes, it now ORs the > SLAPD_FILTER_UNDEFINED flag onto the existing filter choice. This way > the original filter structure can be preserved. back-ldap's filter munging strategy still needs to be adapted to the new code. Probably it shouldn't use the filterstr at all. Any filter component with an unknown attribute is now logged with a '?' prefix, e.g. "(foo=a*b)" becomes "(?foo=a*b)". -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: ITS#3707 filters
by hyc＠symas.com 25 Dec '06

25 Dec '06

hyc(a)symas.com wrote: > I've had a patch for the Filter handling sitting here half-finished for > quite a while. The intent is to preserve all of the original filter data > so that it can be reused directly. This is now in HEAD. I haven't yet caught all the cases in get_ssa or get_mra that drop the info when validation fails, but otherwise it's usable. Instead of using the distinct SLAPD_FILTER_COMPUTED type for filter components with unknown attributes, it now ORs the SLAPD_FILTER_UNDEFINED flag onto the existing filter choice. This way the original filter structure can be preserved. > On a related note, RFC4511 changes the behavior of presence matching on > unknown attributes to be Undefined now instead of FALSE. So presumably > we should update our code accordingly. This is now in HEAD as well. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

(ITS#4792) not able to install Slapd i.e. when I install openldap it does'nt install server module
by azia＠techxact.com 25 Dec '06

25 Dec '06

Full_Name: Ahmad Zia Version: openldap-2.3.31 OS: Redhat ES 4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (80.227.142.2) I have successfully compiled, make openldad but when I get to the point where I have to run "make test" it says cannot connect to the openldap server after timing out. When I use this command , I get the following: [root@TXDXB openldap]# rpm -qa | grep openldap openldap-devel-2.2.13-6.4E openldap-2.2.13-6.4E openldap-clients-2.2.13-6.4E its not listing openldap-server-2.2.13-6.4E and in my /etc/openldap directory I only have ldap.conf and I do not have slapd.conf, so what I gather so far is that I am not able to install the server module. I have used the parameter --enable-slapd with ./configure command but its still the same thing. Can you please tell me what am I doing wrong

1 0

Re: (ITS#4790) re23 hangs during shutdown after test033
by hyc＠symas.com 24 Dec '06

24 Dec '06

---- <ando(a)sys-net.it> wrote: > > Full_Name: Pierangelo Masarati > Version: re23 (2.3.31) > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (87.28.220.33) > > > Apparently, one thread is unable to terminate correctly, so the test succeeds, > but then slapd hangs forever in ldap_pvt_thread_pool_destroy(). I couldn't > investigate this in depth right now, but I could easily reproduce it on two > different systems (different kernels and so), so I'm positive I can easily > reproduce it. This is a bad patch to connections_shutdown in RE23, there is a "continue" after checking for a client session that shouldn't be there. This line is not present in HEAD and the bug doesn't exist in HEAD. Strange that it got there since we just recently sync'd RE23 with HEAD's connection.c. -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support

1 0

(ITS#4791) privileged connections handling in proxy backends
by ando＠sys-net.it 24 Dec '06

24 Dec '06

Full_Name: Pierangelo Masarati Version: HEAD OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (87.28.220.33) Submitted by: ando Privileged connections, under special circumstances, are cached and shared among client-side connections. This may result in very heavy traffic between the proxy and the remote server(s) on a single connection. As a consequence, multiple issues may arise: - heavy contention on the handler's resources - requests limitation at the remote server side on a single connection (this occurs if the remote server is OpenLDAP, but other implementations may follow similar design) - bottelneck whenever the shared connection needs be regenerated, i.e. because it expires (conn-ttl) As a workaround, a pool of privileged connections is proposed. A fixed maximum side pool is deisgned, so that whenever a privileged connection is requested, the related list of connections is walked looking for an idle one (refcnt == 0). If found, it's moved to the tail, to provide a simple round-robin mech to avoid reusing the same connections. If none is found, a new connection is generated, if use-temporary-conn is set to yes or the size limit is not reached, or the thread idles waiting for one to become available. If a new connection is created and there's room for it in the list, it's appended. Tests show a clear benefit on Linux when binding through back-ldap, since this nicely works around the bottleneck created by sharing the bind connection when operations are always proxied authz, to save network resources. Another benefit is represented by a clear smoothing of the response rates. Previously, frequent transients would occur, giving uneven response rates over time, while right now steady rates under steady conditions are observed. The patch is coming. p.

1 0

(ITS#4790) re23 hangs during shutdown after test033
by ando＠sys-net.it 24 Dec '06

24 Dec '06

Full_Name: Pierangelo Masarati Version: re23 (2.3.31) OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (87.28.220.33) Apparently, one thread is unable to terminate correctly, so the test succeeds, but then slapd hangs forever in ldap_pvt_thread_pool_destroy(). I couldn't investigate this in depth right now, but I could easily reproduce it on two different systems (different kernels and so), so I'm positive I can easily reproduce it. p.

1 0

Re: (ITS#4789) can't add BDB database when monitoring
by ando＠sys-net.it 24 Dec '06

24 Dec '06

hyc(a)symas.com wrote: > hyc(a)OpenLDAP.org wrote: > > >> I presume there's some kind of callback for registering new suffixes but I >> haven't looked very hard. >> > > This highlights some other issues lurking in here - back-monitor > basically doesn't deal with dynamic configuration well at all. It > assumes that all databases and overlays have been fully configured by > the time it starts - an assumption that was valid for old-style > slapd.conf use, but not with back-config. > > The monitor_subsys_database_init_one() function probably needs to be > split into separate pieces so that database and overlay info can be set > up and removed incrementally. > The point is that back-monitor has no clean means to detect what database is serving what naming context, since it was designed way ahead of back-config. So when time came to introduce monitor customization, the best mechanism I could find was the extended filter on the naming context. This is really creating trouble. The best solution would be to re-design back-monitor so that the database section mimics back-config using X-ORDERED 'SIBLING' style (and is updated accordingly, especially when entry renaming will be supported by back-config). The X-ORDERED 'SIBLING' could be used throughout back-monitor, to get rid of those "cn=Database X", "cn=Overlay Y" stuff and so. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. 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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs