🚀 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

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.

Our kerberosDB has 12580 principals and is just under 13MB in size
(although ls -l would have you think it was 160MB).  We have close to
900 client machines and our load in 24hrs (Thursday 4am - Friday 4am)
was:
       Initial Requests:  21901   avg of 0.25 /sec
       APPL Requests:     57532   avg of 0.67 /sec
       New Principals:      169
       Password Changes:     60

Although the load isn't constant over 24 hours, it doesn't vary as much
as you might think:

                         (Total Requests per Hour)
    7000+           * *
        |           * *       *
    6000+           * *       * *
        |           * * *   * * *
    5000+         * * * * * * * *
        |         * * * * * * * * *
    4000+         * * * * * * * * *
        |---------*-*-*-*-*-*-*-*-*----------------------- average
    3000+       * * * * * * * * * * *
        |       * * * * * * * * * * * *           *
    2000+       * * * * * * * * * * * * * * * *   *
        |     * * * * * * * * * * * * * * * * * * * * * *
    1000+ * * * * * * * * * * * * * * * * * * * * * * * *
        | * * * * * * * * * * * * * * * * * * * * * * * *
       0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
          4 5 6 7 8 9 1 1 N 1 2 3 4 5 6 7 8 9 1 1 M 1 2 3
                      0 1                     0 1

}A kprop/kpropd that sends only updates is critical for realms that
}have # of principals in the tens of K.  In this case, kdb_util should
}only be used in emergencies.

While we also would like to see a more `fully distributed' KDB (for load
sharing, fault tolerance, etc.), it appears not to be critical at our size
-- our little DS2100 keeps up with no problem.

One thing we didn't really understand when we brought in Kerberos was that
your slave-kerberos server(s) will basically do nothing almost all of the
time.  As an experiment we tried having some machines use the slave as their
primary server, but it was just too confusing for people who had recently
changed their password (we only kprop every 12hrs).  With a more-or-less
instantaneous master-to-slave propagation scheme you could load balance
between multiple kerberii.

John
-- 
John Hascall                   ``An ill-chosen word is the fool's messenger.''
Systems Software Engineer
Project Vincent
Iowa State University Computation Center  +  Ames, IA  50011  +  515/294-9551

sommerfeld@apollo.hp.com (Bill Sommerfeld) writes:

}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)

There is a rather simple work-around which allows you to make
AFSkerberos & MITkerberos play nice together...

John
-- 
John Hascall                   ``An ill-chosen word is the fool's messenger.''
Systems Software Engineer
Project Vincent
Iowa State University Computation Center  +  Ames, IA  50011  +  515/294-9551