Re: Very Large KDCs
I think you'll need to make sure that you're using a _modern_ version of Berkeley DB, rather than what comes with MIT Kerberos. Years ago, Cygnus tested the BDB code in Kerbnet with a million principal database. We did not observe any problems (well, we fixed the ones we observed :-). That code should be basically the same as what's in the MIT release today. I only know that I've heard Keith Bostic on numerous occasions say that the BDB in MIT Kerberos is ancient, full of bugs, etc etc ... I only mentioned that because of those things he talked about. But like Marc said, the best thing to do is perform your own tests. --Ken
Re: Very Large KDCs
On Fri Feb 1 11:07:22 2002, Nicolas Williams said: On Fri, Feb 01, 2002 at 10:20:04AM -0800, Mike Friedman wrote: Looking down the road around here, we may wind up having to populate our KDC with alumni, in addition to the students, staff and 'affiliates' that we have now. Which means possibly exceeding 1M principals in the database. Does anyone know if I should anticipate problems when/if the database gets that large? Are there folks out there actually running a KDC with anywhere near that many principals? - perf knees in BDB? I doubt it. OK, good. - load; how many of those 1M records are going to be active? Good point. Concurrent activity will probably always involve only a small percentage of our registered principals. - replication; how long does it take to kprop a database with 1M records? How long does it take to dump such a KDB? I forgot about that. Right now, the entire propagation (unload, transmit db, reload) takes about 5 minutes (the unload no more than 2 minutes). In our environment, where we do mostly web 'proxy' authentication, I have to deal with the fact that while the master is being unloaded, updates (eg, passphrase changes) don't work properly. When these are being done by my cgi scripts, I have to be prepared to handle this condition. Currently, my code does this rather primitively, but since the condition occurs rarely it hasn't been a problem. So, if dumping the db is going to take a significant amount of time, I'll need to make my code more robust. I have implemented an incremental replication system in-house for dealing with replication. I recommend you look into doing the same. I guess I'll need to consider this. Thanks for the feedback. My initial concern was mainly with the MIT K5 software itself, but clearly I need to worry about ancillary processes as well. Mike -- Mike Friedman System and Network Security [EMAIL PROTECTED]2484 Shattuck Avenue 1-510-642-1410University of California at Berkeley http://ack.Berkeley.EDU/~mikefhttp://security.berkeley.edu --
Re: Very Large KDCs
On Fri, Feb 01, 2002 at 11:34:43AM -0800, Mike Friedman wrote: Thanks for the feedback. My initial concern was mainly with the MIT K5 software itself, but clearly I need to worry about ancillary processes as well. I would say the biggest issue is replication, not the operation of the krb5kdc process. The performance of the krb5kdc process in the face of a large KDB will depend on the performance of the KDB (BDB). Similarly with kadmind, but there you have locking interactions with the replication system. Hint: whole dumps lock the whole database, whereas partial dumps lock the individual records being dumped. So if you're doing incremental replication then kadmind's performance should not be affected(*). BTW, Heimdal has incremental replication... (*) unless there is much contention for a given record, and be mindful of the fact that kadmind fork()s for each connection, so too many admins (hundreds?) might not fly - dunno if kadmind fork()s for kpasswd requests, but those are short anyways. Mike Cheers, Nico -- -DISCLAIMER: an automatically appended disclaimer may follow. By posting- -to a public e-mail mailing list I hereby grant permission to distribute- -and copy this message.- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments.
