Re: 2.0.27 replicating to 2.2.15

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

Curt Blank wrote:

> 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 principle (although possibly going off-topic), I don't see a big 
problem in temporarily shutting down the master, because the read 
service is guaranteed by the slaves.  Only writes are temporarily 
disabled, but I'd consider it a minor limitation, given the extent of 
the changes you're working at.  But I understant that's not my business.

> > 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?

It should.  I vaguely remember trying (just for fun) but it worked.  
Note that 2.2 is also replicating entryUUID and entryCSN, which 2.0 is 
not aware of.

> (Short term.) Should there be a structuralObjectClass: account 
> associated with every dn in the database or is that just used for 
> replication protocol?

The structuralObjectClass attribute is operational; it's computed by 
selecting the structural objectClass in the objectClass chain of the entry.

> 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?

In principle, you could have the structuralObjectClass computed as it is 
for regular adds.  I wouldn't see this as a critical issue, and this 
should be an easy hack.  Just look at where it's computed for regular 
adds (I think it's computed by mods_structural_class() in 
slap_mods_opattrs()).

My main concern is that 2.0 was quite loose in schema compliance checks 
if compared to 2.2; so writes coming from the 2.0 master might fail some 
check (e.g. if more than one structuralObjectClass is defined, which was 
tolerated in 2.0, mods_structural_class() in 2.2 will barf).

> 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?


Slapd needs it, but you shouldn't bother with it, except when you design 
your entry and decide what objectClasses it will be based upon.  Hope I 
clarified a bit the issue.

p.


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