Re: top-level data entries not replicating, 2.4.15, now 2.4.17

[Quanah Gibson-Mount <quanah@zimbra.com>]

--On Friday, August 21, 2009 5:57 PM -0700 Brian Neu 
<proclivity76@yahoo.com> wrote:

> I do this:
>
>
> [root@victory3 ldap]# /etc/init.d/ldap stop && rm -fr /var/lib/ldap/*.*
> /var/lib/ldap/alock && /etc/init.d/ldap start

Ok, that certainly looks like it is wiping out the database. ;)

> [root@victory3 ldap]# ldapsearch -x -D "cn=Manager,dc=srg,dc=com" -w
> secret -b cn=test3,dc=srg,dc=com
> # extended LDIF
> #
> # LDAPv3
> # base <cn=test3,dc=srg,dc=com> with scope subtree
> # filter: (objectclass=*)
> # requesting: ALL
> #
>
> # search result
> search: 2
> result: 32 No such object
> matchedDN: dc=srg,dc=com
>
> # numResponses: 1


Are you sure replication completed yet?  I'm guessing yes, but ... ;)

> uid=user,ou=People  entries replicate fine, as well as services and
> everything else that came from the migration tools.  But those test
> entries and the SambaDomainName entry at the top level don't replicate.
>
>
> Should I start the consumer with a certain debug level and look into an
> error?
>
> I just started slapd with
>    -s 205 -d 205 2>debug.txt
> after letting it run for a minute, there is no "test2" or "test3" in the
> resulting output, though every other entry is.
>
>
> Should we be looking into the provider?

I'm not sure why you are screwing with the syslog level.  Usually the 
default level is fine.  Have you completely verified that the replicator 
credentials can see those objects on the master?

If that works, then yes, using slapd -d -1 and capturing that to a file may 
indicate why they aren't replicating.

--Quanah


--

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