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.
Trond
On Wed, 2009-10-14 at 09:47 -0700, [email protected] wrote:
> > On Tue, 13 Oct 2009 13:51:33 -0400
> > Trond Myklebust <[email protected]> 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
On Wed, Oct 14, 2009 at 12:47 PM, <[email protected]> wrote:
>> On Tue, 13 Oct 2009 13:51:33 -0400
>> Trond Myklebust <[email protected]> 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?
The change that adds the check for "valid" credentials caches
(including expiration) was not added until nfs-utils-1.1.3.
With that version of rpc.gssd, Jeff and Trond's descriptions are correct.
K.C.
On Tue, 13 Oct 2009 13:51:33 -0400
Trond Myklebust <[email protected]> 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...
--
Jeff Layton <[email protected]>
> On Tue, 13 Oct 2009 13:51:33 -0400
> Trond Myklebust <[email protected]> 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?