[1340] in Kerberos_V5_Development
Re: V4 kadmin server
daemon@ATHENA.MIT.EDU (Barry Jaspan)
Thu Jun 20 12:16:44 1996
Date: Thu, 20 Jun 1996 12:16:23 -0400
From: "Barry Jaspan" <bjaspan@MIT.EDU>
To: tytso@MIT.EDU
Cc: krbdev@MIT.EDU
In-Reply-To: <9606200147.AA08011@dcl.MIT.EDU> (tytso@MIT.EDU)
Date: Tue, 18 Jun 96 14:02:15 -0400
From: "Barry Jaspan" <bjaspan@MIT.EDU>
When we first wrote this code at OV, we #ifdef'ed all the changes so
that the V4 kadmin server...
I actually don't understand why you bothered with the #ifdefs at all
since we already had a fully-functional version of the V4 kadmin server
which used the libkdb interface.
I do not think there should be two different versions of the v4 admin
server in the MIT tree; that will just mean we have to update two
pieces of code each time a bug is found, and inevitably the code will
diverge in annoying was. It will also confuse administrators; they
won't know which version to use.
The downside is that we only implemented the change-password function
of V4 kadmind.
Implementing the other functions is extremely important for MIT...
I anticipated this in the integration plan I wrote a couple months ago
(/mit/krbdev/doc/specs/admin/integration/admin-integration.txt).
Basically, I argued that while MIT needs a fully functional V4 compat
server for the time being, the rest of the world probably doesn't---a
V4 change-password server will suffice, and in any case in the
interest of simplifying the Kerberos distribution we want to provide
as little redundant code as possible. Therefore, I suggested that we
remove the current V4 compat server from the public release and that
MIT just maintain it locally for its own use, and that we replace it
in the public release with the kadm5 version of the V4 compat server
that (currently) only supports password changing.
This has the advantage of presenting a more unified system to the
world (all admin access goes through the kadm5 interface, and enforces
its rules, etc) while still leaving MIT with what it needs.
This is something that we need
very badly now --- and I'm sure Cygnus's customers will be in the same
boat as MIT's.
If Cygnus is going to support the kadm5 system (which, based on Marc's
comments, I think it will), then they will probably want the V4 compat
server to work through kadm5 for the same reasons I presented above.
Thus, if it is really important to them to have a fully-functional V4
compat server instead of a password-changing server, they will make
the business decision to assign the resources to implement it.
Barry
