[Date Prev][Date Next]
Re: top-level data entries not replicating, 2.4.15, now 2.4.17
- To: firstname.lastname@example.org
- Subject: Re: top-level data entries not replicating, 2.4.15, now 2.4.17
- From: Brian Neu <email@example.com>
- Date: Fri, 21 Aug 2009 08:52:42 -0700 (PDT)
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1250869962; bh=Va+6PJMGKKM9+a02s7/EaECtbL2mfxOpe79pa3aYx1U=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Zp6oFj1H+tI+w554rkU9huwyBJ+fvTTQUAhicBL8LX+itAX4wjnylgfoajQvHCWLkj50+SmgT0aAwSxIJSnml6DuMPL7Ox8Sx4s29IOPjgDfM5+1wfKJMbY5r+uhxy+c5aFqKA5MgnonyWhOZK3M7PjCbrbGBmftrRym/Ypw+Ck=
- Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=OuduSz5G06dEa6BSHsgEqwGxc/0Q5sPcgxg6Ws8Wvu2bFVN2QJXiajXidP1jv2toahJLL+Qqzfz+BuPIqsk4pn0QFqrw9xfIyaBDXN+cS+BTHzvPiTduxDNMjGfBMn8zPEzg/TbKl9Tw+N4AZMA4nprX4IP2DzZt65xg9DdZY7I=;
- In-reply-to: <firstname.lastname@example.org>
I really only created the test2 record to find out why the
record wasn't replicating.
This entry won't replicate either, even with a cn attribute . . .
--- On Fri, 8/21/09, Brett @Google <email@example.com> wrote:
> From: Brett @Google <firstname.lastname@example.org>
> Subject: Re: top-level data entries not replicating, 2.4.15, now 2.4.17
> To: email@example.com
> Date: Friday, August 21, 2009, 10:28 AM
> On Sat, Aug 22,
> 2009 at 12:18 AM, Brian Neu <firstname.lastname@example.org>
> I compiled new rpms and upgraded to 2.4.17 on both the
> provider and consumer. The problem persists.
> New entries like:
> objectclass: top
> objectclass: person
> If this is literally correct, there is no cn attribute
> (although it is referred to in the dn) ?
> This would not b considered valid with respect to
> the schema, and as such ignored during replication. I would
> think to get it to slapadd in the first place, schema
> validation would need to have been turned off.
> The other entry you quoted, has a cn value.