I usually start with their bug tracker at:
http://elrepo.org/bugs/main_page.php
Pat
On 07/27/2013 09:07 AM, Anton Starikov wrote:
>
> So, point me to the instruction how to contribute to elrepo and I will do it.
>
> On 27 Jul 2013 15:42, "Akemi Yagi" <[log in to unmask]
> <mailto:[log in to unmask]>> wrote:
>
> On Fri, Jul 26, 2013 at 3:36 AM, Anton Starikov <[log in to unmask]
> <mailto:[log in to unmask]>> wrote:
> > 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 :)
>
> Do you think they can be built as kABI-tracking kmods? If so, would
> you consider contributing to ELRepo?
>
> As Pat mentioned, patches like this must be added to the upstream
> (RHEL) kernel for rebuild projects like Scientific Linux to get them
> in their distro kernels. This could take a long time depending on the
> urgency (from the upstream's point of view). It will be beneficial if
> the patches can be distributed as modules, which is why I'm wondering
> if ELRepo can offer them as kmods.
>
> Akemi
>
--
Pat Riehecky
Scientific Linux developer
http://www.scientificlinux.org/
|