On 07/26/2013 05:36 AM, Anton Starikov wrote:
[log in to unmask]" type="cite">
Hey,

I don't know how to proceed with this, as clearly thus must be patched upstream, but I don't use upstream so I submit here.

1) there is parameter in "nfs" module called "nfs4_disable_idmapping", to disable mapping on a client-side when AUTH_SYS. It was introduced, for support of NFS4-root. But NFS4-root can work smoothly only when on both sides, client and server, idmapping is disabled. It was fixed for "nfsd" in fresh kernels (commit http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=e9541ce8efc22c233a045f091c2b969923709038 ).

I attach here backported patch for current 2.6.32-358 kernels. I set default value of nfs4_disable_idmapping to FALSE in this patch, in order to mimic behaviour of unpatched kernel. (this differs from modern kernels, where it is TRUE by default).


2) with NFS4 mounted filesystems there is and issue with execution of files which has execute-only mode (111). (Typical example: sudo will not work on nfs4-root). This was also fixed relatively recently in fresh kernels. Here I attach patch, which fixes that (it affects both, "nfs" and "nfsd" modules). It is backported from 3.1.x.


Without this patches, NFS4-root will never function as it really should. With this patches everything works like a charm.

In my setups I have this patched modules in dkms, but having them in the upstream will be nice simplification of life :)

Sometimes I am curious, is it really the case that nobody from EL6 users uses nfs4-root, but me? :)

Anton.


Thanks for taking the time to research, write, and send this to Scientific Linux!  The best way to get this patch included in a new version of Scientific Linux is to get the fix included further up stream.[1]  That way groups other than this one can benefit from your work on this issue.  From our side we try not to deviate very much from what our upstream provider is doing.  Our hope is that by following them closely we reduce the possible problems our users encounter.  But this can lead to some tension in the application of patches, particularly patches that fix problems.

One of the best ways we can give back to our upstream providers is fixes like this one.  I hope that you can open a bug with them so that everyone can benefit from this.  As a point of etiquette, they prefer not to have mention of SL on their bug tracker.  Our source, for any package they provide, is their source.  Any patches we apply are noted in the changelog with justifications and generally attributed to Connie, Troy (who has left us), myself, or the Scientific Linux Development list.

Right now our commitment to improving SL, assisting upstream in fixes, and generally trying to give back to the linux community at large gives us pause before applying any patch for upstream packages which doesn't have an associated bugzilla number.  They've given us so much, we want to try and give back where we can and help encourage others to do so in the spirit of the open source movement.

Again, thank you for your efforts here!  Please feel free to continue to contribute regularly to [log in to unmask]

Pat


[1] http://bugzilla.redhat.com/

-- 
Pat Riehecky

Scientific Linux developer
http://www.scientificlinux.org/