Debian Bug report logs - #464024
syncrepl provider kills consumer by sending truncated cookie

version graph

Package: slapd; Maintainer for slapd is Debian OpenLDAP Maintainers <pkg-openldap-devel@lists.alioth.debian.org>; Source for slapd is src:openldap.

Reported by: Ralph Rößner <roessner@capcom.de>

Date: Mon, 4 Feb 2008 19:36:02 UTC

Severity: important

Tags: fixed-upstream, upstream

Found in version openldap2.3/2.4.7-3

Fixed in version openldap2.3/2.4.9-1

Done: Matthijs Mohlmann <matthijs@cacholong.nl>

Bug is archived. No further changes may be made.

Forwarded to http://www.openldap.org/its/index.cgi/?findid=5362

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, Debian OpenLDAP Maintainers <pkg-openldap-devel@lists.alioth.debian.org>:
Bug#464024; Package slapd. Full text and rfc822 format available.

Acknowledgement sent to Ralph Rößner <roessner@capcom.de>:
New Bug report received and forwarded. Copy sent to Debian OpenLDAP Maintainers <pkg-openldap-devel@lists.alioth.debian.org>. Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: Ralph Rößner <roessner@capcom.de>
To: submit@bugs.debian.org
Subject: syncrepl provider kills consumer by sending truncated cookie
Date: Mon, 4 Feb 2008 20:33:30 +0100
[Message part 1 (text/plain, inline)]
Package: slapd
Version: 2.4.7-3
Severity: Important

Hi,

when our syncrepl consumers (refreshOnly mode) query the provider for
changes, the provider will sometimes send back an intermediate message
that has the syncronization cookie truncated (the csn is missing). This
causes the consumer to die (segfault). Upon restart, the consumer
database will be empty. In a rarer case, the consumer will survive but
have its database cleaned out as well. This problem appeared after the
upgrade from 2.3.83-1+lenny1. 

Our LDAP infrastructure contains a syncrepl provider and three consumers
in refreshOnly mode. Two of the consumers get an identical subset of the
data and are configured alike except for the replication user, while the
third serves a different purpose. All consumers have been hit by the
problem, the ones configured alike die at the same time. The problem
appears at apparently random intervals, from a few hours to a few days.

Since then I have tried a few changes to our configuration and an
upgrade to 2.4.7-4, mainly to keep things alive (mail customers not
being happy). This has yielded only one result, namely that switching to
refreshAndPersist mode avoids the problem, I had one of the alike
configured consumers running in refreshAndPersist, and it survived when
the other failed.

I have set up a test consumer server, copying the existing
configuration, and it has nicely duplicated the problem, even
reproducably for a stretch of time, So I am able to provide sane (i.e.
without a lot of queries for mail adresses) debug logs that show the
consumer failing. I have also captured a debug log of the provider
working at the replication query, from a later point in time since
restarting the provider to change the log level has cleared the problem
for a while.

You will notice in the logs that the intermediate message returned to
the client contains a cookie that stops after the "csn=" string, i.e. it
does not actually contain a value for the csn. I think that is what
kills the consumer. I don't have a clue why the provider does that.

I have provided a network trace (in pcap format) of the exchange,
leaving out the handshake and bind request message to avoid password
disclosure. Unless I'm mistaken, the refreshDeletes flag of the
intermediate message is set to TRUE, indicating multiple deletes
(right?). This fits well with the rare case of the consumer deleting all
its entries (which I have not been able to get logs of so far). 

From the usual use of our provider server I would have expected zero or
one changes within the poll interval, and definitely no deleted objects.
So the fact that the provider is trying to send a sync id set at all
and flag it as deletes looks suspicious to me. The test consumer server
has never logged such an intermediate message as reaction to a
synchronization search except in these fatal cases, for the few days
that it has been running debug enabled now.

Now I hope that someone has an idea about what might be going wrong in
the provider server. I can just speculate that the problems we observe
are symptoms of a deeper problem.

Some software versions:

slapd: 2.4.7-3
libc6: 2.7-6
libdb4.2: 4.2.52+dfsg-4
libgnutls13: 2.0.4-1
libiodbc2: 3.52.6-1
libldap-2.4-2: 2.4.7-3

Attached files:

slapd.conf.keldon - provider configuration file
slapd.conf.gorkon - test consumer configuration file
slapd.crash.capture - network trace of the consumer - provider
                    communication while performing the deadly replication
slapd.crash.strace - syscall trace of the consumer at the same time
slapd.crash.log -   debug log of the consumer, levels
                    sync+stats+acl+trace, at the same time
provider.log -      debug log of the provider, levels sync+stats+trace,
                    at a later deadly replication

Sincerely,
   Ralph Rößner

-- 
Ralph Rößner
CAPCom AG < http://www.capcom.de >
Rundeturmstr. 10, 64283 Darmstadt, Germany
Phone +49 6151 155 900, Fax +49 6151 155 909

Vorstand: Luc Neumann (Vorsitzender)
Vorsitzender des Aufsichtsrats: Prof. Dr.-Ing. José L. Encarnação
Sitz der Gesellschaft: Darmstadt, Registergericht: Darmstadt HRB 8090
[slapd.conf.keldon (text/plain, attachment)]
[slapd.conf.gorkon (text/plain, attachment)]
[slapd.crash.capture (application/octet-stream, attachment)]
[slapd.crash.strace (text/plain, attachment)]
[slapd.crash.log (text/plain, attachment)]
[provider.log (text/plain, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian OpenLDAP Maintainers <pkg-openldap-devel@lists.alioth.debian.org>:
Bug#464024; Package slapd. Full text and rfc822 format available.

Acknowledgement sent to Quanah Gibson-Mount <quanah@zimbra.com>:
Extra info received and forwarded to list. Copy sent to Debian OpenLDAP Maintainers <pkg-openldap-devel@lists.alioth.debian.org>. Full text and rfc822 format available.

Message #10 received at 464024@bugs.debian.org (full text, mbox):

From: Quanah Gibson-Mount <quanah@zimbra.com>
To: 464024@bugs.debian.org
Cc: Ralph Rößner <roessner@capcom.de>
Subject: Re: [Pkg-openldap-devel] Bug#464024: syncrepl provider kills consumer by sending truncated cookie
Date: Sat, 09 Feb 2008 08:27:58 -0800
This has been filed upstream as ITS#5362

--Quanah

--On February 4, 2008 8:33:30 PM +0100 Ralph Rößner <roessner@capcom.de> 
wrote:

> Package: slapd
> Version: 2.4.7-3
> Severity: Important
>
> Hi,
>
> when our syncrepl consumers (refreshOnly mode) query the provider for
> changes, the provider will sometimes send back an intermediate message
> that has the syncronization cookie truncated (the csn is missing). This
> causes the consumer to die (segfault). Upon restart, the consumer
> database will be empty. In a rarer case, the consumer will survive but
> have its database cleaned out as well. This problem appeared after the
> upgrade from 2.3.83-1+lenny1.
>
> Our LDAP infrastructure contains a syncrepl provider and three consumers
> in refreshOnly mode. Two of the consumers get an identical subset of the
> data and are configured alike except for the replication user, while the
> third serves a different purpose. All consumers have been hit by the
> problem, the ones configured alike die at the same time. The problem
> appears at apparently random intervals, from a few hours to a few days.
>
> Since then I have tried a few changes to our configuration and an
> upgrade to 2.4.7-4, mainly to keep things alive (mail customers not
> being happy). This has yielded only one result, namely that switching to
> refreshAndPersist mode avoids the problem, I had one of the alike
> configured consumers running in refreshAndPersist, and it survived when
> the other failed.
>
> I have set up a test consumer server, copying the existing
> configuration, and it has nicely duplicated the problem, even
> reproducably for a stretch of time, So I am able to provide sane (i.e.
> without a lot of queries for mail adresses) debug logs that show the
> consumer failing. I have also captured a debug log of the provider
> working at the replication query, from a later point in time since
> restarting the provider to change the log level has cleared the problem
> for a while.
>
> You will notice in the logs that the intermediate message returned to
> the client contains a cookie that stops after the "csn=" string, i.e. it
> does not actually contain a value for the csn. I think that is what
> kills the consumer. I don't have a clue why the provider does that.
>
> I have provided a network trace (in pcap format) of the exchange,
> leaving out the handshake and bind request message to avoid password
> disclosure. Unless I'm mistaken, the refreshDeletes flag of the
> intermediate message is set to TRUE, indicating multiple deletes
> (right?). This fits well with the rare case of the consumer deleting all
> its entries (which I have not been able to get logs of so far).
>
> From the usual use of our provider server I would have expected zero or
> one changes within the poll interval, and definitely no deleted objects.
> So the fact that the provider is trying to send a sync id set at all
> and flag it as deletes looks suspicious to me. The test consumer server
> has never logged such an intermediate message as reaction to a
> synchronization search except in these fatal cases, for the few days
> that it has been running debug enabled now.
>
> Now I hope that someone has an idea about what might be going wrong in
> the provider server. I can just speculate that the problems we observe
> are symptoms of a deeper problem.
>
> Some software versions:
>
> slapd: 2.4.7-3
> libc6: 2.7-6
> libdb4.2: 4.2.52+dfsg-4
> libgnutls13: 2.0.4-1
> libiodbc2: 3.52.6-1
> libldap-2.4-2: 2.4.7-3
>
> Attached files:
>
> slapd.conf.keldon - provider configuration file
> slapd.conf.gorkon - test consumer configuration file
> slapd.crash.capture - network trace of the consumer - provider
>                     communication while performing the deadly replication
> slapd.crash.strace - syscall trace of the consumer at the same time
> slapd.crash.log -   debug log of the consumer, levels
>                     sync+stats+acl+trace, at the same time
> provider.log -      debug log of the provider, levels sync+stats+trace,
>                     at a later deadly replication
>
> Sincerely,
>    Ralph Rößner
>
> --
> Ralph Rößner
> CAPCom AG < http://www.capcom.de >
> Rundeturmstr. 10, 64283 Darmstadt, Germany
> Phone +49 6151 155 900, Fax +49 6151 155 909
>
> Vorstand: Luc Neumann (Vorsitzender)
> Vorsitzender des Aufsichtsrats: Prof. Dr.-Ing. José L. Encarnação
> Sitz der Gesellschaft: Darmstadt, Registergericht: Darmstadt HRB 8090



--

Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra ::  the leader in open source messaging and collaboration




Tags added: upstream Request was from Steve Langasek <vorlon@debian.org> to control@bugs.debian.org. (Sat, 09 Feb 2008 20:24:07 GMT) Full text and rfc822 format available.

Noted your statement that Bug has been forwarded to http://www.openldap.org/its/index.cgi/?findid=5362. Request was from Steve Langasek <vorlon@debian.org> to control@bugs.debian.org. (Sat, 09 Feb 2008 20:24:08 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian OpenLDAP Maintainers <pkg-openldap-devel@lists.alioth.debian.org>:
Bug#464024; Package slapd. Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian OpenLDAP Maintainers <pkg-openldap-devel@lists.alioth.debian.org>. Full text and rfc822 format available.

Message #19 received at 464024@bugs.debian.org (full text, mbox):

From: Russ Allbery <rra@debian.org>
To: 464024@bugs.debian.org
Subject: Fwd: (ITS#5362) syncrepl provider kills consumer by sending truncated cookie
Date: Sat, 09 Feb 2008 21:10:39 -0800
[Message part 1 (text/plain, inline)]
Forwarding here for reference.

[Message part 2 (message/rfc822, inline)]
From: hyc@symas.com
To: openldap-its@openldap.org
Subject: Re: (ITS#5362) syncrepl provider kills consumer by sending truncated cookie
Date: Sun, 10 Feb 2008 05:04:22 GMT
quanah@OpenLDAP.org wrote:
> Full_Name: Quanah Gibson-Mount
> Version: 2.4.7
> OS:
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (24.23.156.219)
>
>
> As reported in the Debian BTS, and Howard has seen this as well:
>
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=464024

I saw a similar problem while investigating ITS#5332. While ldapadd'ing 1000 
entries I saw several instances where a cookie was sent without a CSN. It 
didn't result in a crash though. After sprinkling some assert's in the code I 
think I've identified the problem, and the current code in HEAD no longer 
triggers any of the assert's that I used. But I'm not certain that the 
behavior I was chasing is the same as in this bug report. Please test and 
report your results.
-- 
   -- Howard Chu
   Chief Architect, Symas Corp.  http://www.symas.com
   Director, Highland Sun        http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP     http://www.openldap.org/project/

Information forwarded to debian-bugs-dist@lists.debian.org, Debian OpenLDAP Maintainers <pkg-openldap-devel@lists.alioth.debian.org>:
Bug#464024; Package slapd. Full text and rfc822 format available.

Acknowledgement sent to Ralph Rößner <roessner@capcom.de>:
Extra info received and forwarded to list. Copy sent to Debian OpenLDAP Maintainers <pkg-openldap-devel@lists.alioth.debian.org>. Full text and rfc822 format available.

Message #24 received at 464024@bugs.debian.org (full text, mbox):

From: Ralph Rößner <roessner@capcom.de>
To: 464024@bugs.debian.org
Subject: Update: backtrace of dead consumer
Date: Tue, 26 Feb 2008 16:56:19 +0100
Hi,

after spending some time trying - without success - to reproduce my
problems with a test producer slapd, I switched my test consumer back to
the production producer and was able to capture another consumer SEGV.
This time my gdb was ready for it, so here is the backtrace:


0xb7c6f590 in pthread_join () from /lib/libpthread.so.0
(gdb) cont
Continuing.
[New Thread 0xb53dcb90 (LWP 17602)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb69eab90 (LWP 10148)]
0x080caa7a in compare_csns (sc1=0xb69e9c00, sc2=0xb69e9c20, which=0xb69e9cf4)
    at /build/buildd/openldap2.3-2.4.7/servers/slapd/syncrepl.c:668
668     /build/buildd/openldap2.3-2.4.7/servers/slapd/syncrepl.c: No such file or directory.
        in /build/buildd/openldap2.3-2.4.7/servers/slapd/syncrepl.c
(gdb) bt
#0  0x080caa7a in compare_csns (sc1=0xb69e9c00, sc2=0xb69e9c20, 
    which=0xb69e9cf4)
    at /build/buildd/openldap2.3-2.4.7/servers/slapd/syncrepl.c:668
#1  0x080d2e42 in do_syncrep2 (op=0xb69e9d8c, si=0x81f4e88)
    at /build/buildd/openldap2.3-2.4.7/servers/slapd/syncrepl.c:1012
#2  0x080d375b in do_syncrepl (ctx=0xb69ea248, arg=0x81f4190)
    at /build/buildd/openldap2.3-2.4.7/servers/slapd/syncrepl.c:1207
#3  0xb7ec2a44 in ?? () from /usr/lib/libldap_r-2.4.so.2
#4  0xb69ea248 in ?? ()
#5  0x081f4190 in ?? ()
#6  0x00000000 in ?? ()
(gdb) 


The relevant syslog entries from the consumer machine show up the empty
csn again:


Feb 25 08:54:26 gorkon-test2 slapd[10145]: =>do_syncrepl rid=001 
Feb 25 08:54:26 gorkon-test2 slapd[10145]: =>do_syncrep2 rid=001 
Feb 25 08:54:26 gorkon-test2 slapd[10145]: do_syncrep2: rid=001 LDAP_RES_SEARCH_
RESULT 
Feb 25 08:56:26 gorkon-test2 slapd[10145]: =>do_syncrepl rid=001 
Feb 25 08:56:26 gorkon-test2 slapd[10145]: =>do_syncrep2 rid=001 
Feb 25 08:56:26 gorkon-test2 slapd[10145]: do_syncrep2: rid=001 LDAP_RES_INTERME
DIATE - SYNC_ID_SET 
Feb 25 08:56:26 gorkon-test2 slapd[10145]: do_syncrep2: cookie=rid=001,csn= 
Feb 25 09:13:46 gorkon-test2 -- MARK --


Note that this is on both ends of the connection package version
2.4.7-4, not -3 as in the original post.

Sincerely,
   Ralph Rößner

-- 
Ralph Rößner
CAPCom AG < http://www.capcom.de >
Rundeturmstr. 10, 64283 Darmstadt, Germany
Phone +49 6151 155 900, Fax +49 6151 155 909

Vorstand: Luc Neumann (Vorsitzender)
Vorsitzender des Aufsichtsrats: Prof. Dr.-Ing. José L. Encarnação
Sitz der Gesellschaft: Darmstadt, Registergericht: Darmstadt HRB 8090




Information forwarded to debian-bugs-dist@lists.debian.org, Debian OpenLDAP Maintainers <pkg-openldap-devel@lists.alioth.debian.org>:
Bug#464024; Package slapd. Full text and rfc822 format available.

Acknowledgement sent to Quanah Gibson-Mount <quanah@zimbra.com>:
Extra info received and forwarded to list. Copy sent to Debian OpenLDAP Maintainers <pkg-openldap-devel@lists.alioth.debian.org>. Full text and rfc822 format available.

Message #29 received at 464024@bugs.debian.org (full text, mbox):

From: Quanah Gibson-Mount <quanah@zimbra.com>
To: Ralph Rößner <roessner@capcom.de>, 464024@bugs.debian.org
Subject: Re: [Pkg-openldap-devel] Bug#464024: Update: backtrace of dead consumer
Date: Tue, 26 Feb 2008 13:04:04 -0800
This is believed fixed in OpenLDAP 2.4.8.  Hopefully there'll be debian 
packages for that soon.

--Quanah

--On Tuesday, February 26, 2008 4:56 PM +0100 Ralph Rößner 
<roessner@capcom.de> wrote:

> Hi,
>
> after spending some time trying - without success - to reproduce my
> problems with a test producer slapd, I switched my test consumer back to
> the production producer and was able to capture another consumer SEGV.
> This time my gdb was ready for it, so here is the backtrace:
>
>
> 0xb7c6f590 in pthread_join () from /lib/libpthread.so.0
> (gdb) cont
> Continuing.
> [New Thread 0xb53dcb90 (LWP 17602)]
>
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0xb69eab90 (LWP 10148)]
> 0x080caa7a in compare_csns (sc1=0xb69e9c00, sc2=0xb69e9c20,
> which=0xb69e9cf4)     at
> /build/buildd/openldap2.3-2.4.7/servers/slapd/syncrepl.c:668 668
> /build/buildd/openldap2.3-2.4.7/servers/slapd/syncrepl.c: No such file or
> directory.         in
> /build/buildd/openldap2.3-2.4.7/servers/slapd/syncrepl.c (gdb) bt
># 0  0x080caa7a in compare_csns (sc1=0xb69e9c00, sc2=0xb69e9c20,
>     which=0xb69e9cf4)
>     at /build/buildd/openldap2.3-2.4.7/servers/slapd/syncrepl.c:668
># 1  0x080d2e42 in do_syncrep2 (op=0xb69e9d8c, si=0x81f4e88)
>     at /build/buildd/openldap2.3-2.4.7/servers/slapd/syncrepl.c:1012
># 2  0x080d375b in do_syncrepl (ctx=0xb69ea248, arg=0x81f4190)
>     at /build/buildd/openldap2.3-2.4.7/servers/slapd/syncrepl.c:1207
># 3  0xb7ec2a44 in ?? () from /usr/lib/libldap_r-2.4.so.2
># 4  0xb69ea248 in ?? ()
># 5  0x081f4190 in ?? ()
># 6  0x00000000 in ?? ()
> (gdb)
>
>
> The relevant syslog entries from the consumer machine show up the empty
> csn again:
>
>
> Feb 25 08:54:26 gorkon-test2 slapd[10145]: =>do_syncrepl rid=001
> Feb 25 08:54:26 gorkon-test2 slapd[10145]: =>do_syncrep2 rid=001
> Feb 25 08:54:26 gorkon-test2 slapd[10145]: do_syncrep2: rid=001
> LDAP_RES_SEARCH_ RESULT
> Feb 25 08:56:26 gorkon-test2 slapd[10145]: =>do_syncrepl rid=001
> Feb 25 08:56:26 gorkon-test2 slapd[10145]: =>do_syncrep2 rid=001
> Feb 25 08:56:26 gorkon-test2 slapd[10145]: do_syncrep2: rid=001
> LDAP_RES_INTERME DIATE - SYNC_ID_SET
> Feb 25 08:56:26 gorkon-test2 slapd[10145]: do_syncrep2:
> cookie=rid=001,csn=  Feb 25 09:13:46 gorkon-test2 -- MARK --
>
>
> Note that this is on both ends of the connection package version
> 2.4.7-4, not -3 as in the original post.
>
> Sincerely,
>    Ralph Rößner
>
> --
> Ralph Rößner
> CAPCom AG < http://www.capcom.de >
> Rundeturmstr. 10, 64283 Darmstadt, Germany
> Phone +49 6151 155 900, Fax +49 6151 155 909
>
> Vorstand: Luc Neumann (Vorsitzender)
> Vorsitzender des Aufsichtsrats: Prof. Dr.-Ing. José L. Encarnação
> Sitz der Gesellschaft: Darmstadt, Registergericht: Darmstadt HRB 8090
>
>
>
> _______________________________________________
> Pkg-openldap-devel mailing list
> Pkg-openldap-devel@lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/pkg-openldap-devel



--

Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra ::  the leader in open source messaging and collaboration




Tags added: fixed-upstream Request was from Steve Langasek <vorlon@debian.org> to control@bugs.debian.org. (Tue, 26 Feb 2008 21:51:07 GMT) Full text and rfc822 format available.

Tags added: pending Request was from matthijs@alioth.debian.org to control@bugs.debian.org. (Sun, 25 May 2008 18:30:16 GMT) Full text and rfc822 format available.

Tags added: pending Request was from rra@alioth.debian.org to control@bugs.debian.org. (Mon, 26 May 2008 18:21:09 GMT) Full text and rfc822 format available.

Reply sent to Matthijs Mohlmann <matthijs@cacholong.nl>:
You have taken responsibility. Full text and rfc822 format available.

Notification sent to Ralph Rößner <roessner@capcom.de>:
Bug acknowledged by developer. Full text and rfc822 format available.

Message #40 received at 464024-close@bugs.debian.org (full text, mbox):

From: Matthijs Mohlmann <matthijs@cacholong.nl>
To: 464024-close@bugs.debian.org
Subject: Bug#464024: fixed in openldap2.3 2.4.9-1
Date: Mon, 26 May 2008 21:17:08 +0000
Source: openldap2.3
Source-Version: 2.4.9-1

We believe that the bug you reported is fixed in the latest version of
openldap2.3, which is due to be installed in the Debian FTP archive:

ldap-utils_2.4.9-1_i386.deb
  to pool/main/o/openldap2.3/ldap-utils_2.4.9-1_i386.deb
libldap-2.4-2-dbg_2.4.9-1_i386.deb
  to pool/main/o/openldap2.3/libldap-2.4-2-dbg_2.4.9-1_i386.deb
libldap-2.4-2_2.4.9-1_i386.deb
  to pool/main/o/openldap2.3/libldap-2.4-2_2.4.9-1_i386.deb
libldap2-dev_2.4.9-1_i386.deb
  to pool/main/o/openldap2.3/libldap2-dev_2.4.9-1_i386.deb
openldap2.3_2.4.9-1.diff.gz
  to pool/main/o/openldap2.3/openldap2.3_2.4.9-1.diff.gz
openldap2.3_2.4.9-1.dsc
  to pool/main/o/openldap2.3/openldap2.3_2.4.9-1.dsc
openldap2.3_2.4.9.orig.tar.gz
  to pool/main/o/openldap2.3/openldap2.3_2.4.9.orig.tar.gz
slapd-dbg_2.4.9-1_i386.deb
  to pool/main/o/openldap2.3/slapd-dbg_2.4.9-1_i386.deb
slapd_2.4.9-1_i386.deb
  to pool/main/o/openldap2.3/slapd_2.4.9-1_i386.deb



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 464024@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Matthijs Mohlmann <matthijs@cacholong.nl> (supplier of updated openldap2.3 package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.8
Date: Mon, 26 May 2008 22:34:16 +0200
Source: openldap2.3
Binary: slapd ldap-utils libldap-2.4-2 libldap-2.4-2-dbg libldap2-dev slapd-dbg
Architecture: source i386
Version: 2.4.9-1
Distribution: unstable
Urgency: low
Maintainer: matthijs@cacholong.nl
Changed-By: Matthijs Mohlmann <matthijs@cacholong.nl>
Description: 
 ldap-utils - OpenLDAP utilities
 libldap-2.4-2 - OpenLDAP libraries
 libldap-2.4-2-dbg - Debugging information for OpenLDAP libraries
 libldap2-dev - OpenLDAP development libraries
 slapd      - OpenLDAP server (slapd)
 slapd-dbg  - Debugging information for the OpenLDAP server (slapd)
Closes: 414650 457261 464024 464877 465875 466558 471225 471792 471867 474161 474652 474976 475238 475744 475856 477718 479237 480138 480172 480177 480181 480218 480247 481126 481214 483014
Changes: 
 openldap2.3 (2.4.9-1) unstable; urgency=low
 .
   [ Updated debconf translations ]
   * French, thanks to Christian Perrier <bubulle@debian.org>.
     Closes: #471792.
   * Finnish, thanks to Esko Arajärvi <edu@iki.fi>.  Closes: #475238.
   * Czech, thanks to Miroslav Kure <kurem@upcase.info.upol.cz>.
     Closes: #480138.
   * Basque, thanks to Piarres Beobide <pi+debian@beobide.net>.
     Closes: #480177.
   * Vietnamese, thanks to Clytie Siddall <clytie@riverland.net.au>.
     Closes: #480181.
   * Galician, thanks to Jacobo Tarrio <jtarrio@trasno.net>.  Closes: #480218.
   * Japanese, thanks to Kenshi Muto <kmuto@debian.org>.  Closes: #480247.
   * Italian, thanks to Luca Monducci <luca.mo@tiscali.it>. (Closes: #477718)
   * Brazilian Portuguese, thanks to Eder L. Marques <eder@edermarques.net>
     (Closes: #480172)
   * Portuguese, thanks to Tiago Fernandes <tjg.fernandes@gmail.com>
     (Closes: #481126)
   * Russian, thanks to Yuri Kozlov <kozlov.y@gmail.com> (Closes: #481214)
   * Dutch, thanks to "cobaco (aka Bart Cornelis)" <cobaco@skolelinux.no>.
     Closes: #483014.
 .
   [ Matthijs Mohlmann ]
   * New upstream release.
     - Bad entryUUID no longer crashes slapd.  (Closes: #471867)
     - Fix assertion failure in some modify operations.  (Closes: #474161)
     - Mention index in slapd.conf's man page.  (Closes: #414650)
     - Fixes to slapd include handling.  (Closes: #457261)
     - Fix syncrepl cookie truncation.  (Closes: #464024)
     - Fix memory allocation in ldap_parse_page_control.  (Closes: #464877)
     - Fix slapd crash when accessed by multiple threads.  (Closes: #479237)
   * Acknowledge NMU.
     (Closes: #474976, #471225, #475856, #474652, #465875)
   * Bump Standards-Version to 3.7.3
   * Add versioned build dependency on libgnutls-dev (Closes: #466558)
 .
   [ Russ Allbery ]
   * Use MAXPATHLEN rather than PATH_MAX, since OpenLDAP defines the
     former and the latter isn't defined on GNU Hurd.  Thanks, Samuel
     Thibault.  (Closes: #475744)
Checksums-Sha1: 
 c7ea33e93cd797cc983eebe8f41ffa2861d033f3 1828 openldap2.3_2.4.9-1.dsc
 71fee5c280d96efb7e965812500bd11f81eed567 3694611 openldap2.3_2.4.9.orig.tar.gz
 7f450f6ba3f075d1d79e90cc8aa6beab59d9f1b1 147350 openldap2.3_2.4.9-1.diff.gz
 b5ecd137bb3a0224a07c6d00584114b772646ab9 1226112 slapd_2.4.9-1_i386.deb
 5698eded564e9a2944e2f4a413438327bea95753 242400 ldap-utils_2.4.9-1_i386.deb
 dda4e2a31599dfdad3477fba79f1ffdb7c151892 183966 libldap-2.4-2_2.4.9-1_i386.deb
 5022b8ea04fb19fbd4a10e25ecd2cae02478ad0c 280668 libldap-2.4-2-dbg_2.4.9-1_i386.deb
 778621e57cc0618c82417f18adad0a3f1489e38e 768586 libldap2-dev_2.4.9-1_i386.deb
 3000a8ff4dafaa2bfd8720223acb32cd274a7c6a 3543298 slapd-dbg_2.4.9-1_i386.deb
Checksums-Sha256: 
 90f70b5357fa6741a17046e3ee4b727e63d18c057e931345411f60e1d1f252b5 1828 openldap2.3_2.4.9-1.dsc
 06d441c4c81d2e6cd5ef565bd9e89bebf40a4f25dc4592a425a9076e42e533d8 3694611 openldap2.3_2.4.9.orig.tar.gz
 70a6cb2983bb231b35867df076ea1d0116efce6628a5d8697bf7c3ab1bd43466 147350 openldap2.3_2.4.9-1.diff.gz
 88d08a98939287cb61af09eacc83b46f702e18bbfe519e37e6fc100d4a661588 1226112 slapd_2.4.9-1_i386.deb
 091a1fda7669aa2df9e66510fe4b3ef26541b9336662373e021b9b84792c3b7a 242400 ldap-utils_2.4.9-1_i386.deb
 5b644e842165471dee4f36c8ed4b4313d328ff7a851a766ce662037d0b5eb863 183966 libldap-2.4-2_2.4.9-1_i386.deb
 06e25ec042faaec87624f120d8a1283b3a783ca0dba5216efdc907077f53a3fd 280668 libldap-2.4-2-dbg_2.4.9-1_i386.deb
 44f1ecb38dbe3a70b80f8c26713412a57ec6f1c390f99d5e39d19f3ad4dd283e 768586 libldap2-dev_2.4.9-1_i386.deb
 d889317dd4c22639cf3ad8c633782741d61790c584a3217050e96c7eedcd1bc7 3543298 slapd-dbg_2.4.9-1_i386.deb
Files: 
 0ad5a4e1fba16615152d15044b66bfa1 1828 net optional openldap2.3_2.4.9-1.dsc
 3c0b5ae3d45f5675e67aaf81ce7decc9 3694611 net optional openldap2.3_2.4.9.orig.tar.gz
 0ec2c9c7376e6dce90b058d68f1e9761 147350 net optional openldap2.3_2.4.9-1.diff.gz
 cf260840bed1fe98fc1e1c3766ace478 1226112 net optional slapd_2.4.9-1_i386.deb
 b24255f71b5b584084c11fac71327baf 242400 net optional ldap-utils_2.4.9-1_i386.deb
 92340cc78cf63eb764d2e27f057b9596 183966 libs optional libldap-2.4-2_2.4.9-1_i386.deb
 6596e12d4b7ec8f5558aa25c0711bcbb 280668 libdevel extra libldap-2.4-2-dbg_2.4.9-1_i386.deb
 2a04718f661399b77071790d060dc4ca 768586 libdevel extra libldap2-dev_2.4.9-1_i386.deb
 b1fa8469114c739e49ebadad631b194f 3543298 net extra slapd-dbg_2.4.9-1_i386.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFIOyTX2n1ROIkXqbARAoYFAJ98TY8Xr78aWMUPa6zbaiIpSiotgQCfeEtN
/3Aa7QCEQkz/tlKqSEE1XAc=
=vs7O
-----END PGP SIGNATURE-----





Bug archived. Request was from Debbugs Internal Request <owner@bugs.debian.org> to internal_control@bugs.debian.org. (Sat, 05 Jul 2008 07:29:09 GMT) Full text and rfc822 format available.

Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Sat Apr 19 13:10:46 2014; Machine Name: beach.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.