Re: 2.0.27 replicating to 2.2.15

[Pierangelo Masarati <ando@sys-net.it>]

Curt Blank wrote:

> I've got a 2.0.27 server set up as Master replicating via slurp to a 
> 2.2.15 slave server.

In general, replicating across etherogeneous servers is a bad idea, but 
read thru the whole answer.

> Modifications are being replicated properly but adds are not, the new 
> dn is not added, I see this error message:
>
> bdb_add: entry failed schema check: no structuralObjectClass 
> operational attribute (80)

because 2.2 slaves expect the operational attr structuralObjectClass to 
be passed for adds.

> Unfortunately I do have updatedn and rootdn set the same. I see in the 
> 2.2 documentation that shouldn't be done but the existing environment 
> is 2.0 and it was not a constraint there, at least according to the 
> the 2.0 Admin Manual.

That's a suggestion for security's sake, not a constraint.

> So, anyone know if making the updatedn and rootdn different will solve 
> this problem?

No, it's totally unrelated.

> And the intention is to replace the 2.0 Master with the 2.2 server as 
> Master then the 2.2 Master will be replicating to 2.0 servers until 
> they are upgraded to 2.2. It is being done this way as a rolling 
> upgrade because we cannot afford the luxury of an ldap outage.


The other way round, i.e. a 2.2 master replicating to 2.0 slaves should 
be easier because in 2.2 you can filter out the operational attributes 
that the 2.2 master routinely generates but earlier slaves wouldn't 
accept.  The topic has already been iscussed, you may find something by 
browsing the mail archives.  In any case, you need to look at the "attr" 
parameter of the "replica" statement in 2.2's slapd.conf(5) man page.


   SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497