[krbdev.mit.edu #7058] kpropd issues (1.8.x and probably also 1.9.x)
Richard Basch via RT
rt-comment at krbdev.mit.edu
Sat Dec 31 16:13:34 EST 2011
I have seen kpropd constantly fail and generate lots of
UPDATE_FULL_RESYNC_NEEDED warnings in the kadmin log for a rather "unusual"
case.
Steps to reproduce:
- Setup KDC 1 with data (for realm X)
- Setup KDC 2 for realm X (but not actually tied to KDC 1)
- Setup KDC 3 for realm X using iprop against KDC 2.
- Make modifications, affecting KDC 1.
- Dump KDC1 and load data on KDC2 (kdb5_util dump, kdb5_util load)
Kiprop will begin failing and endlessly cause UPDATE_FULL_RESYNC_NEEDED
messages to be generated. Restarting KDC3 kpropd does not resolve the
problem. To resolve the issue, you must:
1. Make a modification to the database on KDC2 so the kproplog is not
empty.
2. Then restart kpropd on KDC3.
There is apparently an issue with the logic where iprop will fail when the
kproplog is empty. (This is not something one would normally encounter in
production.)
Which then brings me to the following concerns:
#1. if you were to setup a master and then many slaves, and then were to
perform a failover, you should:
1. Stop kpropd on the slaves.
2. Make a quick modification on the database (add/delete of a dummy
principal) on the new master to ensure kproplog has data.
3. Then restart kpropd on the slaves (I am assuming the conf file is
pointing to a DNS alias or something which has been moved).
#2. this kproplog design does not allow for a tree style propagation of data
(tree-style propagations may be required for global organizations or any
organization with lots of KDCs and/or lots of regional systems separated by
various WANS), e.g.
KDC A send data to KDC B, KDC C
KDC B send data to KDC D, KDC E
KDC C send data to KDC F, KDC G
-Richard
More information about the krb5-bugs
mailing list