- openldap-bugs - openldap.org

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

10 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 09 Jan '07

09 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 09 Jan '07

09 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 09 Jan '07

09 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 09 Jan '07

09 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 08 Jan '07

08 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 06 Jan '07

06 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 29 Dec '06

29 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 29 Dec '06

29 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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs