[2527] in Kerberos
Re: Scalability issues with Kerberos
daemon@ATHENA.MIT.EDU (Bill Sommerfeld)
Thu Jan 21 21:10:10 1993
Date: Thu, 21 Jan 1993 23:40:08 GMT
From: sommerfeld@apollo.hp.com (Bill Sommerfeld)
To: kerberos@shelby.Stanford.EDU
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
