Integration of k5start/krenew functionality

Jeffrey Hutzelman jhutz at cmu.edu
Mon Aug 3 10:08:47 EDT 2009


--On Sunday, August 02, 2009 11:47:45 PM -0400 Greg Hudson 
<ghudson at mit.edu> wrote:

> AFS support is not a primary goal.  Given that krenew and k5start will
> continue to be maintained externally, I am now wondering if perhaps the
> project scope should be narrowed substantially to limit the amount of UI
> real estate used.  So I am thinking of dropping the krenew use case,
> eliminating the aklog-shaped external program hook, and supporting only
> one style of k5start use case--for example, only operation as a process
> wrapper, and not as a background process or check-and-renew utility.

This sounds like a reasonable approach to me.  As you note, introducing an 
AFS dependency into krb5 would be annoying, since AFS already has krb5 
dependencies and is only likely to grow more.  Kerberos ought to 
concentrate on Kerberos, and leave the complex tie-lots-of-things-together 
tools to someone else.


> The other Ken wrote:
>> Can we do it with a tiny plugin module that can either be installed or
>> not depending on whether you need the AFS support,
>
> I am reluctant to add any build dependencies of any kind on AFS, because
> AFS depends on krb5.

I agree.  However, I can see how it might be useful to have a hole into 
which such a plugin might be dropped.  The plugin itself could then be 
shipped with AFS, which would also resolve issues about knowing exactly 
what it needs to do, which is likely to change over time.

-- Jeff



More information about the krbdev mailing list