openldap-bugs

openldap-bugs@openldap.org

1 participants
20964 discussions

Re: (ITS#5745) slapcat doesn't return correct error status for bdb fatal error
by hyc＠symas.com 29 Oct '08

29 Oct '08

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/

1 0

Re: (ITS#5763) libRSAglue bug in OpenLDAP configure script
by hyc＠symas.com 29 Oct '08

29 Oct '08

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/

1 0

Re: (ITS#5777) slapd should reject BindRequest with 'name' when SASL bind is sent
by Kurt＠OpenLDAP.org 29 Oct '08

29 Oct '08

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

1 0

Re: (ITS#5777) slapd should reject BindRequest with 'name' when SASL bind is sent
by hyc＠symas.com 29 Oct '08

29 Oct '08

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/

1 0

(ITS#5777) slapd should reject BindRequest with 'name' when SASL bind is sent
by michael＠stroeder.com 29 Oct '08

29 Oct '08

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

1 0

Re: (ITS#5753) Command-line tools: Handling of -x and -D vs. -Y and -U
by michael＠stroeder.com 29 Oct '08

29 Oct '08

Seems to work as expected.

1 0

Re: (ITS#5771) autogroup overlay prevent slapd to works correctly
by ando＠sys-net.it 28 Oct '08

28 Oct '08

Guillaume.Rousse(a)inria.fr wrote: > Full_Name: Guillaume Rousse > Version: 2.4.12 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (82.224.237.5) > > > Enabling the autogroup overlay make slapd unwilling to work: > > [guillaume@oberkampf ~]$ ldapsearch -LLL -x > Server is unwilling to perform (53) > Additional information: operation not supported within namingContext I think this is a duplicate of ITS#5724; in fact, it seems to be already fixed in HEAD code. 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#5775) Statslog prints a DN for an entry that has been released in slap_send_search_entry()
by dhawes＠vt.edu 28 Oct '08

28 Oct '08

Pierangelo Masarati wrote: > Fixed in HEAD; please test. Thanks, p. Fix works, thanks.

1 0

Re: (ITS#5775) Statslog prints a DN for an entry that has been released in slap_send_search_entry()
by ando＠sys-net.it 28 Oct '08

28 Oct '08

Fixed in HEAD; please test. Thanks, 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: ACLs related to the content of *new* entries (ITS#4556)
by manu＠netbsd.org 28 Oct '08

28 Oct '08

Howard Chu <hyc(a)symas.com> wrote: > Hm, fixed as of when? I don't see 4556 listed in the RE24 CHANGES file. ITS's > that involve code changes generally don't get closed until the change gets > released. (Unless the ITS involves a Devel/HEAD-only piece of code, e.g. > patches to something that only existed in HEAD...) Given that rule, then it should remain open. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz manu(a)netbsd.org

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