We should decide on a better database prop strategy

[Donn Cave]

Quoth hartmans at mit.edu (Sam Hartman):
| It's my understanding that there are at least two implementations of
| iprop for MIT Krb5.  There's
| http://www.citi.umich.edu/u/kwc/krb5stuff/replication.html.  I believe
| that Nico also had some implementation of this, and we were working on
| something internally.
|
| There's also Ken's Nubik which would provide floating-master
| replication if working.

For what it's worth, we use yet another system.  I'm not sure if
it qualifies as replication, since the original data source is not
a KDC, but the effect is the same, multiplexed KDCs.  The origin
is a locally developed database that feeds /etc/passwd etc., as
well as the several KDCs.  It keeps a sequence count, can synch
a client that has been out for a couple of hours.  Kadmind updates
via, e.g., kpasswd are copied back to the source data.

| It seems to me at least that given there are multiple independent
| implementations of a solution to the problem we have a fairly clearly
| mandate from our users that the status quo sucks.  We should look into
| adopting one of these implementations or in some other way fixing the
| problem.

Yes, if only because of the overhead and synchrony lag.  It was
looking like 10 minutes for us, and with time off for the KDC to
do other things besides propagate, the lag would have been a
half-hour at least.

	Donn Cave, donn at u.washington.edu