[OpenAFS] kaserver deperecation, OpenAFS future, etc...

[Jeff Blaine]

 > I don't think there's any reason for anybody to resort to
 > insults here.

Nor did I think there was any reason for it.  But that's
over with now.

 > It would be helpful to all of us if you could outline exactly why you
 > *do* value kaserver

I value kaserver because it currently works.  Out of the box.
Day in, day out.  Without fail and without dependencies.

I value kaserver because I use pam_afs.so extensively and it
authenticates and token-grants out of the box.

I value kaserver because users don't like change.  Users who
really dislike tokens (many) most definitely don't like change
in something they finally half-stomached.

If my users can login to Solaris 9, Solaris 10, RHELv3 and
RHELv4 boxes (Intel and AMD64) and have a shell or X/GNOME/KDE
environment with tokens sitting there, renewed at screen-unlock,
I'm fine with that.

As I said earlier, I've gone through the process with MIT
Kerberos 1.4.3 and OpenAFS 1.4.something in Feb of 2006.
It was far from anything I would "strongly recommend" to
anyone in place of kaserver.  There were plenty of snags,
patches I was slipped under the table, and ultimately
a setup that was not something we could use with any
confidence - Single-DES "maybe hackable in a day" or
not.

 > you have to (somehow) make the business case of how this best
 > serves the openafs community.

To me, it's a matter of detail.  Any mildly competent admin
can compile and spawn a KDC process.  That's a far cry from
providing a replacement for kaserver.

Everything I have to say further than that on the issue will
very likely be met as unwelcome criticism of a free product
and its developers who volunteer their time.

I suppose I'll feed it toward paid ears, not volunteers'.

If you'd like, I can go through the whole process again in
our testbed and point out everything that needs clear work
or doesn't work at all.