We just finished updating our KDC infra to 1.13.2 and I noticed this today.
It was a very quiet day and, after a test "kproplog -R" on the master to make
sure iprop_resync_timeout was sufficient (it was) all the slaves did two
FULL_RESYNCs (I know why; I'm looking forward to 1.14) and then a couple of
incremental updates came though.
For the next 8 hours and a bit, "kpropog -h’ on the master reported this:
Kerberos update log (/var/krb5/krb5kdc/principal.ulog)
Update log dump :
Log version # : 1
Log state : Stable
Entry block size : 2048
Number of entries : 2
First serial # : 1
Last serial # : 2
First time stamp : Sat Jul 18 13:05:57 2015
Last time stamp : Sat Jul 18 13:12:14 2015
A change came in at 21:30 and this seems to have reset the ulog in some way:
Kerberos update log (/var/krb5/krb5kdc/principal.ulog)
Update log dump :
Log version # : 1
Log state : Stable
Entry block size : 4096
Number of entries : 2
First serial # : 3
Last serial # : 4
First time stamp : Sat Jul 18 21:30:17 2015
Last time stamp : Sat Jul 18 21:30:17 2015
(these updates were a kadm5_chpass_principal and a kadm5_modify_principal, if
that matters)
The iprop requests that came in immediately after this were FULL_RESYNCs (only
one for each slave this time). A subsequent update made it to the slaves in the
usual, incremental, way.
Any idea what caused the full resyncs on such a quiet day? Nothing in the logs
sheds any light on this for me and a glance over lib/kdb/kdb_log.c left me none
the wiser.
jd
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
