[1134] in Kerberos_V5_Development
Re: OV admin system integration plan
daemon@ATHENA.MIT.EDU (Theodore Y. Ts'o)
Tue May 7 22:29:33 1996
Date: Tue, 7 May 1996 22:26:52 -0400
From: "Theodore Y. Ts'o" <tytso@MIT.EDU>
To: Marc Horowitz <marc@MIT.EDU>
Cc: "Barry Jaspan" <bjaspan@MIT.EDU>, raeburn@cygnus.com, krbdev@MIT.EDU
In-Reply-To: Marc Horowitz's message of Tue, 07 May 1996 21:19:28 EDT,
<9605080119.AA02518@opus.MIT.EDU>
Date: Tue, 07 May 1996 21:19:28 EDT
From: Marc Horowitz <marc@MIT.EDU>
(Sorry for not commenting sooner on this issue; I've been kept busy this
week keeping *two* different MIT re-engineering projects from crashing
and burning...)
We need to choose either to use DB or DBM. We can mix the interfaces,
make libkdb use DB, or convert the OV code to use DBM. Avoiding the
decision by "supporting both" is the worst choice of all.
That's easy; we should convert the OV code to use NDBM. All of the code
in the libkdb is only using the NDBM interface.
This gives us the most flexibility since there are many different
database layers which support the NDBM interface. For example, the way
we currently support berk_db is using its ndbm compatibility layer.
I agree with the sentiments that we (MIT) can only support/test one
database layer. However, we shouldn't make it impossible for someone
who is determined (or desperate --- suppose someone desparately needs
krb5 in production finds a new berk_db bug which Marc hasn't run into
yet) to use a new database technology if they see a need to do so. The
way to get this flexibility is to code using the NDBM interface.
Remember that current berk_db which is in the MIT tree is known to have
data corruption problems. There are test cases which will cause it to
crash and burn. Marc has a patched 2.0 ALPHA release that is hopefully
a bit more stable; however, Margo has yet to stablize the file format,
and we still have to integrate his version of berk_db into the MIT
source tree.
If we think we can integrate Marc's berk_db into the MIT tree before
Beta 7 (the release that will contain the OV admin server) we should
definitely do so. At that point, it probably would make sense to make
that berk_db be the stable version that we extensively test against.
Until this happens, though, we may be better off making the native ndbm
library be the one that we test against. There may be a few cases
where that won't work --- such as Linux, which uses gdbm. What we
should do in those cases is a bit of an open issue. It really isn't at
all clear what the right answer in this case should be.
The bottom line is this is a very complex issue; so we shouldn't be
surprised when we can't come up with a simple answer that solves all of
our problems.
- Ted
P.S. There is one other case which may influence our decision; how big
will kdb entries be after the OV kadmin server is integrated in? Some
dbm implementations have a 1024 size limit on entries. This is not true
of all dbm implementations, but it in any case would have to be another
thing that we might have to document and warn people against.
