openldap-bugs

openldap-bugs@openldap.org

1 participants
21517 discussions

(ITS#5967) build failure with openssl : error: structure has no member named `ldo_tls_crlcheck'
by adrien.futschik＠atosorigin.com 21 Feb '09

21 Feb '09

Full_Name: Adrien Futschik Version: 2.4.14 OS: RHEL 4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (78.225.168.82) I am trying to build OpenLDAP 2.4.14 with BDB 4.7.25 (+ 3 Oracle patches) and OpenSSL 0.9.8j. Here are my build options : ./configure --prefix=/logiciels/openldap/old_2.4.14 --bindir=/logiciels/openldap/old_2.4.14/bin --sbindir=/logiciels/openldap/old_2.4.14/bin --libexecdir=/logiciels/openldap/old_2.4.14/bin --datadir=/appli/projects/default/openldap_2.4.14 --sysconfdir=/logiciels/openldap/old_2.4.14/conf --localstatedir=/var/projects/default/openldap_2.4.14 --includedir=/logiciels/openldap/old_2.4.14/include --with-tls=openssl --enable-debug --enable-local --enable-slapd --enable-modules --enable-bdb --enable-monitor --enable-shared --enable-ppolicy=mod --enable-static --disable-syslog --disable-ipv6 --disable-cleartext Here is the error message I am getting : gcc -O3 -march=i686 -m32 -I../../include -I../../include -I/logiciels/openldap/old_2.4.14/lib/db-4.7.25/include -I/logiciels/openldap/old_2.4.14/lib/openssl-0.9.8i/include/openssl -DLDAP_LIBRARY -c tls2.c-fPIC -DPIC -o .libs/tls2.o tls2.c: In function `ldap_pvt_tls_get_option': tls2.c:642: error: structure has no member named `ldo_tls_crlcheck' tls2.c: In function `ldap_pvt_tls_set_option': tls2.c:773: error: structure has no member named `ldo_tls_crlcheck' make[2]: *** [tls2.lo] Erreur 1 make[2]: Leaving directory `/SOUCHES/AFK/openldap-2.4.11/trunk/BUILD/openldap-2.4.14/libraries/libldap' make[1]: *** [all-common] Erreur 1 make[1]: Leaving directory `/SOUCHES/AFK/openldap-2.4.11/trunk/BUILD/openldap-2.4.14/libraries' make: *** [all-common] Erreur 1 I tried OpenSSL 0.9.8i, but it doesn't change anything. I have also used --with-ssl=on option, but it didn't change anything. Thanks for the support. Adrien

1 0

(ITS#5966) test056 may miss the current connection
by ando＠sys-net.it 21 Feb '09

21 Feb '09

Full_Name: Pierangelo Masarati Version: HEAD OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.63.140.131) Submitted by: ando One every few runs (1/75 roughly) test056 does not read the current connection from slapd, thus failing the check for the monitor1.out block. The "cn=Connection 1,cn=Connections,cn=Monitor" entry appears to be missing from the results returned when searching the subtree rooted at "cn=Connections,cn=Monitor". Not clear how this can happen, the logs do not show enough details, and the behavior is too erratic to trace. p.

1 0

ITS#5965
by ando＠sys-net.it 21 Feb '09

21 Feb '09

Should be fixed in HEAD, please test. 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

ITS#5505
by ando＠sys-net.it 21 Feb '09

21 Feb '09

The BackendDB structure could have a specific bd_modifiersName field for internal modifications; the slap_overinst structure could have a on_modifiersName as well. Both could be configurable using a(n optional, single-valued) olcModifiersName attribute. Internal writes would receive the modifiersName from: - the application; or - the overlay's olcModifiersName; or - the database's olcModifiersName; or - the database's rootdn; or - ?!? fail? remain anonymous? a call to int slap_get_modifiersName( Operation *op, BackendDB *be, slap_overinst *on, struct berval *mn, struct berval *nmn ) { *mn = op->o_dn; *nmn = op->o_ndn; if ( BER_BVISEMPTY( nmn ) ) { if ( on && !BER_BVISNULL( &on->on_modifiersName ) ) { *mn = on->on_modifiersName; *nmn = on->on_nmodifiersName; } else if ( be ) { if ( !BER_BVISNULL( &be->bd_modifiersName ) ) { *mn = be->bd_modifiersName; *nmn = be->bd_nmodifiersName; } else if ( !BER_BVISNULL( &be->bd_rootdn ) ) { *mn = be->bd_rootdn; *nmn = be->bd_rootndn; } } } return !BER_BVISEMPTY( nm ); } would return the appropriate value, if any. Probably a bit too much effort, but then multiple customizations that need to perform internal writes would be saved the effort and the dispersion of having to define their own configuration bit for a common feature. 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

(ITS#5965) PROBLEM ADDING NON MULTI-VALUED ATTRIBUTES USING ALSO RDN ATTRIBUTE
by evaristojosec＠yahoo.es 21 Feb '09

21 Feb '09

Full_Name: Evaristo Camarero Version: OpenLDAP 2.4.14 OS: Fedora Core 10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (83.60.182.235) Hi: The issue is related with ITS 5819 and the patch added to solve that issue, that I guess it does not solve completely the problem According to RFC 4511, it is possible to add a multivalued attribute using both RDN attribute and other attributes included in the entry Example: # Allowed because cn is not defined SINGLE-VALUE dn: cn=Bar,dc=example,dc=com objectClass: device cn: Foo The issue happens when the attribute employed in the rdn is SINGLE-VALUE, and we try to add 2 different values (the rdn attribute value and the other one), because the server allows that without sending the corresponding error. # attrSingleValue is defined as SINGLE-VALUE in the schema #ERROR: It should not be allowed because attrSingleValue dn: attrSingleValue=value1, dc=example, dc=com objectClass: whatever attrSingleValue=value2 Regards, Evaristo

1 0

Re: Debug mode "fixes" authentication issue - race condition?
by Neil Garratt 20 Feb '09

20 Feb '09

>> I'm testing OpenLDAP 2.3.27 (RPM) on Centos 5.2, used as a reverse >> proxy to AD. When slapd is run with debugging disabled (or set to 0), >> search requests throw the following error: > > OpenLDAP 2.3.27 is ancient. OpenLDAP 2.3.43 was the final OpenLDAP 2.3 > release. > > The current release is OpenLDAP 2.4.14. I suggest you retry with a modern > version of OpenLDAP, as numerous issues have been fixed since 2.3.27. > > --Quanah Retested with 2.4.14, exactly the same results. If I hammer away with the query on -d 0, I do occasionally get the correct result. If I hammer away on -d 1, I occasionally get the same failure I get with -d 0. Neil

2 1

Re: (ITS#5963) Explictly deleting all object classes and re-add some fails in modify request
by michael＠stroeder.com 20 Feb '09

20 Feb '09

Pierangelo Masarati wrote: > michael(a)stroeder.com wrote: > >> If I explicitly remove all object classes of an entry by value and >> re-add some >> of them the modify requests fail with >> "Type or value exists: modify/add: objectClass: value #1 already exists" >> >> Unfortunately I cannot provide a simple example for showing this. >> Specific configuration and data upon request since it's private >> data which MUST NOT be disclosed. > > I could not reproduce it. I also can't reproduce it with standard object classes on my local system. > Probably, the best way to proceed is: I could provide a canned config to a developer which should be kept confidential. Do you take that? Ciao, Michael.

1 0

Re: (ITS#5963) Explictly deleting all object classes and re-add some fails in modify request
by ando＠sys-net.it 20 Feb '09

20 Feb '09

michael(a)stroeder.com wrote: > If I explicitly remove all object classes of an entry by value and re-add some > of them the modify requests fail with > "Type or value exists: modify/add: objectClass: value #1 already exists" > > Unfortunately I cannot provide a simple example for showing this. Specific > configuration and data upon request since it's private data which MUST NOT be > disclosed. I could not reproduce it. Probably, the best way to proceed is: 1) write down the objectClass values before and after the attempted modifications 2) classify them as ABSTRACT, STRUCTURAL, AUXILIARY 3) indicate any inheritance relationship 4) send the outcome of (2) and (3) after mangling the objectClass names as required. This should allow you (and others) to try to reproduce the issue without the need to disclose your info. 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#5964) Explictly deleting all object classes and re-add some fails in modify request
by michael＠stroeder.com 20 Feb '09

20 Feb '09

openldap-its(a)OpenLDAP.org wrote: > You may follow the progress of this report by loading the following > URL in a web browser: > http://www.OpenLDAP.org/its/index.cgi?findid=5964 Sorry, this duplicate was produced by hitting reload. Please remove it. Ciao, Michael.

1 0

(ITS#5964) Explictly deleting all object classes and re-add some fails in modify request
by michael＠stroeder.com 20 Feb '09

20 Feb '09

Full_Name: Michael Ströder Version: RE24 (synced right now) OS: openSUSE 11.1 URL: Submission from: (NULL) (84.163.85.36) If I explicitly remove all object classes of an entry by value and re-add some of them the modify requests fail with "Type or value exists: modify/add: objectClass: value #1 already exists" Unfortunately I cannot provide a simple example for showing this. Specific configuration and data upon request since it's private data which MUST NOT be disclosed.

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs