> > * fix several krb5 bugs that they are continually ignoring > > I should probably not ask, but can you give details?
(Some of these MAY be fixed, but I don't believe they are. Alot of been in my local cvs for so long they just keep getting brought forward, but some are more recent.) memory leaks in krb524d due to copying a pointer to a structure containing pointers instead of traversing into the structure. (Results in dangling pointer when freeing, causing leaks.) poor handling of forwarded DISPLAY env var (patch isn't perfect, but it behaves much better) failure to set up ccache correctly when using 'telnet -l userid' to another system where you don't get let in via a .k5login and are prompted for a password. You get into system, but you wind up not owning the ccache, even though it contains your tickets. In krb524 (this one may be fixed, but doesn't look like it) source calls routines that aren't defined any more krb_life_to_time or something like that. Problem building without DNS support enable due to the way the locate_kdc headers are set up. They have #if blah #endif, but really need #if blah1 #endif blah2 #if blah3 #endif, cause the build depends on stuff in blah even without dns enabled. Other stuff is more afs specific, like how they locate libraries, and how the setpag functions are written, etc. Or it's enhancements that make it halfway usable. > > Another option would be to have central.org be the grand > repository of > > pointers to all-that-is-afs-related, but actually keep the tools on > > openafs.org. > > It's the same machine. I know, I meant same URL... > > > Since my impression is that we want people to be using krb5 > when they deploy > > afs, we should make it as easy as possible for them to do > so. To me, the > > easiest way to do that is to provide the auxilliary tools > to be built as > > part of openafs. If they can be provided externally > (example - binutils > > contains gdb, but gbd is also an external product - or > maybe it's vice > > versa) - that's great too. Distribute the extracted version > via central.org. > > aklog/asetkey at least a case could be made for "useful to > distribute with > OpenAFS". Is there anything else? The migration kit comes with: fakeka, ka-forwarder, afs2k5db, keyfile_dump in addition however, those are really specific to MIT servers. Not sure on keyfile_dump, I've never used it. The one patch that is still optional, but makes things MUCH easier with mit krb5 is the patch that allows krb524d to pull it's afs keys from a different location than it's krb5, so you don't have to update your KeyFile if you want to use krb524d. You can just leave it as is, give a copy to your krb524d server, and be continue to run just fine. I can pull that one out independently if desired. -- Nathan ------------------------------------------------------------ Nathan Neulinger EMail: [EMAIL PROTECTED] University of Missouri - Rolla Phone: (573) 341-4841 Computing Services Fax: (573) 341-4216 _______________________________________________ OpenAFS-devel mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-devel
