openldap-bugs

openldap-bugs@openldap.org

1 participants
20960 discussions

Re: (ITS#5919) URI syntaxe (ldap:///dc=my%2cdc=domaine)
by ando＠sys-net.it 09 Feb '09

09 Feb '09

philippe.eychart(a)informatique.gov.pf wrote: > michael(a)stroeder.com wrote: >> Such an extension would be feasible. But still I'm not sure whether this >> distinction is needed. Although LDAP URL with empty hostport portion are >> used internally (e.g. in ACLs) this IMHO does not affect >> ldap_initialize(). Maybe I missed something. But before implementing a >> patch this should be clarified. > > Do you suggest that an empty hostport (as ldap_initialize() arg) could mean > that a SRV search is needed ? > But this will reduce the search in the default domain name, won't it ? > So, how to produce a search in another specific domain name when wished ? > Where (in the URI) to appoint the root ("dc=my,dc=domain") or the explicit > domain name ("my.domain") for the search domain ?... > > Secondarily, how to specify the present meaning "this LDAP server" if we use > this empty hostport syntaxe for SRV seach ? (A SRV search could respond when > the user think to request his local LDAP server ...) OpenLDAP clients do the following: empty hostport, empty DN: localhost, default port empty hostport, non-empty DN: SRV what might be missing IMHO is: use domain to specify SRV however, I don't see any special need for it, as domain can always be put in DN form. I don't know if there's need for a form that asks to use SRV to discover the server for the default SUFFIX. In order to avoid issues, I recommend using something like x-dnssrv={<domain>|<DN>} where <DN> is restricted to the domain component sequence form. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

RE: (ITS#5919) URI syntaxe (ldap:///dc=my%2cdc=domaine)
by philippe.eychart＠informatique.gov.pf 09 Feb '09

09 Feb '09

michael(a)stroeder.com wrote: > Such an extension would be feasible. But still I'm not sure whether this > distinction is needed. Although LDAP URL with empty hostport portion are > used internally (e.g. in ACLs) this IMHO does not affect > ldap_initialize(). Maybe I missed something. But before implementing a > patch this should be clarified. Do you suggest that an empty hostport (as ldap_initialize() arg) could mean that a SRV search is needed ? But this will reduce the search in the default domain name, won't it ? So, how to produce a search in another specific domain name when wished ? Where (in the URI) to appoint the root ("dc=my,dc=domain") or the explicit domain name ("my.domain") for the search domain ?... Secondarily, how to specify the present meaning "this LDAP server" if we use this empty hostport syntaxe for SRV seach ? (A SRV search could respond when the user think to request his local LDAP server ...) --- PE

1 0

(ITS#5935) segfault in syncrepl.c when replacing olcSyncrepl values by syncrepl on cn=config
by jclarke＠linagora.com 09 Feb '09

09 Feb '09

Full_Name: Jonathan Clarke Version: RE24 OS: CentOS 5.2 x64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (213.41.243.192) Hi all, We have encountered a segfault that occurs in syncrepl.c, on line 1449 (from a checkout of RE24 today). This occurs during replication of cn=config, by a thread in do_syncrepl on rid=999. Syncrepl pulls in new values for olcSyncRepl on cn=config. This deletes the configuration for rid=999, and adds configuration for rid=001 and rid=002. Some debugging (lots) showed the following. This thread enters syncrepl_config() 3 times: 1) Delete rid=999. This detects this syncrepl is running, and sets si->si_ctype = 0 (as described in the comments in syncrepl.c line 4358). si is not freed, since it's running. The c->be->be_syncinfo->si_cookieState is freed (line 4564). 2) Add rid=001 3) Add rid=002 Back in syncrepl.c on line 1449, the "final delete cleanup" looks for it's own si in be->be_syncinfo. It of course doesn't find it (the config is deleted), and segfaults when sip = null. We have tried changing these lines to: for ( sip = &be->be_syncinfo; sip != NULL || *sip != si; sip = &(*sip)->si_next ); if (sip) { *sip = si->si_next; } However, we then encounter another segfault on line 1448, involving be->be_syncinfo->si_cookieState, which was freed... It's a bit too much for us at this point, do you have any more ideas?

1 0

(ITS#5934) NULL pointer usage in ldap_new_connection(), causes segmentation fault
by bplank＠gta.com 09 Feb '09

09 Feb '09

Full_Name: Brad Plank Version: 2.4.13 OS: FreeBSD URL: ftp://ftp.openldap.org/incoming/brad-plank-090209.patch Submission from: (NULL) (199.120.225.110) NULL pointer usage in: LDAPConn * ldap_new_connection( LDAP *ld, LDAPURLDesc **srvlist, int use_ldsb, int connect, LDAPreqinfo *bind ) ... if ( lc->lconn_server->lud_exts ) { ... The below patch is to fix this issue, since the pointer "lconn_server" should only be used when "connect" is non-zero: ================================================================== --- libraries/libldap/request.c.orig 2008-11-07 20:15:17.000000000 -0500 +++ libraries/libldap/request.c 2009-02-09 11:01:56.000000000 -0500 @@ -452,9 +452,9 @@ ldap_new_connection( LDAP *ld, LDAPURLDe ldap_pvt_thread_mutex_unlock( &ld->ld_conn_mutex ); #endif - if ( lc->lconn_server->lud_exts ) { -#ifdef HAVE_TLS if ( connect ) { +#ifdef HAVE_TLS + if ( lc->lconn_server->lud_exts ) { int rc, ext = find_tls_ext( lc->lconn_server ); if ( ext ) { LDAPConn *savedefconn; ================================================================== I, Brad Plank, 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.

1 0

Re: (ITS#5931) back-meta crashes with syncrepl data
by ali.pouya＠free.fr 09 Feb '09

09 Feb '09

Yes, I confirm that now the slapd from HEAD simply ignores the intermediate response type. So I can go forward on my projet :-) In this project I do not bother about the contextCSN of my replica because it is managed by another master. Thanks a lot for this rapid fix. Best Regards Ali Selon Pierangelo Masarati <ando(a)sys-net.it>: > Slapd in HEAD no longer crashes when receiving intermediate response. > It rather complains about an unsupported response message. I'm now > working at correctly handling it. > > p.

1 0

Re: (ITS#5930) Problem while making the build
by quanah＠zimbra.com 09 Feb '09

09 Feb '09

--On Monday, February 09, 2009 7:44 AM +0000 bhupi.iit(a)gmail.com wrote: > Full_Name: Bhupinder > Version: 2.4.11 > OS: Solaris SunOS.5 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (149.77.167.165) > > > setenv LD_LIBRARY_PATH /usr/local/BerkeleyDB/lib > setenv CPPFLAGS -I/usr/local/BerkeleyDB/include/ > > ./configure > make depend > make > > while 'mak'ing i get the following error. > .. > .. > .. > /bin/sh ../..//libtool --mode=compile cc -g -I../../include > -I../../include -I/usr/local/BerkeleyDB/include/ -DLDAP_LIBRARY -c > tls.c cc -g -I../../include -I../../include > -I/usr/local/BerkeleyDB/include/ -DLDAP_LIBRARY -c tls.c -KPIC -DPIC -o > .libs/tls.o > "tls.c", line 102: syntax error before or at: gnutls_kx_algorithm_t > "tls.c", line 112: syntax error before or at: typedef > "tls.c", line 114: syntax error before or at: > gnutls_certificate_credentials_t "tls.c", line 127: syntax error before > or at: typedef > "tls.c", line 128: syntax error before or at: tls_ctx > "tls.c", line 189: member cannot be function: ldap_pvt_tls_ctx_free > "tls.c", line 189: warning: syntax requires ";" after last struct/union > member "tls.c", line 189: syntax error before or at: { > "tls.c", line 191: syntax error before or at: tls_ctx > "tls.c", line 211: member cannot be function: tls_ctx_new > "tls.c", line 211: warning: syntax requires ";" after last struct/union > member "tls.c", line 211: syntax error before or at: { > "tls.c", line 230: syntax error before or at: * > "tls.c", line 231: member cannot be function: tls_ctx_ref > "tls.c", line 231: warning: syntax requires ";" after last struct/union > member "tls.c", line 242: warning: syntax requires ";" after last > struct/union member "tls.c", line 262: warning: syntax requires ";" after > last struct/union member "tls.c", line 275: syntax error before or at: * > "tls.c", line 276: member cannot be function: tls_session_free > "tls.c", line 276: warning: syntax requires ";" after last struct/union > member "tls.c", line 285: syntax error before or at: * > "tls.c", line 285: warning: undefined or missing type for: char > "tls.c", line 286: member cannot be function: tls_parse_ciphers > "tls.c", line 286: warning: syntax requires ";" after last struct/union > member "tls.c", line 289: warning: syntax requires ";" after last > struct/union member "tls.c", line 289: syntax error before or at: = > "tls.c", line 292: syntax error before or at: num > "tls.c", line 314: warning: syntax requires ";" after last struct/union > member "tls.c", line 350: zero-sized struct/union > "tls.c", line 352: warning: old-style declaration or incorrect type for: > ptr "tls.c", line 352: warning: old-style declaration or incorrect type > for: len "tls.c", line 352: warning: syntax error: empty declaration > "tls.c", line 353: warning: old-style declaration or incorrect type for: > end "tls.c", line 354: undefined symbol: nkx > "tls.c", line 354: can not declare variably modified type at file scope > "tls.c", line 354: warning: old-style declaration or incorrect type for: > kx "tls.c", line 354: warning: {}-enclosed initializer required > "tls.c", line 354: too many array initializers > "tls.c", line 354: warning: variable length array can not be initialized: > kx "tls.c", line 355: undefined symbol: ncipher > "tls.c", line 355: can not declare variably modified type at file scope > "tls.c", line 355: warning: old-style declaration or incorrect type for: > cipher "tls.c", line 355: warning: {}-enclosed initializer required > "tls.c", line 355: too many array initializers > "tls.c", line 355: warning: variable length array can not be initialized: > cipher > "tls.c", line 356: undefined symbol: nmac > "tls.c", line 356: can not declare variably modified type at file scope > "tls.c", line 356: warning: old-style declaration or incorrect type for: > mac "tls.c", line 356: warning: {}-enclosed initializer required > "tls.c", line 356: too many array initializers > "tls.c", line 356: warning: variable length array can not be initialized: > mac "tls.c", line 357: warning: old-style declaration or incorrect type > for: ctx "tls.c", line 357: syntax error before or at: -> > "tls.c", line 357: warning: old-style declaration or incorrect type for: > kx_list > "tls.c", line 357: warning: improper pointer/integer combination: op "=" > "tls.c", line 358: warning: old-style declaration or incorrect type for: > ctx "tls.c", line 358: syntax error before or at: -> > "tls.c", line 358: warning: old-style declaration or incorrect type for: > cipher_list > "tls.c", line 358: warning: improper pointer/integer combination: op "=" > "tls.c", line 359: warning: old-style declaration or incorrect type for: > ctx "tls.c", line 359: syntax error before or at: -> > "tls.c", line 359: warning: old-style declaration or incorrect type for: > mac_list > "tls.c", line 359: warning: improper pointer/integer combination: op "=" > "tls.c", line 360: syntax error before or at: return > "tls.c", line 360: warning: syntax error: empty declaration > "tls.c", line 532: cannot recover from previous errors > cc: acomp failed for tls.c > make[2]: *** [tls.lo] Error 1 > make[2]: Leaving directory `~openldap/openldap-2.4.11/libraries/libldap' > make[1]: *** [all-common] Error 1 > make[1]: Leaving directory `~/openldap/openldap-2.4.11/libraries' > make: *** [all-common] Error 1 > > > > Please let me know if i'm doing something wrong here. Looks like it can't find your GnuTLS headers/libs, at a guess. In any case, this isn't an OpenLDAP bug. Please use openldap-software for further help with building OpenLDAP. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5931) back-meta crashes with syncrepl data
by ando＠sys-net.it 09 Feb '09

09 Feb '09

ando(a)sys-net.it wrote: > Slapd in HEAD no longer crashes when receiving intermediate response. > It rather complains about an unsupported response message. I'm now > working at correctly handling it. This won't probably be as easy as I expected: back-meta does not check, parse or return entry controls. This needs to be fixed as well. I notice that back-ldap and back-meta use ldap_first_entry() to parse the entry. Syncrepl client-side code uses a ldap_get_entry_controls() and explicit entry parsing. Probably we need to abstract what syncrepl does in a new libldap call that parses an entry and its controls, and use it as appropriate. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Need bug list for openldap-2.2.24 release.
by kalyan tej 09 Feb '09

09 Feb '09

Hi Folks, I am new to openldap ,I'd like to know the list of software bugs in openldap-2.2.24 release. I chose openldap-2.2.24 because my libc version is 2.3.3.It would be of great help to me if someone can provide me with the major list of bugs in the mentioned release and/or fixes . Thanks in advance, -Kalyan Tej

2 1

Re: (ITS#5931) back-meta crashes with syncrepl data
by ando＠sys-net.it 09 Feb '09

09 Feb '09

Slapd in HEAD no longer crashes when receiving intermediate response. It rather complains about an unsupported response message. I'm now working at correctly handling it. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5931) back-meta crashes with syncrepl data
by ando＠sys-net.it 09 Feb '09

09 Feb '09

ali.pouya(a)free.fr wrote: > I try to connect a RefreshAndPersist syncrepl client to a sync provider slapd > through an intermediate back-meta slapd in order tu use its RWM features. > The search entries are propagated without problem. But back-meta crashes each > time it receives the LDAP_RES_INTERMEDIATE response time from the sync provider > reproducing the following message : > > read1msg: ld 0x9f29550 msgid 2 message type intermediate > slapd: search.c:1460: meta_back_search: Assertion `0' failed. > Abandon Back-beta (and probably back-ldap) need to be able to recognize intermediate response messages, as they are part of the protocol. Probably, it would be a good idea to detect unrecognized response messages and handle them nicely. > I think this would be a useful feature to be able to make replicas that are > different from the master. > May be if this response time is propagated as is this type of synchronization > will be possible ? I'd notice that this type of operation might be less than ideal, since a proxied refreshAndPersist operation will keep one thread of the proxy busy all times waiting for further responses. > I am aware that connection to more thant one targets through back-meta may be > meaningless. In that case you could use back-ldap with slapo-rwm. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs