[1154] in Kerberos_V5_Development
Re: OV admin system integration plan
daemon@ATHENA.MIT.EDU (Theodore Y. Ts'o)
Fri May 10 14:33:14 1996
Date: Fri, 10 May 1996 14:32:59 -0400
From: "Theodore Y. Ts'o" <tytso@MIT.EDU>
To: Mark Eichin <eichin@MIT.EDU>
Cc: Ezra Peisach <epeisach@MIT.EDU>, "Barry Jaspan" <bjaspan@MIT.EDU>,
krbdev@MIT.EDU
In-Reply-To: Mark Eichin's message of 10 May 1996 02:40:03 -0400,
<xe1ive5rpz0.fsf@maneki-neko.cygnus.com>
From: Mark Eichin <eichin@MIT.EDU>
Date: 10 May 1996 02:40:03 -0400
Sorry I hadn't mentioned that here earlier, but yes, as far as I can
tell krb5 won't work with dbm on *any* system unless you #ifdef out
the locking that it does. (I have a seperate debian package of libgdbm
that I use for just that reason, and have been trying to think of a
way to have one package support both modes...)
Are you sure? It was my understandign standing that the locking problem
was gdbm problem only.
Once marc's berk_db fixes get checked in, I'd certainly be happy
testing it extensively and (hopefully) committing to it. As Ken has
pointed out, we *know* that dbm is really broken too, with *small*
cases, much less large ones, and have merely gotten lucky thus far...
Well, marc works for Cygnus now. If he wants to work on integrating his
version of berk_db (not fixes, but a complete new version) into our
source tree, I have no objections. It wasn't checked in while he was
working for MIT/ISC because he indiciated it was a lot of work and he
didn't want to get side tracked from doing the OV/admin stuff.
Note however that it will mean that customers will have to do a dump and
restore of the database during the upgrade process.
- Ted
