[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: 2.0.27 replicating to 2.2.15
At 02:06 PM 3/23/2005, Curt Blank wrote:
>Thank you for your reply.
>
>Yeah I was leaning towards one of your three solutions as a temporary fix so I could do the upgrade. Before I attempt it though (already been looking at the code) and target the structuralObjectClass issue and optimistically say successfully address it, anything else then going to bite me in the butt?
The problem with your upgrade approach, as I see it, is that the
2.0 server may not only have bad data in it, clients may
continually be adding bad data to it. So, even if you were to
modify slurpd(8) (I don't recommend solutions (1) or (3)) to
generate structualObjectClass values, you have to deal data for
which slurpd(8) can deal with programmatically.
I recommend (2) over (1) and (3) because it keeps the (temporary)
hacks out of the servers. I recommend against (3) as that would
lead to the hacks becoming permanent, it would (in effect) back
out many of the data consistency bug fixes that 2.2 was intended
to address.
Personally, I prefer to either replacing everything at once
(which can be done quite quickly if necessary... and, if done
right, allows for switching back if something were to go wrong)
or to replace master first.
Kurt
>Kurt D. Zeilenga wrote:
>
>>At 12:44 PM 3/23/2005, 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. 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)
>>>
>>>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.
>>>
>>>So, anyone know if making the updatedn and rootdn different will solve this problem?
>>>
>>
>>The problem has nothing to do with the updatedn and the rootdn.
>>
>>2.0 simply does not produce everything that 2.2 expects to be
>>present in the replication stream. There are three obvious
>>solutions to this problem.
>> 1) modify the 2.0 slapd(8) to provide what 2.2 slapd(8) expects.
>> 2) modify the 2.0 or 2.2 slurpd to provide what 2.2 slapd(8) expects.
>> 3) modify the 2.2 slapd(8) not to require information not provided
>> by the 2.0 slapd(8).
>>
>>The devil is in the details, of course.
>>
>>Kurt