krb5 1.13 Replication enhancements

[Richard Basch]

I have uploaded my commits to github (I am still testing, but I am
reasonably in my git commit)

See https://github.com/rbasch/krb5/wiki/1.13-Replication-enhancements

 

Basically, this uplifts the 1.13-beta1 code base to the same level as I
previously provided as an enhancement for 1.12, specifically:

- Do not require the DB first_sno to be present in the ulog (this avoids
extraneous db resyncs to downstream slaves)

- Implement downstream slave notification when ulog is updated.

 

The following are my GIT commits, but it may be better to reference the
commits via the wiki in case I have to apply another fix and rebase.

 

Allow kdb_first_* not to be present in the ulog

https://github.com/rbasch/krb5/commit/ce238c4a19e117caedc7ce53f4780270b86d52
1c      

 

Notify downstream slaves of pending ulog updates

https://github.com/rbasch/krb5/commit/db0c450f6c09f4623bff3c3aff16794ba4e2c7
63      

 

 

-----Original Message-----

From: Richard Basch [ <mailto:basch at alum.mit.edu> mailto:basch at alum.mit.edu]

Sent: Tuesday, September 30, 2014 3:26 PM

To: 'Greg Hudson'; 'tlyu at mit.edu'

Cc: 'kayla.c.harrison at gmail.com'

Subject: RE: krb5-1.13-beta1 iprop

 

Yeah, re #2... I originally went through all the code which I could find
which pertained to the ulog parsing... the only other change I had was in
kproplog at the time so that it wouldn't overrun a missing entry. I had
added some defensive checks in my original code to only allow for 1 missing
entry, but upon a ulog wrap, it would reset the number.

 

I'll try to re-incorporate all of this...

 

 

-----Original Message-----

From: Greg Hudson [ <mailto:ghudson at mit.edu> mailto:ghudson at mit.edu]

Sent: Tuesday, September 30, 2014 2:58 PM

To: Richard Basch;  <mailto:tlyu at mit.edu> tlyu at mit.edu

Cc:  <mailto:kayla.c.harrison at gmail.com> kayla.c.harrison at gmail.com

Subject: Re: krb5-1.13-beta1 iprop

 

On 09/30/2014 01:30 PM, Richard Basch wrote:

> If you want, I believe I can have patches for 1.13 beta in the next 

> couple days and publish them to github. In essence, there should be no 

> changes to command-line arguments at this point, since you have iprop 

> tree-based propagation already available.

> 

> Will that help?

 

Yes, that will provide a better starting point.

 

> Preliminary testing also suggests that it may be causing an extraneous 

> full resync (I had this problem in one of my early implementations 

> too). I suspect you are resetting the first_sno when you get your 

> first ulog entry (my 1.12 patches avoided resetting the first_sno 

> until it wrapped so that the first "dump/restore" would not be 

> followed by a second one if there were no additional ulog entries to 

> apply).  I am not certain if this is what is going on, but some 

> preliminary testing suggested such (again, I haven't looked at the 

> 1.13

code yet).

 

See item #2 in

 
<http://k5wiki.kerberos.org/wiki/Projects/Hierarchical_iprop#Related_problem
s>
http://k5wiki.kerberos.org/wiki/Projects/Hierarchical_iprop#Related_problems

 

Your implementation had a workaround for this issue, but it broke (at

least) the detection of ulog size changes.  I ran out of time to design a
better workaround.