Re: [NFS] NFS/krb and batch jobs - doable?

[raini@rainiday.com]

> On Tue, 13 Oct 2009 13:51:33 -0400
> Trond Myklebust <trond.myklebust@fys.uio.no> wrote:
>
>> On Tue, 2009-10-13 at 13:27 -0400, Jeff Layton wrote:
>> > Correct...and gssd actually does check the validity of the cache. If
>> > TGT has expired or it's not valid for some other reason, then it skips
>> > it and moves on.
>> >
>> > The problem comes when you have more than one valid credcache. In that
>> > case it picks the one with the latest mtime. It seems that it should
>> > instead pick the one with the latest TGT expiration time.
>>
>> So why do you think that is a problem? The result should be that
>> rpc.gssd always ends up with a valid credential as long as there is at
>> least one with a valid TGT.
>> IOW: Who cares if the GSS session isn't going to last as long, as long
>> as the RPC client can always instantiate a new one.
>>
>
> Hrm...good point. I suppose that as long as gssd can pick a new
> credcache if the context expires then this patch is superfluous. Wasn't
> that support only added fairly recently (around a year ago?)? If so, it
> may just be that raini isn't using a recent enough nfs-utils...

Hm - well I'm stuck on production machines (RHEL5) so currently on
nfs-utils 1.0.9 which I'm going to take a wild guess may be problematic
either way.  Could someone point me to information on this change (I see
little in http://www.kernel.org/pub/linux/utils/nfs/)?

The reason I thought the new code would be useful is that if default
tickets are non-renewable and short lifetime, it seems sensible for gssd
to spot and use a longer lifetime renewable ticket in another ccache file
- and say use krenew to keep the job alive (or even cope with the user
renewing the ticket manually).

Seems to me therefore that in the absence of per-session ccaches, gssd
should prefer long lifetime, and renewable.

Would the newer code you mention cope with this situation already?