| Date: | Fri, 30 Dec 2011 09:43:38 -0500 |
| From: | Richard Basch <basch@alum.mit.edu> |
| Subject: | kpropd issues (1.8.x and probably also 1.9.x) |
| To: | krb5-bugs@mit.edu, krbdev@mit.edu |
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