[1116] in Kerberos_V5_Development
Re: OV admin system integration plan
daemon@ATHENA.MIT.EDU (Barry Jaspan)
Mon May 6 11:36:03 1996
Date: Mon, 6 May 96 11:35:31 -0400
From: "Barry Jaspan" <bjaspan@MIT.EDU>
To: raeburn@cygnus.com
Cc: krbdev@MIT.EDU
In-Reply-To: <tx168aae47h.fsf@cujo.cygnus.com> (message from Ken Raeburn on 06 May 1996 01:54:58 -0400)
So what would be the plan for updating a site runninf beta5 or beta6?
Well, I disagree with your implicit assumption that compatibility with
beta 5 and beta 6 are important. How many sites are running beta 5 or
will run beta 6? How many of those will be running slaves (heck, how
many of those will even be able to get slaves props to work at all)?
Of those that are running slaves, how many are in production use and
are so large or reliability-critical that the slaves actually matter?
Given the quality of the beta 5 release, I hope and expect that the
answer is "none." Therefore, I think that adding more code for
compatibility with a case that is unimportant will just contribute to
the bloat.
Secondly, updating a beta 5/6 site will be possible anyway. The site
takes one slave out of service (or sets up an additional slave or
clone of the master for testing) and practices on it. The update
should only take a few minutes; not many db entries will have changed,
so the slave with the new code can be put into service for a day to
see how it works. Once the admin is confident the code will work, he
can update all the slaves and the master in one day or, if there are
too many, over a few days (simply disbaling updates to the new slaves
until the master is done). The admin can disable kpasswd for those
days so that no db entries get changed, too.
Yes, this makes the admin's life a little bit more complicated, but
(a) I doubt there are many such admins, as explained above, (b) making
kerberos smaller and simpler will make their lives much easier in the
long run, and (c) if a site really better compatability between beta
releases of MIT code, they should be using a commercial Kerberos
vendor.
As far as DB versus DBM, I'd just as soon see us switch to DB for the
principal database if it works.
I don't really have strong emotions one way or the other. I do know
that DB had bugs in the past, but Marc now assures me that they are
all fixed. Ted says that the internal DB disk format will likely
change the future, but I suppose sites can handle that with a
dump/reload cycle, so it isn't that critical. Using just one db
library would *simplify the configure system* (always a worthy goal)
and we could even dike out the #ifdefs for dbm support in kdb_dbm.c.
So maybe that is the right choice.
Barry
