Re-exporting mounted NFS file system using Ganesha?
Hi. We'd like to use Ganesha for this purpose using the VFS FSAL. However, it seems Ganesha can only do a Proxy re-export from another NFS server. This does not work for our use case for security reasons. Looking at the code, I found the following in FSAL/commonlib.c: static void posix_create_file_system(struct mntent *mnt) { struct fsal_filesystem *fs; struct avltree_node *node; if (strncasecmp(mnt->mnt_type, "nfs", 3) == 0) { LogDebug(COMPONENT_FSAL, "Ignoring %s because type %s", mnt->mnt_dir, mnt->mnt_type); return; } Is there a reason why you don't allow NFS mounts to be re-exported using VFS FSAL? Thanks. -Jeff
Historically NFS has not been re-exportable. I know that since we started on Ganesha, the NFS client has added functions so that name_to_handle_at and open_by_handle_at system calls will work. I'm not sure there wouldn't be hidden issues with re-exporting this way. You could try removing the restriction and see if it works, but don't be surprised if there is some issue. Frank
-----Original Message----- From: Becker, Jeffrey C. (ARC-TN)[InuTeq, LLC] [mailto:jeffrey.c.becker@nasa.gov] Sent: Wednesday, December 4, 2019 2:55 PM To: ganesha-devel <devel@lists.nfs-ganesha.org> Subject: [NFS-Ganesha-Devel] Re-exporting mounted NFS file system using Ganesha?
Hi. We'd like to use Ganesha for this purpose using the VFS FSAL. However, it seems Ganesha can only do a Proxy re-export from another NFS server. This does not work for our use case for security reasons. Looking at the code, I found the following in FSAL/commonlib.c:
static void posix_create_file_system(struct mntent *mnt) { struct fsal_filesystem *fs; struct avltree_node *node;
if (strncasecmp(mnt->mnt_type, "nfs", 3) == 0) { LogDebug(COMPONENT_FSAL, "Ignoring %s because type %s", mnt->mnt_dir, mnt->mnt_type); return; }
Is there a reason why you don't allow NFS mounts to be re-exported using VFS FSAL? Thanks.
-Jeff _______________________________________________ Devel mailing list -- devel@lists.nfs-ganesha.org To unsubscribe send an email to devel-leave@lists.nfs-ganesha.org
OK. I just cloned the latest nfs-ganesha git tree, and found that get_in_addr disappeared from include/gsh_rpc.h and RPCAL/rpc_tools.c. Did something replace it? Thanks. -Jeff ________________________________________ From: Frank Filz <ffilzlnx@mindspring.com> Sent: Wednesday, December 4, 2019 4:24 PM To: Becker, Jeffrey C. (ARC-TN)[InuTeq, LLC]; 'ganesha-devel' Subject: [EXTERNAL] RE: [NFS-Ganesha-Devel] Re-exporting mounted NFS file system using Ganesha? Historically NFS has not been re-exportable. I know that since we started on Ganesha, the NFS client has added functions so that name_to_handle_at and open_by_handle_at system calls will work. I'm not sure there wouldn't be hidden issues with re-exporting this way. You could try removing the restriction and see if it works, but don't be surprised if there is some issue. Frank
-----Original Message----- From: Becker, Jeffrey C. (ARC-TN)[InuTeq, LLC] [mailto:jeffrey.c.becker@nasa.gov] Sent: Wednesday, December 4, 2019 2:55 PM To: ganesha-devel <devel@lists.nfs-ganesha.org> Subject: [NFS-Ganesha-Devel] Re-exporting mounted NFS file system using Ganesha?
Hi. We'd like to use Ganesha for this purpose using the VFS FSAL. However, it seems Ganesha can only do a Proxy re-export from another NFS server. This does not work for our use case for security reasons. Looking at the code, I found the following in FSAL/commonlib.c:
static void posix_create_file_system(struct mntent *mnt) { struct fsal_filesystem *fs; struct avltree_node *node;
if (strncasecmp(mnt->mnt_type, "nfs", 3) == 0) { LogDebug(COMPONENT_FSAL, "Ignoring %s because type %s", mnt->mnt_dir, mnt->mnt_type); return; }
Is there a reason why you don't allow NFS mounts to be re-exported using VFS FSAL? Thanks.
-Jeff _______________________________________________ Devel mailing list -- devel@lists.nfs-ganesha.org To unsubscribe send an email to devel-leave@lists.nfs-ganesha.org
OK. I just cloned the latest nfs-ganesha git tree, and found that get_in_addr disappeared from include/gsh_rpc.h and RPCAL/rpc_tools.c. Did something replace it? Thanks.
It was unused in the current code, and is trivial. It's also not IPv6 safe, returning 0 for non-AF_INET addresses. We have steadily been trying to attain 100% IPv6 compatibility so retaining a very IPv4 only function makes no sense. Frank
participants (2)
-
Becker, Jeffrey C. (ARC-TN)[InuTeq, LLC] -
Frank Filz