RPC and NFS more than 16 groups

[Knowledge Seeker]

Hi,
I made the changes in 2 FreeBSD 8.0 stable boxes. One I've configured one as
a server and the other as the client.
But the 16 groups limit persists.
Even when I tried using a GNU/Linux Debian machine as a client with a Kernel
patched  to work with the number of groups advertised by the server
(kernel-patch-nfs-ngroups), it does not work.


The files and lines changed in FreeBSD src were:

include/rpc/auth_unix.h:#define NGRPS 64
lib/libc/rpc/PSD.doc/xdr.nts.ms:#define NGRPS 64
lib/libc/rpc/PSD.doc/xdr.nts.ms:#define NGRPS 64
sys/rpc/authunix_prot.c:#define NGRPS 64
sys/rpc/svc_auth_unix.c:#define NGRPS            64

I wish to do that as a temporary solution, once we intend to do a complete
migration to OpenAFS soon.
But now, It's really important to have this working.
Migrate to NFSv4 first, will be too much work, especially on clients. (Only
the server is a FreeBSD machine)

Thanks in advance.

Regards

-- 
Knoseeker



On Wed, Apr 14, 2010 at 2:34 AM, Brooks Davis <brooks at freebsd.org> wrote:

> On Tue, Apr 13, 2010 at 11:00:48PM +0000, Knowledge Seeker wrote:
> > Hi,
> > I need to have my NFS server to authenticate more than 16 groups when
> there
> > is a file access.
> >
> > I would like to know if I can just redefine my MACROS to accomplish that.
> >
> > The macro would be: NGRPS,  because it is tested against the variable
> > ngroups which comes from NGROUPS value.
> >
> > /* gids compose part of a credential; there may not be more than 16 of
> them
> > */
> > #define NGRPS 16
> >
> > In:
> >
> > sys/rpc/authunix_prot.c
> > sys/rpc/svc_auth_unix.c
> > usr.sbin/rpc.lockd/kern.c
> > include/rpc/auth_unix.h
> > lib/libc/rpc/PSD.doc/xdr.nts.ms
> >
> > Is there any critical issue in change the defs and recompile the kernel
> and
> > the world?
>
> It won't work unless you also change the clients and then you will be
> sending invalid RPC packets over the wire.  If you can live with that it
> may well work.  The real answer is switch to NFSv4 and GSSAPI
> authentication where the group checking all takes place on the server
> where it belongs in the first place.
>
> -- Brooks
>