[1108] in Kerberos_V5_Development
Re: OV admin system integration plan
daemon@ATHENA.MIT.EDU (Marc Horowitz)
Sun May 5 18:47:56 1996
To: "Richard Basch" <basch@lehman.com>
Cc: "Barry Jaspan" <bjaspan@MIT.EDU>, krbdev@MIT.EDU
In-Reply-To: Your message of "Sun, 05 May 1996 17:53:01 EDT."
<199605052153.RAA01965@badger.lehman.com>
Date: Sun, 05 May 1996 18:47:50 EDT
From: Marc Horowitz <marc@MIT.EDU>
In message <199605052153.RAA01965@badger.lehman.com>, "Richard Basch" <basch@lehman.com> writes:
>> A few reasons why I am using v4kadmind:
>> 1. We still have a large V4 install base.
>> 3. The V5 admin server/protocol is changing soon and I don't want
>> to build up an install base that I will have to convert. When
>> the final V5 admin protocol is done, I will consider deploying it.
Except for changing passwords, how much of your installed base uses
admin clients of any version? I'm trying to gauge the usefulness of
extending ov's v4 protocl password changing server.
>> > "The kdb library currently uses the ndbm api. The OV admin system
>> > code uses the berkeley db api for its own databases, and the kdb
>> > library to access the KDC database." The rest of the paragraph
>> > follows more clearly from this.
>>
>> Why doesn't the admin server use the kdb layer, instead of direct db/dbm
>> access? This would reduce the number of places that need to be changed
>> if a new db is chosen.
It does use the kdb layer, when it can. This layer provides
functionality for dealing with principals, and none for dealing with
policies. So it uses db for dealing with policies.
The entire kdb abstraction is a mess; gutting it and using a more
reasonable abstraction for the underlying database would be admirable,
but it's what we've got now.
>> The part that actually needs work under the kadmin tree is ktutil.
>> There is no equivalent to the V4 ksrvutil (add/delete/change). However,
>> I must say that it provides a useful V4-V5 conversion feature.
The OV stuff provides such a program, so you'll have it when the OV
integration is done.
Marc
