[OpenAFS] kaserver deperecation, OpenAFS future, etc...
Thu, 19 Oct 2006 16:32:43 -0400
> 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
> 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.