(ITS#5578) sortvals error
by andrew.findlay＠skills-1st.co.uk
Full_Name: Andrew Findlay
Version: 2.4.10
OS: Linux
URL: ftp://ftp.openldap.org/incoming/andrew-findlay-20080625.tgz
Submission from: (NULL) (88.97.25.132)
When 'sortvals members' is in effect, some attribute modify operations produce
bad results. This seems to occur when an operation adds an attribute that sorts
to the end of the list.
The attached tarball contains a cut-down config and dataset, along with a set of
scripts and LDIF files that demonstrate the bug.
To create the problem:
(This does NOT need to run as root)
edit vars to set appropriate PATH
# First version of problem - single LDAP op removes one member and adds
another:
rm -r openldap-db
mkdir openldap-db
./start-slapd
./load-dsa data.ldif
./update-dsa mess-tenk.ldif
./update-dsa unmess-tenk.ldif
The first update is OK, but the second fails thus:
modifying entry "cn=tenK,ou=groups,o=test,dc=example,dc=org"
ldap_modify: No such attribute (16)
additional info: modify/delete: member: no such value
If 'sortvals member' is not set in slapd.conf.test you can just alternate those
two LDIFs forever.
Check data with:
./bound-search cn=tenk
Now compare with the same process using change-tenk.ldif and
change-tenk-back.ldif
- they do the same job but with a value that sorts earlier, and they work OK.
# Second version - repeat adding of single value:
./stop-slapd
rm -r openldap-db
mkdir openldap-db
./start-slapd
./load-dsa data.ldif
./update-dsa add-member.ldif
./update-dsa add-member.ldif
./update-dsa add-member.ldif
First update OK.
Second update OK but should not be.
Third fails is it should.
Check data with:
./bound-search cn=tenk
14 years, 11 months
Re: (ITS#5576) Missing attribute type 'managedInfo' referenced with SUP
by michael＠stroeder.com
Michael Ströder wrote:
> Kurt Zeilenga wrote:
>>
>> On Jun 23, 2008, at 4:58 PM, michael(a)stroeder.com wrote:
>>> ( 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.
>
> Sorry, could have been in my build because of -DDEVEL.
Built without -DDEVEL and this schema element is still there but not
'managedInfo'.
> P.S.: Frankly I see no problem with publishing a .666 OID.
Personally I'd prefer to see interims schema elements in the subschema
subentry over seeing no schema declaration for existing attributes.
Ciao, Michael.
14 years, 11 months
Re: (ITS#5576) Missing attribute type 'managedInfo' referenced with SUP
by ando＠sys-net.it
hyc(a)symas.com wrote:
> 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.
well, all modules do. So if a module needs to register schema dependent
on another module that's not loaded yet, it should either fail or, if
that piece of schema is to be considered optional, just complain it
couldn't do all the job. So it seems pertinent: if you load modules in
the "wrong" order, you could miss monitoring functionalities. I note
that back-bdb actually tries to register the schema all times a database
is instantiated, unless already done. In any case, if the back_monitor
module is loaded __after__ the server is already running, existing
databases will not gain monitoring capabilities; only subsequent ones
will. I don't consider this necessarily a bug (it could be worked out
by explicitly setting "monitoring" to "on" after loading the
back_monitor module, provided some backend-specific hook is invoked).
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
-----------------------------------
14 years, 11 months
Re: (ITS#5576) Missing attribute type 'managedInfo' referenced with SUP
by michael＠stroeder.com
Kurt Zeilenga wrote:
>
> On Jun 23, 2008, at 4:58 PM, michael(a)stroeder.com wrote:
>> ( 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.
Sorry, could have been in my build because of -DDEVEL.
Nevertheless I'd appreciate if the schema elements of back-monitor are
published in subschema subentry.
Ciao, Michael.
P.S.: Frankly I see no problem with publishing a .666 OID.
14 years, 11 months
Re: (ITS#5576) Missing attribute type 'managedInfo' referenced with SUP
by michael＠stroeder.com
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.
14 years, 11 months
Re: (ITS#5540) Normalization assertion in attr.c
by unix.gurus＠gmail.com
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
14 years, 11 months
Re: (ITS#5540) Normalization assertion in attr.c
by unix.gurus＠gmail.com
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
14 years, 11 months
Re: (ITS#5576) Missing attribute type 'managedInfo' referenced with SUP
by hyc＠symas.com
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/
14 years, 11 months
Re: (ITS#5576) Missing attribute type 'managedInfo' referenced with SUP
by h.b.furuseth＠usit.uio.no
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
14 years, 11 months
Re: (ITS#5577) [BUG, PATCH] slapd unable to import CRL using GnuTLS backend
by hyc＠symas.com
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/
14 years, 11 months
