[1126] in Kerberos_V5_Development
Re: OV admin system integration plan
daemon@ATHENA.MIT.EDU (Theodore Y. Ts'o)
Tue May 7 00:19:31 1996
Date: Tue, 7 May 1996 00:19:27 -0400
From: "Theodore Y. Ts'o" <tytso@MIT.EDU>
To: Ken Raeburn <raeburn@cygnus.com>
Cc: "Barry Jaspan" <bjaspan@MIT.EDU>, krbdev@MIT.EDU
In-Reply-To: Ken Raeburn's message of 06 May 1996 14:56:49 -0400,
<tx1zq7l6366.fsf@cujo.cygnus.com>
I haven't had time to go over all of the fine details of the integration
plan yet (hopefully will have time to do this tomorrow), but let me
comment on a couple of issues that have been raised so far:
>Compatibility with Beta-5 and Beta-6
There are two separate issues here that getting mixed up. First of all,
there is the issue of smooth upgrades from Beta-5 and Beta-6. It should
be a requirement that we be able to read *and* write old-format ASCII
kdb dumps. In the latter case, we may lose information; but that's OK.
The only reason for this is so that admins can easily upgrade *and*
downgrade in case something goes very badly wrong. There may also be an
issue of wanting to run a slave using the old Beta-5 or Beta-6 for
testing purposes, so we want a way to be able to convert from the new
database format to the old database format.
There is a second issue of compatibility with the admin server systems
themselves. Actually, there are a number of production systems (Rutgers
being a notable example) that are using Beta 4pl3 with the Sandia admin
server. While I'm not suggesting that we actually try to support them,
it will mean that there will be some sites that will be forced into
doing a flag day for password changing programs.
The kadmin server for Beta 5 and Beta 6 supports the Krb5 simple
password changing protocol, and that *should* continue to work after we
cut over to the OV kadmin server. As long as this continues to work,
the kpasswd client from Beta 4pl3, Beta 5 and Beta 6 will continue to
work, and that is a good level of compatibility to strive for.
>DB/DBM issues.
I would very much like to see the ability to use *either* db or dbm,
which would mean coverting over the policy database routines in the OV
kadmin implementation to use the dbm interfaces instead of the db
interfaces. That way, if you want to use Berkeley DB, you can just
simply use the dbm glue code --- but if you want to use some other
database package, like gdbm or sdbm, you have that option. I don't
really like tieing oursolves to the Berkeley DB interface, especially
when it's still in ALPHA and the file format is still subject to change.
I have heard varying reports about how hard it would be to actually do
this. I can't believe it's too hard, but I haven't investigated the
source code of the OV kadmin server myself.
- Ted
