[28468] in Kerberos
Re: MIT Incremental Propagation
daemon@ATHENA.MIT.EDU (Marcus Watts)
Sun Sep 23 01:56:51 2007
To: Ken Raeburn <raeburn@mit.edu>
In-reply-to: <18EE8EE5-4FAD-4265-ACAB-856E78554DA0@mit.edu>
Date: Fri, 21 Sep 2007 18:09:11 -0400
From: Marcus Watts <mdw@spam.ifs.umich.edu>
Message-Id: <E1IYqgR-0005Cs-7z@spam.ifs.umich.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
> Date: Fri, 21 Sep 2007 16:52:59 EDT
> To: John Hascall <john@iastate.edu>
> cc: harris@ucdavis.edu, kerberos@mit.edu
> From: Ken Raeburn <raeburn@mit.edu>
> Subject: Re: MIT Incremental Propagation
>
> On Sep 21, 2007, at 16:08, John Hascall wrote:
> > I haven't studied it all that extensively,
> > so correct me if I am wrong, but with the
> > new "DAL" stuff there is now an opportunity
> > to do a 'proper' job of multi-master KDCs
> > (dare I say it) in a "ubik-like" or "AD-like"
> > manner.
>
> 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.
ubik basically just provides a replicated flat file with transactions.
All the database stuff that AFS does is layered on top of this,
but ubik proper doesn't provide a database, just a byte stream
with seek and a length.
-Marcus Watts
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
