🚀 go-pugleaf

In article <9301211836.AA14955@shadow.secure.bellcore.com> lunt@CTT.BELLCORE.COM (Steve Lunt) writes:

   Database dumps and loads (via krb_util, which is used by kprop) are
   slow when the database is that big (apparently order n log n).  But
   ticket requests (kinit) and database updates (kadmin and kpasswd) are
   still very fast (apparently order log n).  Also, the ndbm files get
   really big (I think I tested it on a Sun with 10,000 principals, and
   the file was 5 meg in size), if this is a problem on your system.

Note that this is purely a function of the KDC implementation, and
fixing this requires no changes to clients, servers, or the main run
time library.

If you've got a better, more scaleable database (or even a better dbm
implementation -- that's all that kerberos needs), you can drop it in
place on the KDC and use it instead.

If you've got a better replication system, you can drop it in place on
your KDC and use it instead, and won't have to change the clients.

I'm aware of Kerberos v4 implementations that have used at least three
different databases underlying the MIT KDC implementation.

	ingres	(the old university ingres.  this was too slow and
		 flushed in favor of dbm).
	dbm	(both "dbm classic" and ndbm).
	Apollo registry (this was an internal project which
		was never released -- however it "evolved" into the
			DCE kerberos v5 support).

The database module is eminently replaceable.

In addition, Transarc's AFS3 includes has a v4-kerberos system (albeit
with a serious flaw: they use a completely incompatible string-to-key
algorithm) built over their "ubik" replication technology.

				- Bill