[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Migrating from slapd 2.3 to 2.4

--On May 23, 2012 12:52:19 PM +0300 Nick Milas <nick@eurobjects.com> wrote:

On 23/5/2012 6:11 ÏÎ, Quanah Gibson-Mount wrote:

I would generally expect a replica to export the database in the same
order as the master.  But in general, yes, you compare the LDIF
generated by the master and the replica. If the replica is out of
order in relation to the master, you can use the ldifsort perl utility
that's found fairly easily to sort both ldif's into entry order prior
to doing the diff.


This method however would be really feasible only when the whole DIT is
replicated. If a non-root DN is used for replication, then only the parts
of the DIT that are accessible by that DN will be replicated.

Additionally, slapcat outputs operational attributes too, which I think
can not be identical on both ends.

With the exception of perhaps ppolicy overlay, the operational attributes better damn well be identical. ;)

Also, the recommendation is always to use a non-rootDN for replication. I fail to see what that has to do with anything. You can certainly fully replicate the DIT w/o a root DN for replication.

In this case I think slapcat does not offer a solution. Therefore, could
we use:

    ldapsearch -H <provider> -D <dn used on the consumer setup> <filter,
    if used on the consumer setup> -L *


    ldapsearch -H <consumer> -D <root dn> -L *

instead (without operational attrs)?

Is this approach correct?

No.  Again, man slapcat.  It accepts filters too.


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