Cy Schubert wrote: >Rick Macklem wrote: >> Hi, >> >> The attached one line patch to /etc/rc.d/nfsd modifies the script so that i= >> t >> does not force the nfsuserd to be run when nfsv4_server_enable is set. >> (nfsuserd can still be enabled via nfsuserd_enable=3D"YES" is /etc/rc.conf.= >> ) >> >> Here's why I think this patch might be appropriate... >> (a) - The original RFC for NFSv4 (RFC3530) essentially required Owners and >> Owner_groups to be specified as <user>_at_<domain> and this required >> the nfsuserd daemon to be running. >> (b) - RFC7530, which replace RFC3530, allows a Owner/Owner_group string to = >> be >> the uid/gid number in a string when using AUTH_SYS. This simplifies confi= >> guration >> for an all AUTH_SYS/POSIX environment (most NFS uses, I suspect?). >> >> To make the server do (b), two things need to be done: >> 1 - set vfs.nfsd.enable_stringtouid=3D1 >> 2 - set vfs.nfsd.enable_uidtostring=3D1 (for head, I don't know if it will = >> be MFC'd?) >> OR >> - never run nfsuserd after booting (killing it off after it has been runn= >> ing is not >> sufficient) >> =20 >> Given the above, it would seem that /etc/rc.d/nfsd should not force running= >> of >> the nfsuserd daemon, due to changes in the protocol. >> >> However, this will result in a POLA violation, in that after the patch, nfs= >> userd won't >> start when booting, unless nfsuserd_enable=3D"YES" is added to /etc/rc.conf= >> . >> >> So, what do people think about this patch? rick= > >How about a warning message + an UPDATING entry + no MFC? And, relnotes = >yes to say we now support RFC7530 in 12.0? Sounds fine to me. I'll wait to see if there are more comments. Thanks, rickReceived on Tue Jul 11 2017 - 09:48:59 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:12 UTC