On 2/7/19 1:14 PM, Frank Filz wrote:
-----Original Message----- From: Jeff Becker [mailto:jeffrey.c.becker@nasa.gov] Sent: Thursday, February 7, 2019 12:08 PM To: dang@redhat.com; Frank Filz <ffilzlnx@mindspring.com>; support@lists.nfs- ganesha.org Subject: [NFS-Ganesha-Support] Re: NFS4 reexporter question
That looks promising. Just to be clear, /top/export* are all PROXY FSAL? Thanks. Yes, what I'm not sure is that PROXY indeed supports multiple exports. That may have been added in the recent work.
Frank
Is it supported in v2.7.1? That's the version I built from your git repo. Thanks. -Jeff
-Jeff
On 2/7/19 11:30 AM, Daniel Gryniewicz wrote:
No, NFSv4 doesn't work that way. However, because of the way the pseudoFS works, you can put all the exports on subdirs of a single directory, and then mount the root dir, like this:
/top/export1
/top/export2
/top/export3
/top/export4
then, on the client, you mount /top, which is a directory in the pseudoFS that's automatically created for you. You can even, if you want, export in /export1, /export2, and so on, and then mount /
Daniel
On 2/7/19 1:45 PM, Jeff Becker wrote:
I guess I wasn't clear. What I'd like is to have a single export with subdirectories that are NFS mount points. This would have a single corresponding pseudo path. Is that possible? Thanks.
-Jeff
On 2/7/19 5:13 AM, Daniel Gryniewicz wrote:
Sure, should work fine. Ganesha handles multiple exports fine, either by the same FSAL, or multiple FSALs, or combinations. The only caveat is that, if one of the exports uses the pseudo path "/", then all the paths to the other exports must exist in the backing FS for that export. It's much easier to just give every export a unique pseudo path.
Daniel
On 2/5/19 12:44 PM, Jeff Becker wrote:
Thanks to everyone for their help. I got this working on a single NFS4 proxy export. My use case is a bit different. What I'd like to do is export a ganesha server directory that mounts several remote directories over NFS. Can I do this using FSAL PROXY or possibly even VFS? Thanks.
-Jeff
On 1/28/19 1:51 PM, Frank Filz wrote: >> Another question.. >> >> On 1/28/19 9:58 AM, Daniel Gryniewicz wrote: >>> On 1/28/19 12:45 PM, Jeff Becker wrote: >>>> One more question below... >>>> >>>> On 1/28/19 9:37 AM, Daniel Gryniewicz wrote: >>>>> A lot of that looks very out-of-date. The description of what >>>>> goes in the Path statement is correct, but there is no longer >>>>> an NFSv4_Proxy section. Instead, configuration goes in the >>>>> FSAL subsection of the export. You can look at the sample >>>>> proxy.conf in the repo here: >>>>> >>>>> https://github.com/nfs-ganesha/nfs-ganesha/blob/next/src/confi >>>>> g_samp >>>>> >>>>> les/proxy.conf >>>>> >>>>> >>>>> Or you can look at the man page for FSAL PROXY here: >>>>> >>>>> https://github.com/nfs-ganesha/nfs-ganesha/blob/next/src/doc/m >>>>> an/gan >>>>> >>>>> esha-proxy-config.rst >>>>> >>>>> >>>>> (And sorry for writing PSEUDO in my last email, I meant PROXY) >>>>> >>>>> Daniel >>>>> >>>>> On 1/28/19 12:29 PM, Jeff Becker wrote: >>>>>> Hi, >>>>>> >>>>>> On 1/25/19 5:36 AM, Daniel Gryniewicz wrote: >>>>>>> The path given to PSEUDO needs to be the full path exported >>>>>>> by the other NFS server, not any kind of local mount. So, >>>>>>> when you mount the other server directly, you do this: >>>>>>> >>>>>>> mount -t nfs <server>:<remotepath> <localpath> >>>>>>> >>>>>>> What needs to go in that Path config statement is >>>>>>> <remotepath> not <localpath>. PSEUDO isn't accessing a >>>>>>> mount (and, indeed, you probably should not have the remote >>>>>>> server mounted on the Ganesha box), it's acting as it's own >>>>>>> NFS client, and translating NFS calls directly. >>>> Do you mean on the client mounting the Ganesha server, I should >>>> not also be directly mounting the remote filesystem for which >>>> the Ganesha server is proxying access? Thanks. >>>> >>> Hmm... I think a full explanation is necessary. There are three >>> machines involved here. First, the original NFS server, hosting >>> the base filesystem. Lets call this server O, for original. >>> Next, there's the Ganesha server, which we'll call G. Finally, >>> there's the Client, which we'll call C. They're likely >>> connected something like this: >>> >>> O -------- G -------- C >>> >>> O has one path, when it comes to NFS: it's export path. Let's >>> call this /exportO. If you were to mount this on a client >>> directly, you would use a command like this: >>> >>> mount -t nfs O:/exportO /mnt >> This is helpful. However, it's not clear how to specify specific >> clients or client ranges in the Export block. I don't want it to >> be the case that anyone can mount the Ganesha test server. >> Thanks. > So in your EXPORT block, make sure the Access is something you > want all clients to have (maybe none, could be read-only). > > Add at least one CLIENT sub-block, here's a sample from my > development test config: > > CLIENT > { > Access_Type=RW; > Squash=None; > Clients=simple1*,127.0.0.1,local*,192.168.0.119,192.168.0.111; > SecType = sys; > Anonymous_gid = -5; > } > > The clients list can list individual host names, host name wild > cards, individual IP addresses, netgroups, and IP net masks (in > CIDR form, for example 127.0.0.0/8). IPv6 addresses should be > supported... > > The CLIENT blocks are considered in order (thus they form an ACL, > you could exclude part of a sub-net by listing it with > Access_Type=none; first, and then the sub-net with Access_Type=RW; > second). The permissions in the EXPORT are considered next, and > then the global EXPORT_DEFAULTS block and finally the code defaults. > > Any option that is not specified at one layer will pick it's value > of from the first layer specified (finally the code defaults if > not specified at all). > > Frank >
Support mailing list -- support@lists.nfs-ganesha.org To unsubscribe send an email to support-leave@lists.nfs-ganesha.org