[5508] in Kerberos
Re: replacement for kprop?
daemon@ATHENA.MIT.EDU (Paul Zarnowski)
Mon Jul 17 21:59:32 1995
To: kerberos@MIT.EDU
Date: 17 Jul 1995 23:27:23 GMT
From: psz@jasper.cit.cornell.edu (Paul Zarnowski)
We've done a similar thing to what Barry suggested (below), but it's much
simpler. The problem we were trying to solve was that while kprop extracted
the database, the database was locked out from changes. We were propagating
every 15 minutes, and as our database grew larger, this became a real problem.
The solution, implemented by Mike Hojnowski (mqh1@cornell.edu) was to modify
kadmind and kdb_edit as follows. Whenever a record was changed in the
database, a copy of it was appended to the end of a log file. Kprop still
ran, but only once per day. Every 15 minutes, the morning's full dump,
suffixed by the cumulative daily log file, was sent to kpropd on the secondary
servers. kpropd required no changes. It read in the whole database, plus
log, and the end result is just what you want. The nice thing about this
solution is that if the network goes down or something, it's no big deal.
There's no sync problems to worry about. The daily db dump in the wee hours
of the morning is just a safeguard to prevent the logs from getting too large
and out of hand. It's worked pretty well for us. If you're interested in it,
you can get the code from the author (Mike).
..Paul
--
bjaspan@cam.ov.com (Barry Jaspan) writes:
>So as to make this a not entirely commercial message to a
>non-commercial list, I'll mention one of the ways that incremental
>database propagation could be added to the MIT release without too
>much pain. If you modify the lowest-level database write routines
>(krb5_db_put_principal and krb5_db_delete_principal, I believe) to
>maintain a "transaction log" for the kdb, you can then propagate just
>those log entries to each slave server---just make sure that your
>admin server uses those functions to make all of its changes. Of
>course, you also have to worry about keeping a database version number
>and maintaining state on the current version of each slave in case a
>slave is down when a propagation occurs. But it is not really that
>hard a problem.
>If anyone wants to implement it, I'm sure MIT would be delighted to
>accept incremental propagation patches for inclusion in its
>distribution. :-)
>Barry Jaspan, bjaspan@cam.ov.com
--
Paul Zarnowski Phone: 607/255-4757
Cornell Information Technologies Fax: 607/255-6523
Cornell University US Mail: 315 CCC, Ithaca, NY 14853-2601
