Re: 2.0.27 replicating to 2.2.15

[Curt Blank <curt@uwm.edu>]

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