Date: Thu, 26 Aug 2010 15:06:11 -0400 From: jhell <jhell@DataIX.net> To: Heinrich Rebehn <rebehn@ant.uni-bremen.de> Cc: freebsd-stable@freebsd.org Subject: Re: zfs sharenfs with multiple hosts/networks and options Message-ID: <4C76BB23.50606@DataIX.net> In-Reply-To: <3D57D985-4B4D-4657-86E0-C93EFB3549CC@ant.uni-bremen.de> References: <3D57D985-4B4D-4657-86E0-C93EFB3549CC@ant.uni-bremen.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On 08/25/2010 03:47, Heinrich Rebehn wrote: > Hi list, > > with traditional /etc/exports i can do > > /export/linux/root -ro xxx.xxx.xxx.0/24 > /export/linux/root -maproot=0 xxx.xxx.xxx.1 > > How can i do this using zfs's sharenfs option? > > When i try > > zfs set sharenfs="-ro -network xxx.xxx.xxx.0/24,-maproot=0 xxx.xxx.xxx.1" data/linux/root > > /var/log/messages shows "network/host conflict" and "bad exports list line. > > The general problem seems to be that with each "zfs set sharenfs" command, the corresponding in /etc/zfs/exports gets overwritten. > > Is there a workaround for this besides ignoring sharenfs and using hand edited /etc/exports? > > Thanks for any help, > Hi Heinrich, All the sharenfs property is actually doing and maybe not exactly in this order is modifying /etc/zfs/exports with the interpreted contents of the sharenfs property and using a syntax that the native mountd(8) understands or at least tries to in a very simple way. After this is all done, mountd(8) recieves a HUP signal to inform if to reread /etc/exports & /etc/zfs/exports. So traditionally everything is happening the way it always has been except for the fact your now using the zfs(1M) Sun command with our own patch on top of that to make it look like its doing what you see in *Solaris or at least the interpreted version. Currently we do not have a/the share(1M) command implemented. My suggestion would be to write a script either in Python or Perl or maybe even in C to parse your own command line arguments and adjust /etc/exports or /etc/zfs/exports accordingly depending on the type of filesystem your arguments point to and then send signal HUP to mountd(8). This will at least be a little more under your control without having to modify sources and deal with conflicts later. I would recommend that you disable using the sharenfs property at all if you choose to go this route as you may start to find inconsistencies among your shares. The reference code where this is all happening is: cddl/compat/opensolaris/misc/fsshare.c Disable handling of the sharenfs property (ZFS_PROP_SHARENFS): cddl/contrib/opensolaris/lib/libzfs/common/libzfs_dataset.c Personally I would love to see our version of the sharenfs version translated into something that is local to FreeBSD only like the org.freebsd:swap local property that we use to enable swap on zvol's. My theorized version of this would look a little like the following. zfs set \ org.freebsd:nfs='ro=@192.168.1.0/24,root=0; rw=@192.168.2.1,root=514' org.freebsd:nfs4='V4: ......' Where options are separated by commas and shares to different hosts or networks are separated by semicolons. But if you don't want to go through all this then you could always designate /etc/zfs/exports as a permanent share for users that are allowed to write and administered by the sharenfs property. And use /etc/exports as your extraneous read-only shares. Just a thought. Anyway! enough said. Good luck on your mission. Regards, -- jhell,v
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4C76BB23.50606>