Re: small patch for /etc/rc.d/nfsd, bugfix or POLA violation?

[Benjamin Kaduk]

On Tue, Jul 11, 2017 at 11:48:55AM +, Rick Macklem wrote:
> Cy Schubert wrote:
> >
> >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.

Yes, this seems like the sort of thing best done on a major version
boundary and not MFC'd.

-Ben
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: small patch for /etc/rc.d/nfsd, bugfix or POLA violation?

[Rick Macklem]

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 @ 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, rick


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: small patch for /etc/rc.d/nfsd, bugfix or POLA violation?

[Cy Schubert]

In message , Rick Macklem writes:
> --_002_YTXPR01MB0189F5614497D4FA96A7579ADDA80YTXPR01MB0189CANP_
> Content-Type: text/plain; charset="iso-8859-1"
> Content-Transfer-Encoding: quoted-printable
> 
> 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 @ 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?

-- 
Cheers,
Cy Schubert 
FreeBSD UNIX:     Web:  http://www.FreeBSD.org

The need of the many outweighs the greed of the few.


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

small patch for /etc/rc.d/nfsd, bugfix or POLA violation?

[Rick Macklem]

Hi,

The attached one line patch to /etc/rc.d/nfsd modifies the script so that it
does not force the nfsuserd to be run when nfsv4_server_enable is set.
(nfsuserd can still be enabled via nfsuserd_enable="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 @ 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 
configuration
  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=1
2 - set vfs.nfsd.enable_uidtostring=1 (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 running 
is not
sufficient)
  
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, 
nfsuserd won't
start when booting, unless nfsuserd_enable="YES" is added to /etc/rc.conf.

So, what do people think about this patch? rick

nfsd-rcd.patch
Description: nfsd-rcd.patch
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"