krb5 1.13 Replication enhancements

Richard Basch basch at
Wed Oct 1 21:22:26 EDT 2014

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



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


Notify downstream slaves of pending ulog updates



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

From: Richard Basch [ <mailto:basch at> mailto:basch at]

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

To: 'Greg Hudson'; 'tlyu at'

Cc: 'kayla.c.harrison at'

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> mailto:ghudson at]

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

To: Richard Basch;  <mailto:tlyu at> tlyu at

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

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



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.


More information about the krbdev mailing list