Integration of k5start/krenew functionality
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.
More information about the krbdev