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

[Trond Myklebust <trond.myklebust@fys.uio.no>]

On Wed, 2009-10-14 at 09:47 -0700, raini@rainiday.com wrote:
> > 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.

No. That is not a necessary condition.

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

Yes. Please reread the thread carefully again.

As long as gssd always select from among the valid (i.e. unexpired)
TGTs, then the actual remaining lifetime of the particular TGT that was
selected doesn't matter; gssd will always be able to renew the resulting
RPCSEC_GSS session when it expires.

  Trond