[OpenAFS-devel] tools and additional autoconf options...

[Neulinger, Nathan]

> > 	* 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:  nneul@umr.edu
University of Missouri - Rolla         Phone: (573) 341-4841
Computing Services                       Fax: (573) 341-4216