Integration of k5start/krenew functionality

[Ken Raeburn]

I've wondered before if some of this functionality should be pulled  
into the library or existing programs.  For example, various means  
could be used to express to the library, "if credentials have expired  
or are about to, use this keytab entry to renew them automatically",  
or "after successful TGT acquisition, call this function".

I was going to argue that for the keytab case, at least, we shouldn't  
need a new long-running process to support this fairly simple  
functionality, but the other bits might.  Then I got to thinking about  
the CCAPI and ccache server stuff, where (at least on the Mac) renewal  
and running of additional hooks like token acquisition are handled  
automatically and via a helper process, and how we've had some  
discussions before on the possibility of moving some of the Kerberos  
work out of random processes and into some kind of "Kerberos/GSSAPI  
helper" process.  So, yes, I think maybe this is the right way to go,  
though the UI with these command-line tools is very different from the  
Mac/Windows CCAPI approach in some important respects, and I haven't  
formed an opinion yet whether that's good or bad, or which might be  
better.

I'm also of two minds as to how much Kerberos programs should be going  
out of their way to do AFS things, rather than providing hooks and  
letting someone choose to run AFS programs.  We don't do anything  
special for NFS or Zephyr or other Kerberos-using technologies.  (I  
wonder if we should look at some of the event signaling systems  
present on many systems these days, as a way to advertise "TGT in  
ccache foo updated" to any interested process, so it can get new AFS  
tokens or update Zephyr session key data etc.  There are already some  
notification hooks in some of the ccache code.  Just a thought...)

As for these specific programs -- I think there's a lot of duplicated  
functionality between kinit and k5start, so having one program with a  
few more options may be better... or a helper program to implement the  
other bits, though for some bits that could be as simple as shell code  
running chmod/chown/chgrp on success.  The "wait and see if renewal is  
needed" parts of krenew might reasonably go into program separate from  
kinit, though it's probably okay to merge in too as I wouldn't  
anticipate it could be used in conjunction with anything else besides  
kinit.  Though again, a shell/perl/python script could do some of it  
-- sleep N seconds, run an enhanced "klist -s -H" that'll tell if  
there's a valid TGT with at least X valid lifetime left, run kinit to  
renew, etc.

I guess what I'm suggesting is closest to your option #1, unless the  
process-wrapper bits turn out to be easily scriptable on top of  
existing (possibly slightly enhanced) krb5 programs.  If that's the  
case, maybe we should ship scripts instead of yet more C programs.

Plus maybe that keytab-auto-kinit library enhancement.

Ken