Porting Heimdal's libkafs to MIT Kerberos

[Sam Hartman]

>>>>> "Ken" == Ken Hornstein <kenh at cmf.nrl.navy.mil> writes:


    Ken> Well, I can only say that a recent thread on one of the
    Ken> openafs mailing lists indicated to me that plenty of MIT
    Ken> customers care about AFS support.  

Wouldn't know; I tend not to read OpenAFS lists.  I'd recommend that
people who want to give us feedback give it to us rather than posting
on lists we don't follow.
    Ken> well, the users may switch to a Kerberos implementation that
    Ken> does.

    >> I don't understand why AC_CHECK_LIB(kafs) or whatever is so
    >> hard.

    Ken> Well, it works as well as AC_CHECK_LIB(krb5) does.  That is
    Ken> to say, it seems easy, but it sucks in practice.  The real
    Ken> problem is that in my experience, you have to go through a
    Ken> bunch of autoconf contortions to check for a library in a
    Ken> non-standard location.  This was the whole crap that
    Ken> krb5-config was designed to address, and I was _so_ glad when
    Ken> I was able to rip all of that out and simply switch to using
    Ken> krb5-config, because although I tried my very best, it just
    Ken> never worked very well.

I think the reason we viewed krb5-config as valuable is because of the
libk5crypto vs libcrypto/libdes/libdes425/whatever mess, the
libgssapi_krb5 vs libgssapi mess, etc.  Nonstandard locations can be
handled by CPPFLAGS, LDFLAGS.

Do you believe that libkafs will be harder than AC_CHECK_LIB, CPPFLAGS
and LDFLAGS?  If so, then yes it needs a better solution than
AC_CHECK_LIBS


    Ken> That's one of the problems.  The other problem is that it's
    Ken> one extra piece and that has a whole bunch of secondary
    Ken> effects.  It's one more library I have to distribute to
    Ken> systems locally, it's one more thing that users of my
    Ken> software have to get and install.  If I could just say, "Hey,
    Ken> you need MIT Kerberos version X or greater", that's a lot
    Ken> easier than saying, "Hey, you need to get MIT Kerberos, _and_
    Ken> this other package".  These aren't insurmountable problems,
    Ken> they're just annoying, especially when the _other_ guys just
    Ken> ship with it.

OK.  Being the one package you need for Kerberos support is
specifically an anti-goal for the core MIT Kerberos libraries.  We
want to be good Kerberos libraries, KDC and admin system.  We
certainly have a while to go on the admin system.

KFW does try to be more a complete Kerberos solution and there, we do
have AFS support.

I could see arguing that we should bundle libkafs with KFW binary
builds.

If you or someone else does want to make the single Kerberos you want
to install to get all things Kerberos, I personally think that would
be a good idea if it were well done an well maintained.  I would hope
that you would select MIT Kerberos as your core Kerberos
implementation, although Heimdal is also a fine product.  If you did
choose MIT Kerberos then I'd certainly try my best to encourage MIT to
work with you.  I'd hope that you would avoid needing to patch MIT
Kerberos itself and MIT might have to make some changes to realize
that goal.

Yes, what I describe is a lot of work.  That is why we're not trying
to do it.