Re: 2.0.27 replicating to 2.2.15

[Curt Blank <curt@uwm.edu>]

Pierangelo Masarati wrote:

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

No, no problem, I don't either, if it worked this way, unfortunately in 
our environment it doesn't. Some applications, because they don't know 
how to handle a referral if they got one attempting to update a slave 
are hardcoded to go to the Master because they need to do updates, so 
those applications would be offline. (They won't accept a secondary 
server  in the config either.) But, you got me thinking that I could 
temporarily point them at the Slave and still keep the applications 
running for the most part. Going off topic can be good, I never do mind 
when it happens.

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

Thank you, that was the kind of information I was hoping for.

> > (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()).

Thank you for this suggestion, I will look into that.

> 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).

Tell me about it! Getting slapadd to work in the first place 2.0->2.2 
was no cake walk. Many schema changes both to home grown schema and 
vendor supplied, obviously this came as a surprise to many.

But I found this (let the screaming begin):

int       global_schemacheck = 1; /* schemacheck ON is default */

If I were to temporarily:

int       global_schemacheck = 0;

Then turn it back on once all servers were at 2.2, how hosed would I be? 
With it off would
structuralObjectClass still be computed and set for new entries? Or any 
entries for that matter?

Thanks again for the reply.

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