[28463] in Kerberos
Re: MIT Incremental Propagation
daemon@ATHENA.MIT.EDU (John Hascall)
Fri Sep 21 17:47:02 2007
To: Ken Raeburn <raeburn@mit.edu>
In-reply-to: Your message of Fri, 21 Sep 2007 16:52:59 -0400.
<18EE8EE5-4FAD-4265-ACAB-856E78554DA0@mit.edu>
Date: Fri, 21 Sep 2007 16:46:40 CDT
Message-ID: <31949.1190411200@malison.ait.iastate.edu>
From: John Hascall <john@iastate.edu>
Cc: kerberos@mit.edu
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
> Yes, that's exactly right. At least, in theory; I haven't tried it.
> Using the LDAP back end -- ah, as I see Nico was just saying -- will
> get you a common database shared across the KDCs, and leaves the
> replication mechanism, if any, to the LDAP administrator.
>
> Building something on Ubik might be a possibility. I'm not that
> familiar with it beyond "oh, that thing in AFS", but if it meets the
> performance requirements for a KDC, yes, it could work.
Well, ubik wouldn't exactly be my first choice, I just threw it
out as a possibly-known technology in the KDC replication protocol space.
Ubik is an elected-master protocol. All updates go to the master
which replicates. If the master goes away, after a while the
remaining nodes notice and revote a new master (this can take a while).
I'm not sure that model works well with the KDC's single-threadedness.
I expect a 3-phase commit model would be more robust.
John
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
