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

Re: 2.0.27 replicating to 2.2.15

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