Re: Occasional corrupt DN in be_add logs under 2.4.16

To: Howard Chu <hyc@symas.com>

Subject: Re: Occasional corrupt DN in be_add logs under 2.4.16

From: Sean Burford <unix.gurus@gmail.com>

Date: Wed, 6 May 2009 12:43:49 -0700

Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:cc:content-type; bh=2PYSiq6kzJTtjlRyefdLB8tcQhV6EkO9du/Ryg8jWTw=; b=IfF7iZmfy/kVaIwNjNQFe3Avb6KAKGRHB3ln/s32bhf33ZKH4VnNnvRuFvqFN8FNnG zrm37WjDLVmbiau9ORbrAylJFmPv2Im14wsxE3eDZrd/9yOxqjaZSzaeEdNsP0KsAFgS KvWlGlyDHQQUOjKkg8cnxDlKDq/OSjUF4HdJo=

Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=Zai7WngS3YkMew/YUytUIL7JYass/AA+xCYgj9oXenp+8JeVJC6OiTXm+EN+13mSlE GMH6IlVRi2kG2ZtskQdStwq7tUYhEuPgtr/vwMQESOYhpM84CRq0dbH7r6Igl3lhJuUl tAPKDaMqNw+yxEQD+hTGL0EMb6VCglYXEjtcM=

In-reply-to: <4A009B0C.8010803@symas.com>

References: <ebfa01ed0905051237p5b13e7efjf490ac2253ba9319@mail.gmail.com> <4A0098F7.1090000@symas.com> <ebfa01ed0905051255w1bf4305dj3f64c0c7d162c543@mail.gmail.com> <4A009B0C.8010803@symas.com>

On Tue, May 5, 2009 at 1:01 PM, Howard Chu <hyc@symas.com> wrote:

Sean Burford wrote:

On Tue, May 5, 2009 at 12:52 PM, Howard Chu <hyc@symas.com
<mailto:hyc@symas.com>> wrote:

Sean Burford wrote:

slapcat shows no problems with the entry on the 2.4.16 host.

Since the database looks fine I wonder if this is just a logging
issue.
Should this Debug statement in syncrepl.c actually use
op->ora_e->e_name.bv_val or some other attribute?

Looks like a side-effect of ITS#5326. And no, you can't use
op->ora_e because the backend may free it before returning
(back-bdb/hdb definitely do).

Do you agree that this looks like a logging issue rather than a database
issue?

Yes, and it is fixed now in HEAD.

I've got three 2.4.16 servers running with the patched add.c from head. They are replicating from the 2.3.43 server. One of them logged this today (the other two logged the correct DN) indicating that this is still an issue:

May 6 12:10:27 ldapserver slapd[29037]: syncrepl_message_to_op: rid=100 be_add µ-ESCxxxxxxxxxx,ou=people,dc=example,dc=com (0)

4 characters were lost (uid=) under the µ-ESC. xxxxxxxxxx masks the uid.

For reference I've attached the patch I used.

Possible patch for "Occasional corrupt DN in be_add logs under 2.4.16" from OpenLDAP CVS. Should already be provided in upstream 2.4.17+. --- servers/slapd/back-bdb/add.c.orig 2009-03-05 10:40:00.000000000 -0800 +++ servers/slapd/back-bdb/add.c 2009-05-05 13:19:06.728827000 -0700 @@ -1,5 +1,5 @@ /* add.c - ldap BerkeleyDB back-end add routine */ -/* $OpenLDAP: pkg/ldap/servers/slapd/back-bdb/add.c,v 1.152.2.17 2009/03/05 18:40:00 quanah Exp $ */ +/* $OpenLDAP: /servers/slapd/back-bdb/add.c,v 1.183 2009/05/05 19:54:01 hyc Exp $ */ /* This work is part of OpenLDAP Software <http://www.openldap.org/>. * * Copyright 2000-2009 The OpenLDAP Foundation. @@ -293,6 +293,27 @@ retry: /* transaction retry */ /* free parent and reader lock */ if ( p != (Entry *)&slap_entry_root ) { + if ( p->e_nname.bv_len ) { + struct berval ppdn; + + /* ITS#5326: use parent's DN if differs from provided one */ + dnParent( &op->ora_e->e_name, &ppdn ); + if ( !dn_match( &p->e_name, &ppdn ) ) { + struct berval rdn; + struct berval newdn; + + dnRdn( &op->ora_e->e_name, &rdn ); + + build_new_dn( &newdn, &p->e_name, &rdn, NULL ); + if ( op->ora_e->e_name.bv_val != op->o_req_dn.bv_val ) + ber_memfree( op->ora_e->e_name.bv_val ); + op->ora_e->e_name = newdn; + + /* FIXME: should check whether + * dnNormalize(newdn) == e->e_nname ... */ + } + } + bdb_unlocked_cache_return_entry_r( bdb, p ); } p = NULL;