(ITS#5779) backsql_load_schema_map checks wrong schema column in db
by robb@wtg.cw.com
Full_Name: Robert Brooks
Version: 2.4.12
OS: Linux
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (212.28.17.64)
start-up of slapd reports
"backsql_load_schema_map(): required column #6 "expect_return" is empty"
however the value of ldap_oc_mappings.create_proc is actually being checked,
this can be confirmed by changing create_proc value in database from empty value
to non-empty.
problem seems to be around line 567 of schema-map.c
" { delete_proc_idx + 1, "expect_return" },"
6 seems correct value, but actual result is not correct
14 years, 11 months
Re: (ITS#5778) slapd crashes while adding multipe attributes
by ando@sys-net.it
yoreck(a)rambler.ru wrote:
> Full_Name: Yuriy V. Ohonin
> Version: slapd 2.4.3alpha (Oct 16 2008 14:08:49)
Is there any special reason you're using a release that is more than 2
years old? Can you reproduce the issue with the latest release?
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
-----------------------------------
14 years, 11 months
(ITS#5778) slapd crashes while adding multipe attributes
by yoreck@rambler.ru
Full_Name: Yuriy V. Ohonin
Version: slapd 2.4.3alpha (Oct 16 2008 14:08:49)
OS: FreeBSD 6.2-RELEASE
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (80.65.16.93)
slapd daemon crashes complitely in such a situation:
I create my own class in shema
objectclass ( Tasks:Chain:Element
NAME ('x-tch-e' 'x-Task-Chain-Element')
MUST ( cn )
MAY ( x-tch-nxt $ x-tch-sp $ x-tch-ep )
DESC 'Container of pointers, next and previos'
)
and an attribute wich should have multiple values
attributetype ( Tasks:Attr:3
NAME ('x-tch-nxt' 'x-Task-Chain-Next')
EQUALITY distinguishedNameMatch
DESC 'Point to next chain element'
SYNTAX distinguishedName
)
Slapd starts sussesfully. It is possible add first x-tch-nxt attribute to an
entry, but if i try to add next one (usind ldapbrowser, or ldap_mod_add php
function) slapd stops (i have no such process any more)
this is what syslog say:
Oct 30 12:11:45 yurik kernel: pid 13227 (slapd), uid 389: exited on signal 6
14 years, 11 months
Re: (ITS#5777) slapd should reject BindRequest with 'name' when SASL bind is sent
by michael@stroeder.com
Kurt Zeilenga wrote:
>
> On Oct 29, 2008, at 2:56 AM, michael(a)stroeder.com wrote:
>
>> I wonder whether it would be worth that slapd rejects a SASL bind
>> request with
>> BindRequest.name set (normally used for simple bind) returning a
>> protocolError
>> error code.
>
> RFC 4513:
> Clients sending a BindRequest message with the sasl choice selected
> SHOULD send a zero-length value in the name field. Servers receiving
> a BindRequest message with the sasl choice selected SHALL ignore any
> value in the name field.
>
> So, no.
Ok.
My intention was that if 'name' field and SASL authc-ID leads to
different identity mapping it could confuse admins seeing 'name' in the
BindRequest but a different authz-ID being in effect.
Anyway no strong need, just an idea.
Ciao, Michael.
14 years, 11 months
Re: (ITS#5745) slapcat doesn't return correct error status for bdb fatal error
by hyc@symas.com
Guillaume.Rousse(a)inria.fr wrote:
> Full_Name: Guillaume Rousse
> Version: 2.4.12
> OS:
> URL:
> Submission from: (NULL) (193.55.250.67)
>
>
> [root@etoile ~]# slapcat -b dc=msr-inria,dc=inria,dc=fr
> ...
> bdb(dc=msr-inria,dc=inria,dc=fr): pthread lock failed: Invalid argument
> bdb(dc=msr-inria,dc=inria,dc=fr): PANIC: Invalid argument
> bdb(dc=msr-inria,dc=inria,dc=fr): PANIC: DB_RUNRECOVERY: Fatal error, run
> database recovery
> bdb(dc=msr-inria,dc=inria,dc=fr): PANIC: fatal region error detected; run
> recovery
> bdb_db_close: database "dc=msr-inria,dc=inria,dc=fr": close failed:
> DB_RUNRECOVERY: Fatal error, run database recovery (-30975)
> [root@etoile ~]# echo $?
> 0
>
> It makes a bit difficult to know if slapcat-based backup were successful.
How did you create this situation? I can't test a fix without some way to
break the DB in the first place, and generally the DB doesn't fail...
--
-- 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#5763) libRSAglue bug in OpenLDAP configure script
by hyc@symas.com
epj(a)newpointtech.com wrote:
> Full_Name: Eric Johanson
> Version: 2.4.12
> OS: Debian Linux 4.0
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (64.80.228.78)
>
>
> The "configure" script has a bug when TLS is enabled, which causes it to fail
> when using recent versions of OpenSSL. The bug is found on line 18759 of the
> "configure" script in OpenLDAP 2.4.12. The line currently reads:
>
> LIBS="-lssl -lcrypto -lRSAglue -lrsaref $LIBS"
>
> But the -lRSAglue and -lrsaref are old OpenSSL libraries that are not in use any
> more. I modified the above line to read:
>
> LIBS="-lssl -lcrypto $LIBS"
>
> This solves the problem. However, perhaps someone wants to add logic to detect
> which version of OpenSSL is being used and then vary the LIBS variable
> accordingly when the configure script tests for the linkability of the
> ssl3_accept() function.
>
> Note that many Linux systems, even those that have a recent OpenSSL, may still
> have the -lRSAglue and -lrsaref libraries (just for compatibility reasons). To
> reproduce this bug, you will have to search your system and remove all files
> with the names libRSAglue.a and librsaref.a.
The configure script only checks for -lRSAglue after it has already failed to
link without it. As such, there's something wrong on your machine for it to
even be reaching that test. There is no OpenLDAP bug 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/
14 years, 11 months
Re: (ITS#5777) slapd should reject BindRequest with 'name' when SASL bind is sent
by Kurt@OpenLDAP.org
On Oct 29, 2008, at 2:56 AM, michael(a)stroeder.com wrote:
> I wonder whether it would be worth that slapd rejects a SASL bind
> request with
> BindRequest.name set (normally used for simple bind) returning a
> protocolError
> error code.
RFC 4513:
Clients sending a BindRequest message with the sasl choice selected
SHOULD send a zero-length value in the name field. Servers
receiving
a BindRequest message with the sasl choice selected SHALL ignore any
value in the name field.
So, no.
-- Kurt
14 years, 11 months
Re: (ITS#5777) slapd should reject BindRequest with 'name' when SASL bind is sent
by hyc@symas.com
michael(a)stroeder.com wrote:
> Full_Name: Michael Ströder
> Version: HEAD
> OS: Linux
> URL:
> Submission from: (NULL) (84.163.120.227)
>
>
> This is somewhat related to the client tool modification in ITS#5753.
>
> I wonder whether it would be worth that slapd rejects a SASL bind request with
> BindRequest.name set (normally used for simple bind) returning a protocolError
> error code.
>
> Example for an inconsistent use of -D and -U with SASL/DIGEST-MD5 at the
> command-line:
>
> $ ldapwhoami -D "cn=root,dc=stroeder,dc=de" -W -U michael -Y DIGEST-MD5
> Enter LDAP Password:
> SASL/DIGEST-MD5 authentication started
> SASL username: michael
> SASL SSF: 128
> SASL data security layer installed.
> dn:cn=michael ströder,ou=private,dc=stroeder,dc=de
Changing this behavior seems like a bad idea to me. Currently the RFC doesn't
require servers to behave one way or the other, so there's no argument that
this change would improve interoperability. If there are no clients out there
depending on the behavior, then this change is meaningless. If there *are*
clients out there depending on the behavior, then they will break for no
apparent reason.
--
-- 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
(ITS#5777) slapd should reject BindRequest with 'name' when SASL bind is sent
by michael@stroeder.com
Full_Name: Michael Ströder
Version: HEAD
OS: Linux
URL:
Submission from: (NULL) (84.163.120.227)
This is somewhat related to the client tool modification in ITS#5753.
I wonder whether it would be worth that slapd rejects a SASL bind request with
BindRequest.name set (normally used for simple bind) returning a protocolError
error code.
Example for an inconsistent use of -D and -U with SASL/DIGEST-MD5 at the
command-line:
$ ldapwhoami -D "cn=root,dc=stroeder,dc=de" -W -U michael -Y DIGEST-MD5
Enter LDAP Password:
SASL/DIGEST-MD5 authentication started
SASL username: michael
SASL SSF: 128
SASL data security layer installed.
dn:cn=michael ströder,ou=private,dc=stroeder,dc=de
14 years, 11 months