[1113] in Kerberos_V5_Development
Re: OV admin system integration plan
daemon@ATHENA.MIT.EDU (Ken Raeburn)
Mon May 6 01:55:13 1996
To: "Barry Jaspan" <bjaspan@MIT.EDU>
Cc: krbdev@MIT.EDU
From: Ken Raeburn <raeburn@cygnus.com>
Date: 06 May 1996 01:54:58 -0400
In-Reply-To: "Barry Jaspan"'s message of Fri, 3 May 1996 17:32:36 -0400
So what would be the plan for updating a site runninf beta5 or beta6?
If kdb5_edit and the dump format are changed, the slave propagation
will be too.
I think the new code ought to be able to write old format dumps as
well as read them. Otherwise, a site would have to update slaves
before the master, and then if the update to the master causes any
problems and needs to be backed out, there would be no way to back out
the new server without reverting to an old database.
As far as DB versus DBM, I'd just as soon see us switch to DB for the
principal database if it works. I've seen dump files that can't be
loaded into a v4 NDBM database on SunOS because of NDBM bugs. I've
even generated very short dump files that cause the same problem. I'd
expect a v5 database to be at least as easy to trash. (It's a problem
in the standard BSD implementation. I don't recall if I checked
Solaris or HP-UX for the problem at the time.) If we ship the source
to the database package, at least we've got a chance of fixing any
problems.
I don't see any problem with requiring the same database system for
both databases (or a merged database). I do think it'd be best if we
keep it easy for someone to swap in an alternate database back end.
