From owner-freebsd-fs@FreeBSD.ORG Sun Apr 29 22:55:50 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4531D106566B for ; Sun, 29 Apr 2012 22:55:50 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id D0E648FC08 for ; Sun, 29 Apr 2012 22:55:49 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8EAMrGnU+DaFvO/2dsb2JhbABEhWitOIIJAQEBBAEBASArIAsFFg4KAgINGQIpAQkmBggHBAEcBIdsC6Z+kX+BL4ldhH6BGASTT4IvgRGPMYMEgUA X-IronPort-AV: E=Sophos;i="4.75,502,1330923600"; d="scan'208";a="167153896" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 29 Apr 2012 18:55:32 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 5303BB3EB3; Sun, 29 Apr 2012 18:55:32 -0400 (EDT) Date: Sun, 29 Apr 2012 18:55:32 -0400 (EDT) From: Rick Macklem To: Robert Simmons Message-ID: <393972009.105652.1335740132289.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.203] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: freebsd-fs@freebsd.org Subject: Re: NFSv4 Questions X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Apr 2012 22:55:50 -0000 Robert Simmons wrote: > On Sun, Apr 29, 2012 at 4:36 PM, Rick Macklem > wrote: > > Robert Simmons wrote: > >> On Sun, Apr 29, 2012 at 9:09 AM, Rick Macklem > >> > >> 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? Nope. Adding mountd_enable="YES" would be fine, as far as I know. (I never use the scripts to kill/restart stuff.) rick > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org"