[NFS-Ganesha-Support] Re: NFS4 reexporter question

> -----Original Message----- > From: Jeff Becker [mailto:jeffrey.c.becker@nasa.gov] > Sent: Thursday, February 7, 2019 12:08 PM > To: dang(a)redhat.com; Frank Filz <ffilzlnx(a)mindspring.com>; support(a)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

> -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(a)lists.nfs-ganesha.org To unsubscribe send an > email to support-leave(a)lists.nfs-ganesha.org