On 08/01/2014 01:02 PM, chas williams - CONTRACTOR wrote:
On Thu, 31 Jul 2014 15:29:47 -0500
Andrew Deason <[email protected]> wrote:
The first time I heard this I was a bit surprised, but that may be just
because I'm very used to the 'aklog' approach and find it intuitive. You
need to tell the kernel what credentials you want it to use for AFS
access; makes sense to me.
Honestly, nowadays this seems to be pretty transparent to our users, or
more exactly, there is little difference made between "expired Kerberos
TGT" and "expired AFS token" - of course, credentials can still expire
at inconvenient times.
[On Linux, our users receive both Kerberos and AFS credentials on login
(console/ssh/screensaver), ssh forwards the TGT (and gets an AFS token
on the server side), and we have wrappered "kinit" to do "aklog" as
well. The batch system will do Kerberos/AFS renewal automatically, and
we have kerberized cron servers.. all of this since several years. The
PAM bits need looking at for new Linux releases.]
As such, using a different mechanism to get one from the other is not a
high priority. Of course, some more automatic/'pure' Kerberos-like
approach[1] would allow us to remove such customizations, but having to
run something like gssklogd everywhere would probably offset that gain.
Regards,
jan
[1]: imagine that the kernel on access to AFS checks whether a token
exists in the PAG, otherwise triggers a userspace call-out (with same
environment as the calling process, i.e KRB5CCNAME set) to provide one.
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info
