> On Tue, 13 Oct 2009 13:51:33 -0400 > Trond Myklebust <trond.myklebust@xxxxxxxxxx> 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? -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
