openldap-bugs

openldap-bugs@openldap.org

1 participants
21001 discussions

Re: (ITS#5576) Missing attribute type 'managedInfo' referenced with SUP
by michael＠stroeder.com 25 Jun '08

25 Jun '08

Hallvard B Furuseth wrote: > michael(a)stroeder.com writes: >> The following attribute type declaration references 'managedInfo' >> which is not declared: >> >> ( 1.3.6.1.4.1.4203.666.1.55.0.1.2.1 NAME 'olmDbURIList' DESC 'List of URIs a >> proxy is serving; can be modified run-time' SUP managedInfo ) > > Please mention where the code is which you refer to. > > Anyway, this is in back-ldap/monitor.c and managedInfo *is* declared - > in back-monitor/init.c. Have you observed a failure, e.g. with > back-ldap and ./configure --disable-monitor? I'm simply looking an cn=monitor of RE24. I probably have to rephrase that: The schema elements of back-monitor seems not to be available in the subschema subentry. Ciao, Michael.

1 0

Re: (ITS#5540) Normalization assertion in attr.c
by unix.gurus＠gmail.com 25 Jun '08

25 Jun '08

On Tue, Jun 24, 2008 at 12:50 PM, <unix.gurus(a)gmail.com> wrote: > Hi, > > I have uploaded a patch against HEAD that normalizes the attributes > used under cn=monitor according to the schema: > ftp://ftp.openldap.org/incoming/sean-burford-monitor-normalize-080624.patch Unified diff of the same thing: sean-burford-monitor-normalize-unified-080624.patch The search (namingContexts:distinguishedNameMatch:=CN=...) returns the expected results, I'll check what filterentry.c:test_mra_filter() is up to later. make test also completes successfully, for what it's worth. -- Thanks, Sean Burford

1 0

Re: (ITS#5540) Normalization assertion in attr.c
by unix.gurus＠gmail.com 24 Jun '08

24 Jun '08

Hi, I have uploaded a patch against HEAD that normalizes the attributes used under cn=monitor according to the schema: ftp://ftp.openldap.org/incoming/sean-burford-monitor-normalize-080624.patch I picked cn=monitor for the first upload since it can be modified without having to reimport databases. Once we've worked through any issues with this patch I'll seperate out the rest of the normalization patches and send those in. namingContexts was the trickiest, since RFC 4512 defines it without an equality matching rule but monitor_back_register_database() compares it with backend suffixes. It has to deal with capitalised values properly otherwise we end up with duplicate namingContexts entries, so normalization is required. The relevant part of the diff is below. I am open to suggestions about how this should be dealt with: + struct berval nContext; + + for ( j = 0; !BER_BVISNULL( &a->a_vals[ j ] ); j++ ) { + /* FIXME: namingContexts has no equality rule + * but it needs to be normalized for this + * comparison. Using si_ad_distinguishedName + * instead of si_ad_namingContexts results + * in the normalization we expect for now. + */ + if ( attr_normalize_one( slap_schema.si_ad_distinguishedName, + &a->a_vals[ j ], + &nContext, + NULL ) ) { + Debug( LDAP_DEBUG_ANY, + "monitor_subsys_database_init: " + "unable to normalize DN %d \"%s\"\n", + j, a->a_vals[ j ], 0 ); + return( -1 ); + } for ( k = 0; !BER_BVISNULL( &be->be_nsuffix[ k ] ); k++ ) { ! if ( dn_match( &nContext, &be->be_nsuffix[ k ] ) ) { rc = 0; goto done; } } + free( nContext.bv_val ); The attribute types that are modified and the attributes that are affected are listed below. cn=Monitor didn't need and schema modifications: monitorContext: removed nvals namingContexts: removed nvals rootDSE monitorContext and namingContexts monitorCounter: removed nvals cn=Max File Descriptors cn=Total,cn=Connections cn=Current,cn=Connections cn=Read under rww DN counter under sent monitorConnectionProtocol: removed nvals monitorConnectionMask: normalized monitorConnectionListener: normalized monitorConnectionPeerDomain: normalized monitorConnectionPeerAddress: normalized monitorConnectionLocalAddress: normalized monitorConnectionStartTime: normalized monitorConnectionActivityTime: normalized monitorOpInitiated: removed nvals monitorOpCompleted: removed nvals readOnly: removed nvals -- Thanks, Sean Burford

1 0

Re: (ITS#5576) Missing attribute type 'managedInfo' referenced with SUP
by hyc＠symas.com 24 Jun '08

24 Jun '08

h.b.furuseth(a)usit.uio.no wrote: > ando(a)sys-net.it writes: >> I suspect something like: if back-monitor and/or back-ldap are built as >> modules, and loaded in the wrong order (back-ldap first, back_monitor >> then), 'olmDbURIList' is likely to be registered __before__ >> 'managedInfo'. > > So, a manpage fix something like this? > > If monitor is a dynamically loaded module, it should be "moduleload"ed > before any modules it wants to monitor. A dynamically loaded monitor > may be unable to monitor a statically built module. Not necessary. The order of moduleloads is irrelevant. back-monitor initializes its schema as soon as the module is loaded. All of the other backends initialize their monitor schema when a backend is first instantiated. The problem you're talking about here doesn't exist. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5576) Missing attribute type 'managedInfo' referenced with SUP
by h.b.furuseth＠usit.uio.no 24 Jun '08

24 Jun '08

ando(a)sys-net.it writes: > I suspect something like: if back-monitor and/or back-ldap are built as > modules, and loaded in the wrong order (back-ldap first, back_monitor > then), 'olmDbURIList' is likely to be registered __before__ > 'managedInfo'. So, a manpage fix something like this? If monitor is a dynamically loaded module, it should be "moduleload"ed before any modules it wants to monitor. A dynamically loaded monitor may be unable to monitor a statically built module. > only "clean" solution would be for back-ldap to register a function that > is executed when back-monitor is loaded, in order to register dependent > schema items and enable the monitoring feature it implements. Well, that's doable, if anyone cares. Or a simpler variant would be: back-monitor complains if it can tell it's not the first moduleloaded module, or modules that try to use back-monitor set a "I couldn't find back-monitor" flag and back-monitor logs a warning if that flag is set. -- Hallvard

1 0

Re: (ITS#5577) [BUG, PATCH] slapd unable to import CRL using GnuTLS backend
by hyc＠symas.com 24 Jun '08

24 Jun '08

arno(a)natisbad.org wrote: > Full_Name: Arnaud Ebalard > Version: 2.4.10 > OS: Linux (Debian unstable) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (213.215.50.138) > > > Hi, > > When openldap is linked with gnutls for TLS support, a file containing > CRL in PEM format can be provided (in slapd.conf, using TLSCRLFile > parameter). > > The following code in ldap_int_tls_init_ctx() (librairies/libldap/tls.c) > prevents the daemon to start when the option is used: > > if ( lo->ldo_tls_crlfile ) { > rc = gnutls_certificate_set_x509_crl_file( > ((tls_ctx*) lo->ldo_tls_ctx)->cred, > crlfile, > GNUTLS_X509_FMT_PEM ); > if ( rc< 0 ) goto error_exit; > } > > because gnutls_certificate_set_x509_crl_file() returns the number of CRL > files that have been imported which is stored in rc and returned later > in the function. Caller expects 0, otherwise it reports an error, the > value of rc (below, with 3 CRL in the file) and slapd fails to start: > > .... main TLS init def ctx failed: 3 Thanks, fixed in HEAD. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5577) [BUG, PATCH] slapd unable to import CRL using GnuTLS backend
by arno＠natisbad.org 24 Jun '08

24 Jun '08

Full_Name: Arnaud Ebalard Version: 2.4.10 OS: Linux (Debian unstable) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (213.215.50.138) Hi, When openldap is linked with gnutls for TLS support, a file containing CRL in PEM format can be provided (in slapd.conf, using TLSCRLFile parameter). The following code in ldap_int_tls_init_ctx() (librairies/libldap/tls.c) prevents the daemon to start when the option is used: if ( lo->ldo_tls_crlfile ) { rc = gnutls_certificate_set_x509_crl_file( ((tls_ctx*) lo->ldo_tls_ctx)->cred, crlfile, GNUTLS_X509_FMT_PEM ); if ( rc < 0 ) goto error_exit; } because gnutls_certificate_set_x509_crl_file() returns the number of CRL files that have been imported which is stored in rc and returned later in the function. Caller expects 0, otherwise it reports an error, the value of rc (below, with 3 CRL in the file) and slapd fails to start: .... main TLS init def ctx failed: 3 The patch below is for 2.4.10, but should apply against all versions (it applies fine against current Debian version available under Unstable). Tell me if you have issues. I recompiled the Debian version with the patch applied and it works as expected. Cheers, a+ The patch is IMHO short enough to inline it here: Index: openldap-2.4.10/libraries/libldap/tls.c =================================================================== --- openldap-2.4.10.orig/libraries/libldap/tls.c 2008-06-24 16:10:00.128945991 +0200 +++ openldap-2.4.10/libraries/libldap/tls.c 2008-06-24 16:11:46.804929042 +0200 @@ -754,7 +754,10 @@ ((tls_ctx*) lo->ldo_tls_ctx)->cred, crlfile, GNUTLS_X509_FMT_PEM ); - if ( rc < 0 ) goto error_exit; + if ( rc < 0 ) + goto error_exit; + else + rc = 0; } if ( is_server ) { gnutls_dh_params_init (&((tls_ctx*)

1 0

Re: (ITS#5576) Missing attribute type 'managedInfo' referenced with SUP
by hyc＠symas.com 24 Jun '08

24 Jun '08

ando(a)sys-net.it wrote: > h.b.furuseth(a)usit.uio.no wrote: >> michael(a)stroeder.com writes: >>> The following attribute type declaration references 'managedInfo' >>> which is not declared: >>> >>> ( 1.3.6.1.4.1.4203.666.1.55.0.1.2.1 NAME 'olmDbURIList' DESC 'List of URIs a >>> proxy is serving; can be modified run-time' SUP managedInfo ) >> Please mention where the code is which you refer to. >> >> Anyway, this is in back-ldap/monitor.c and managedInfo *is* declared - >> in back-monitor/init.c. Have you observed a failure, e.g. with >> back-ldap and ./configure --disable-monitor? > > I suspect something like: if back-monitor and/or back-ldap are built as > modules, and loaded in the wrong order (back-ldap first, back_monitor > then), 'olmDbURIList' is likely to be registered __before__ > 'managedInfo'. I don't see a quick fix (or anything but requiring > loading the modules in the right order) to this issue. In fact, the > only "clean" solution would be for back-ldap to register a function that > is executed when back-monitor is loaded, in order to register dependent > schema items and enable the monitoring feature it implements. The > safest thing to do right now is condition the registration of > 'olmDbURIList' to the existence of 'managedInfo', conditioning the > availability of the monitoring feature to loading the modules in the > right order. Of course this ought to be documented somewhere. Note > that probably similar issues exist in back-bdb's specific monitoring > features. The fact that I seldom develop while building backends and > overlays as modules might have an impact on this type of issues, though. We already solved this dependency in back-ldap and back-bdb - their monitor_init() functions will return without doing anything if backend_info("monitor") fails. As such, these schema items will only be registered if back-monitor has already beeen loaded. There's no issue here. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5576) Missing attribute type 'managedInfo' referenced with SUP
by Kurt＠OpenLDAP.org 24 Jun '08

24 Jun '08

On Jun 23, 2008, at 4:58 PM, michael(a)stroeder.com wrote: > Full_Name: Michael Ströder > Version: RE24 > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (84.163.96.75) > > > The following attribute type declaration references 'managedInfo' > which is not > declared: > > ( 1.3.6.1.4.1.4203.666.1.55.0.1.2.1 NAME 'olmDbURIList' DESC 'List > of URIs a > proxy is serving; can be modified run-time' SUP managedInfo ) THe fact that this element is published with a .666 OID is a bug. . 666 are intended for experiments and should never be published. -- Kurt

1 0

Re: (ITS#5576) Missing attribute type 'managedInfo' referenced with SUP
by ando＠sys-net.it 24 Jun '08

24 Jun '08

h.b.furuseth(a)usit.uio.no wrote: > michael(a)stroeder.com writes: >> The following attribute type declaration references 'managedInfo' >> which is not declared: >> >> ( 1.3.6.1.4.1.4203.666.1.55.0.1.2.1 NAME 'olmDbURIList' DESC 'List of URIs a >> proxy is serving; can be modified run-time' SUP managedInfo ) > > Please mention where the code is which you refer to. > > Anyway, this is in back-ldap/monitor.c and managedInfo *is* declared - > in back-monitor/init.c. Have you observed a failure, e.g. with > back-ldap and ./configure --disable-monitor? I suspect something like: if back-monitor and/or back-ldap are built as modules, and loaded in the wrong order (back-ldap first, back_monitor then), 'olmDbURIList' is likely to be registered __before__ 'managedInfo'. I don't see a quick fix (or anything but requiring loading the modules in the right order) to this issue. In fact, the only "clean" solution would be for back-ldap to register a function that is executed when back-monitor is loaded, in order to register dependent schema items and enable the monitoring feature it implements. The safest thing to do right now is condition the registration of 'olmDbURIList' to the existence of 'managedInfo', conditioning the availability of the monitoring feature to loading the modules in the right order. Of course this ought to be documented somewhere. Note that probably similar issues exist in back-bdb's specific monitoring features. The fact that I seldom develop while building backends and overlays as modules might have an impact on this type of issues, though. 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 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