Viewing Incoming/6874
Full headers

Major security issue: yes  no

Notes:
no info
Notification:

Date: Sat, 19 Mar 2011 13:37:46 +0000
From: dieter@dkluenter.de
To: openldap-its@OpenLDAP.org
Subject: slapd crashes while modifying a database

Full_Name: Dieter Kluenter
Version: 2.4.24
OS: SLES11_x64
URL: 
Submission from: (NULL) (88.71.14.24)


While modifying a database, either subordinate or not, slapd crashes.
Debugging and configuration information can be found here:
http://pastebin.de/16349 (debugging)
http://pastebin.de/16350 (slapd.conf)

linked libraries are
/usr/lib/openldap> ldd slapd
	linux-vdso.so.1 =>  (0x00007fff8e9e1000)
	libldap_r-2.4.so.2 => /usr/lib64/libldap_r-2.4.so.2 (0x00007f633361e000)
	liblber-2.4.so.2 => /usr/lib64/liblber-2.4.so.2 (0x00007f633340f000)
	libltdl.so.7 => /usr/lib64/libltdl.so.7 (0x00007f6333205000)
	libdb-4.5.so => /usr/lib64/libdb-4.5.so (0x00007f6332ece000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f6332cb1000)
	libslp.so.1 => /usr/lib64/libslp.so.1 (0x00007f6332a97000)
	libsasl2.so.2 => /usr/lib64/libsasl2.so.2 (0x00007f633287c000)
	libcrypto.so.1.0.0 => /lib64/libcrypto.so.1.0.0 (0x00007f63324cd000)
	libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007f6332292000)
	libwrap.so.0 => /lib64/libwrap.so.0 (0x00007f6332087000)
	libc.so.6 => /lib64/libc.so.6 (0x00007f6331d27000)
	libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f6331b10000)
	libssl.so.1.0.0 => /lib64/libssl.so.1.0.0 (0x00007f63318b4000)
	libdl.so.2 => /lib64/libdl.so.2 (0x00007f63316b0000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f633386f000)
	libz.so.1 => /lib64/libz.so.1 (0x00007f633149a000)

-Dieter

Followup 1

From: Ralf Haferkamp <rhafer@suse.de>
To: dieter@dkluenter.de
Subject: Re: (ITS#6874) slapd crashes while modifying a database
Date: Mon, 21 Mar 2011 17:39:08 +0100
Cc: openldap-its@openldap.org

Am Samstag 19 M=E4rz 2011, 14:37:46 schrieb dieter@dkluenter.de:
> While modifying a database, either subordinate or not, slapd crashes.
> Debugging and configuration information can be found here:
> http://pastebin.de/16349 (debugging)
> http://pastebin.de/16350 (slapd.conf)

I wonder if such a configuration is even supposed to work. The accesslog=20
overlay on the master is configured for the glued database=20
(dc=3Ddkluenter,dc=3Dde). On the slave however you have individual syncrepl=
=20
configuration for each subordinate database. Wouldn't it be correct to=20
have separate accesslog databases for the subordinates?

Additionally I think that at least the "overlay syncprov" for the=20
subordinate databases on the master is wrong (as syncprov is already=20
configured for the glued database). Not sure if it is harmful though.

A more selfcontained and stripped down example configuration with actual=20
data and information on which operation exactly fails could also help=20
debugging this (assuming that your config turns out to be valid).

Ralf