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

Re: 2.0.27 replicating to 2.2.15

Thank you for the reply.

Pierangelo Masarati wrote:

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.

This was only temporary. In order to convert the backend to Berkley I did a slapcat/slapadd and was using replication across the versions to keep the 2.2 server up to date until it could be placed in service as the master. However I see now that did not work. Problem is, I cannot afford the downtime to slapadd the new 2.2 master.

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.

Thanks. I will work towards changing that but at least I know it is not my problem.

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.

This is the intent for only as long as it takes to rotate in slaves upgraded to 2.2 once the Master was at 2.2. So, will attr!=structuralObjectClass work when replicating from a 2.2 Mater to a 2.0 Salve? (Short term.) Should there be a structuralObjectClass: account associated with every dn in the database or is that just used for replication protocol?

To be able to get the 2.2 server running temporarily as a slave so I can slapadd it and then get replication from the 2.0 server, how hard/risky would it be for me to modify the code so that the 2.2 server bypasses this requirement? (Temporarily, until it is installed as the Master.) Or would this not be recommended at all?

Just as a sidebar, I was wondering if you would explain why this structuralObjectClass: account for replication was added? Is it something I really need?

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