[1131] in Kerberos_V5_Development
Re: OV admin system integration plan
daemon@ATHENA.MIT.EDU (Ezra Peisach)
Tue May 7 20:11:55 1996
To: "Barry Jaspan" <bjaspan@MIT.EDU>
Cc: krbdev@MIT.EDU
In-Reply-To: Your message of "Tue, 07 May 1996 12:00:16 EDT."
<9605071600.AA15021@starkiller.MIT.EDU>
Date: Tue, 07 May 1996 20:11:42 EDT
From: Ezra Peisach <epeisach@MIT.EDU>
Regarding different database formats:
I agree that there should be one underlying database system - and if
need be we provide it in source form. We cannot afford to spend the time
trying out all the differing configuration options. If the Berkely DB
library is really robust and non-buggy - then we should go with it. I
would suggest that we merge the db routines into libkdb.a to make it
easier. I am all for making whatever software exists able to dump and
read an ascii formatted file (with version number) and make whatever
applications able to read and produce said files.
I will give you an example which will show why we should do this (and
merge libraries). I recently tried to build krb5 on a Linux 386 running
Slackware 2. The default configuration options will build fine - but
when you try to make check - you run into database problems. I tracked
it down to the fact that under Linux the dbm routines are using GDBM
which do not allow more than one application to open the database
read/write. This is a lose for a KDC and admin server - they would not
be able to co-exist. It was hinted that I could modify GDBM to do what I
wanted - but if I was an end user - I would not want to.
So, I figured I would use the berk_db support built into the existing
configuration. I discovered that with Slackware 2 - the loader (ld)
exhibited the amusing feature that -Lpath was appended to the end of the
default path and I was linking against the wrong db.a.
Okay - I compiled a new version of ld and everything compiled. Now make
check does not compile because one of the test programs assumes that if
you specify --with-kdb-db=db, the dbm routines are available to you -
but they are not, because -ldbm is not included on the link
line. Needless to say, I just fixed the source.
So what are the lessons learned by all this? a) We did not do sufficient
testing, even on what is becomming a low-end affordable platform (which
Don says people consider a plus). b) Do we have to document the dangers
with GDBM for end users - and would they know how to check c) Operating
systems have bugs. We should not name out libraries the same thing as
what is already present in the O/S.
I will also propose the following:
a) The aname database be the same as all other databases. (p.s. there is
currently no way to dump an aname database)
b) The ability to read a V4 dbm file - which probably has not been
tested in a long time - should be removed. We should expect though that if
you are running V4, you can take a ascii V4 database dump and read it into a
V5 configuration.
If I hear no objections by the weekend, I will remove the V4 DBM kdb
support.
ezra
