>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. --Ken _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
