Re: 2.0.x <--> 2.1.x replication problem

[M Butcher <mbutcher@grcomputing.net>]

For 2.1 -> 2.0, you can use the "attr!=" parameter in the replica
setting in slapd.conf to block those attributes from going to the 2.0
hosts.

For 2.0 -> 2.1... I had to turn of schema checking until I got the
master up to 2.1 status. I guess it didn't hurt, but I don't think I'd
recommend that.

One thing I never tried was simply copying the 2.1 schemas to the 2.0
servers. You'd probably have to slapcat the 2.1 server and slapadd it to
the 2.0 after the update.... I'm not sure... haven't really thought
through that process.

Matt

On Mon, 2003-05-12 at 08:24, Roberto Benedetti wrote:
> Hello everyone.
> 
> I've tried to find out the same problem (and hopefully a solution) on 
> mail-lists, but I was not lucky enough...
> 
> I've been experiencing problems with LDAP replica using software from 
> different distribution branches.
> 
> I could solve the problem of replication from a server running openldap 
> 2.1.17 to a server running openldap 2.0.27 with a (acceptable?) work-around:
> in the replica directive I simply don't allow propagation of attributes 
> that would be unknown for a 2.0.x server's schemas (entryUUID, entryCSN).
> 
> For the opposite direction (a 2.0.x master replicating to a 2.1.x slave) 
> the only work-around (namely: "schemacheck off") I could find is not 
> acceptable since we wish to enforce constraints defined in our own 
> schema files.
> 
> The error I get is
>    "no structuralObjectClass operational attribute".
> 
> Does it mean it is not possible to replicate data in that direction?
> 
> Thanks in advance,
> 
> ---
> 		Roberto Benedetti
-- 
M Butcher <mbutcher@grcomputing.net>