Date: Sun, 29 Apr 2012 17:23:54 -0400 From: Robert Simmons <rsimmons0@gmail.com> To: freebsd-fs@freebsd.org Subject: Re: NFSv4 Questions Message-ID: <CA%2BQLa9BfKkZU8aJ%2BO7A_eYGgo7GyEq231bFe--YtnBXfYGh1KQ@mail.gmail.com> In-Reply-To: <1494135294.103829.1335731763653.JavaMail.root@erie.cs.uoguelph.ca> References: <CA%2BQLa9B4Xxc-4pCo8y4pgU1BBoBvC2xG4vA3Kydr-Q2dXWRpNw@mail.gmail.com> <1494135294.103829.1335731763653.JavaMail.root@erie.cs.uoguelph.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Apr 29, 2012 at 4:36 PM, Rick Macklem <rmacklem@uoguelph.ca> wrote: > Robert Simmons wrote: >> On Sun, Apr 29, 2012 at 9:09 AM, Rick Macklem <rmacklem@uoguelph.ca> >> wrote: >> > Robert Simmons wrote: >> >> I've been digging and digging to find sources to clarify the >> >> exports(5) man page with no luck. What I have read differs from >> >> what >> >> I see on my server. From the man page examples section: >> >> >> >> V4: / -sec=krb5:krb5i:krb5p -network 131.104.48 -mask 255.255.255.0 >> >> >> >> Now, here is what I have put as an experiment to try to understand >> >> what's happening here (my /etc/exports): >> >> >> >> V4: / -sec=krb5 -network 192.168.1 -mask 255.255.255.0 >> >> / >> >> >> >> In this case, -sec=krb5 is totally ignored. I can mount / using >> >> sys. >> >> >> > The "-sec=krb5" restriction applies to state related operations that >> > don't >> > use file handles. >> > The FreeBSD mount doesn't do any of those, so it is the options on >> > the second line >> > "/" that control whether or not the mount succeeds. >> > >> > With the above exports, the first Open of a file should fail when >> > attempted via auth_sys, >> > at least for the FreeBSD client. (The FreeBSD client doesn't try and >> > establish >> > state via SetClientID until the first Open. Some other clients do so >> > at mount time.) >> > >> > I know this is ugly, but I thought it would be confusing to have the >> > semantics >> > of the other export lines (like "/") different for NFSv4 than >> > NFSv2,3. For NFSv2,3 >> > all RPCs involve a file handle, so they can be associated with a >> > server volume. >> > For NFSv4, this is not the case, since some state related operations >> > (SetClientID/SetClientIDConfirm/Renew and maybe a couple of others) >> > do not use >> > a file handle and, as such, can't be associated with an exported >> > volume. I put >> > the options in the "V4:" for those, since I couldn't think of where >> > else to put >> > them. >> >> I think a rewrite of exports(5) might help out quite a lot. >> Especially if the EXAMPLES section was scrapped entirely and replaced >> with a set of examples each one more granular in explaining one >> feature or use case instead of lumping all of it into explaining one >> huge export file. >> >> Since I'm working on setting up a pair of NFS servers with a set of >> clients, I volunteer. May I contact you offlist if I have questions? >> > Sure. However, I'd suggest that you get others to review it as well, since > I kinda know how it works and won't spot "missing bits", although I should > be able to catch most inaccuracies. > > Also, be sure to check "man nfsv4" and maybe reference it (it is currently > in the See Also list, but that might not be strong enough). Understood. >> >> If I use this: >> >> >> >> V4: / >> >> / -sec=krb5 >> >> >> >> It requires proper kerberos authentication. >> >> >> > Yep, as explained above. If you really want to restrict NFSv4 use to >> > kerberos, >> > then you should put the "-sec=krb5" on the V4: line and all lines >> > exporting >> > volumes. For example: >> > V4: / -sec=krb5 >> > / -sec=krb5 >> >> Got it. >> >> >> My next question is can I reject NFSv3/v2 clients/connections? >> >> >> > sysctl vfs.nfsd.server_min_nfsvers=4 >> >> Perfect. >> >> >> Third question is: how can I disable rpcbind? It seems that the >> >> following does not work in rc.conf: >> >> rpcbind_enable="NO" >> >> When I'm running NFSv4 rpcbind is not needed, but it seems that >> >> mountd >> >> always starts rpcbind no matter what I do: >> >> /etc/rc.d/rpcbind stop >> >> is the only way to do it, and that is only after boot, or mountd >> >> starting. >> >> _ >> > Yea, I suppose there should be a -nfsv4-only option on mountd, so it >> > knows that it only needs to do exports and doesn't need rpcbind. >> > Since you are probably the first person wanting an NFSv4 only >> > server, >> > I hadn't thought to do this. I'll put it on my "to do" list. >> >> If I may, perhaps a switch in /etc/rc.conf: >> nfsv4_only="YES" >> > I might call it nfsv4_server_only, but sounds like a good suggestion. > >> This would set the -nfsv4-only switch you mention for mountd, and it >> would set vfs.nfsd.server_min_nfsvers=4 >> > It could also be used by /etc/rc.d/mountd to indicate "don't force rpcbind". > > Have fun with it, rick Another thing to note about the behavior of mountd and the instructions in nfsv4(4): The three recommended lines to add to rc.conf are: nfs_server_enable="YES" nfsv4_server_enable="YES" nfsuserd_enable="YES" With only these three, if you change something in /etc/exports and want to kick mountd to have it reread the file, you get the following error: Cannot 'restart' mountd. Set mountd_enable to YES in /etc/rc.conf or use 'onerestart' instead of 'restart'. Would there be a drawback to suggesting setting mountd_enable in man page to avoid this? In other words, is there a reason this is setup this way?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CA%2BQLa9BfKkZU8aJ%2BO7A_eYGgo7GyEq231bFe--YtnBXfYGh1KQ>