In message <ytxpr01mb0189f5614497d4fa96a7579add...@ytxpr01mb0189.canprd01.pr
OUTLOOK.COM>, Rick Macklem writes:
> Content-Type: text/plain; charset="iso-8859-1"
> Content-Transfer-Encoding: quoted-printable
> The attached one line patch to /etc/rc.d/nfsd modifies the script so that i=
> 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>@<domain> and this required
> the nfsuserd daemon to be running.
> (b) - RFC7530, which replace RFC3530, allows a Owner/Owner_group string to =
> the uid/gid number in a string when using AUTH_SYS. This simplifies confi=
> 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?)
> - never run nfsuserd after booting (killing it off after it has been runn=
> ing is not
> Given the above, it would seem that /etc/rc.d/nfsd should not force running=
> 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?
Cy Schubert <cy.schub...@cschubert.com>
FreeBSD UNIX: <c...@freebsd.org> Web: http://www.FreeBSD.org
The need of the many outweighs the greed of the few.
email@example.com mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"