[OpenAFS] Password transition to krb5 - your methods?
Thu, 25 Oct 2007 12:50:06 -0400
Thank you for the usual thorough response, Ken. It's
very welcome... and a bit amazing that you can construct
a response that thorough and clear in ~20 minutes :)
So my best bet, today, is to track down an MIT 1.3.0 release
to build afs2k5db against then?
Which is the next hurdle:
"Retrieve it here!"
"The kerberos...blahblah has moved."
Redirected in 1 second to main/modern dist. download page.
Off to the Kerberos list I go.
Ken Hornstein wrote:
>> IMO, it should be distributed with it and referenced
>> in a new README.kaserver (which also should include
>> the elders EOL statement regarding kaserver).
>> It doesn't have to be referenced by the build process.
>> I wouldn't surprise me to find that nobody agrees with
>> me again.
> Sigh. Jeff, I got your private email about problems building afs2k5db;
> I'm going to reply to this note and consider it a reply to your private
> note as well, because they're related.
> afs2k5db doesn't have a home, as you've discovered. So it's not a case of
> Redhat getting preferential treatment; the people who put the Redhat
> package together did extra work to put it in there.
> Why doesn't it have a home? Well, it is unfortunately an odd program.
> What afs2k5db needs to do is know about AFS internals (the format of the
> kaserver database) _and_ MIT Kerberos internals (the necessary magic to
> read a stash file or handle the master key, and output Kerberos dump
> file formats).
> When splitting up the various parts of the AFS-Kerberos 5 migration kit,
> the MIT Kerberos people said that "things that act like a KDC" (such as
> fakeka) they felt were better suited to ship with MIT Kerberos. Utilities
> such as aklog and asetkey are pretty obviously mostly AFS utilities that
> happen to link against Kerberos libraries and use Kerberos public APIs,
> so it makes sense to put them in OpenAFS. However ... no one was really
> sure what to do with afs2k5db. The MIT Kerberos people didn't want it,
> and the OpenAFS people understandably didn't want to ship with something
> that required private header files and functions and was almost certainly
> going to break in future MIT Kerberos releases. So that's the situation
> we're in now, to provide some history.
> Now, what SHOULD we do? Well, if it was up to me, I think afs2k5db
> should be rewritten to use only public krb5 API functions and
> manually do all of the encoding necessary to create dump file records
> (most of that is there; you would need to parse the stash file and
> encrypt the principal keys yourself, but that isn't terrible).
> Since MIT Kerberos generally supports older dump file formats this
> would be reasonably future-proof. If this was done, I think it
> would be reasonable to ship this program with OpenAFS. But the
> problem here is I don't see who is going to do the work; obviously
> I transitioned our cell years ago, and I have no motivation or time
> to do work on fixing up afs2k5db. I think most other people are
> in a similar situation. While I regret that we're where we are
> now, that's the situation as I see it. Unfortunately that isn't
> much help to you.
> Regarding your specific compilation problem, Jeff ... looks like
> to me that swapping the order of the includes of k5-int.h and krb5.h
> would be a good first step. But like Jeff Altman already told you,
> newer versions of Kerberos are unlikely to work with it.