Re: (ITS#8672) syncrepl with openldap 2.4.{40,42} and mdb backend

[remy.dernat@univ-montp2.fr]

Hi Ryan, Quanah,


Le 11/06/2017 à 03:57, Ryan Tandy a écrit :
> On Thu, Jun 08, 2017 at 01:06:21PM +0000, remy.dernat@umontpellier.fr 
> wrote:
>> I am able to reproduce the bug quite easily.
>
> I'm afraid I have not been able to. I followed the steps you posted 
> (with s/hdb/mdb/) with both servers running slapd 2.4.40+dfsg-1+deb8u3 
> and syncrepl seems to work fine.
>
> https://bugs.debian.org/798964 seems quite similar. R�my, do you think 
> this problem started for you right after you upgraded to +deb8u3?

Indeed, I am afraid that this upgrade causes this issue, or maybe rather 
the previous one. `2.4.40+dfsg-1+deb8u2` were upgraded on my system in 
February and syncrepl does not work from this moment.

Concerning tests from the latest source, I am not able to reproduce this 
bug as I get a weird error, with some stuff remaining from my previous 
install:
```
LDAP vendor version mismatch: library 20440, header 20445
```
Google leads me to this topics :
https://bbs.archlinux.org/viewtopic.php?id=56872
http://www.openldap.org/lists/openldap-software/200307/msg00399.html


Although I removed every previous packages.


Using ldd :
```
ldd `which ldapadd`
         linux-vdso.so.1 (0x00007ffe19765000)
         libldap-2.4.so.2 => /usr/lib/x86_64-linux-gnu/libldap-2.4.so.2 
(0x00007fef25b0d000)
         liblber-2.4.so.2 => /usr/lib/x86_64-linux-gnu/liblber-2.4.so.2 
(0x00007fef258fe000)
         libsasl2.so.2 => /usr/lib/x86_64-linux-gnu/libsasl2.so.2 
(0x00007fef256e1000)
         libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1 
(0x00007fef254aa000)
         libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 
(0x00007fef25293000)
         libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fef24ee7000)
         libgnutls-deb0.so.28 => 
/usr/lib/x86_64-linux-gnu/libgnutls-deb0.so.28 (0x00007fef24bc7000)
         libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x00007fef249aa000)
         libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fef247a5000)
         /lib64/ld-linux-x86-64.so.2 (0x000055776c6be000)
         libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fef2458a000)
         libp11-kit.so.0 => /usr/lib/x86_64-linux-gnu/libp11-kit.so.0 
(0x00007fef24344000)
         libtasn1.so.6 => /usr/lib/x86_64-linux-gnu/libtasn1.so.6 
(0x00007fef2412f000)
         libnettle.so.4 => /usr/lib/x86_64-linux-gnu/libnettle.so.4 
(0x00007fef23efd000)
         libhogweed.so.2 => /usr/lib/x86_64-linux-gnu/libhogweed.so.2 
(0x00007fef23cce000)
         libgmp.so.10 => /usr/lib/x86_64-linux-gnu/libgmp.so.10 
(0x00007fef23a4a000)
         libffi.so.6 => /usr/lib/x86_64-linux-gnu/libffi.so.6 
(0x00007fef23842000)
```

with strace : http://paste.debian.net/971168/

And no result with:
```
for file in `ldd /usr/local/bin/ldapadd |awk '{print $3}'`; do echo 
$file && objdump -T $file |grep 2044; done
```
(and nothing in /var/log/slapd.log)

I should try to install it from a fresh install, it would be easier. 
Anyway, as you said, if installing it from a fresh install did not gave 
you this bug, I think you can close it...

In the meantime, I am working with two other servers for production. As 
it works for me now (with hdb), I think I will remove the 2 others. This 
bug already took me too many time.

Best regards,
Rémy

-- 
Rémy Dernat
Ingénieur d'Etudes
MBB/ISE-M