krb5 1.13 Replication enhancements

Richard Basch basch at
Thu Oct 2 20:24:36 EDT 2014

Revised commits (in particular, the second one only differs in the syslog
output generated, not in the core functionality). I was concerned about
excessive logging by kadmind's servicing lots of slaves, so instead of
indicating each slave being notified (which was useful during debugging),
merely indicate the number of slaves being notified (being notified does not
mean they "understand" the notification or will check-in).
1c      first_sno fix
e1      notify slaves


I have also documented an alternate approach to implementing the feature in
my Wiki, but it is far too involved for me to pursue. MIT should decide if
they want to keep the separation of programs as it stands today, in which
case this patch is probably among the better implementations possible.



From: Richard Basch [mailto:basch at] 
Sent: Wednesday, October 1, 2014 9:22 PM
To: 'Greg Hudson'; 'tlyu at'; 'krbdev at'
Cc: 'kayla.c.harrison at'; 'Richard Basch'
Subject: krb5 1.13 Replication enhancements


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