Re: (was: nfs-utils-1.1.3 released)

[Chuck Lever <chuck.lever@oracle.com>]

On Aug 6, 2008, at 2:21 PM, Sergey Bolshakov wrote:
>>>>>> "Chuck" == Chuck Lever <chuck.lever@oracle.com> writes:
> [skipped]
>
>> In addition to the debugging mentioned above, anyone encountering  
>> this
>> regression can also try a git bisect on nfs-utils (between 1.1.2 and
>> 1.1.3).
>
> I've seen same thing with degraded sec=none having SUSE 9SP3
> nfs-utils-1.0.6-103.23 on server side and 1.1.2-3899db6d
> on client side, so 3c1bb23c seems causing problems.

That's plausible.  The patch description claims the new client  
shouldn't choose AUTH_NULL even if it's in the list, so there may be a  
bug in the logic introduced by 3c1bb23c.

The new nfs(5) man page says sec=sys is the default if no security  
flavor is explicitly specified.  This is incorrect (or an  
oversimplification at the very least), given the security negotiation  
that goes on in mount.nfs.  That's another bug that should be fixed  
when this problem is addressed.

I doubt similar security flavor negotiation occurs in the kernel's  
mountd client, in the text-based case; thus the default sec=sys is  
always used when no security flavor is specified.  That's probably yet  
another bug.

I'm still at a loss to explain how this would show up on 2.6.26  
clients.  mount.nfs from nfs-utils-1.1.1 and beyond on that kernel  
should be using the text-based interface, so changing nfs-utils  
shouldn't have any effect on this behavior.

--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com