Description of problem: I have a client that has a need to have some form of alternative to 'showmount -e' when using NFSv4 server (ceph-nfs-ganesha). The dbus command is an option but they need to get the output from instances (OpenStack). Could there be a ganesha way, through a new option, where it would export the mounts it has. This way it could be queried and data fetch that way. One software engineer I spoke to thought it could be a possibility. I'm opening this BZ to see the feasibility of it. Version-Release number of selected component (if applicable): N/A How reproducible: N/A Steps to Reproduce: 1. N/A 2. 3. Actual results: With NFSv4 server, you can't have a list of mounts. Expected results: Find a way to have mounts listed Additional info:
The NFSv4 way to do this is to mount the pseudo-root ("/") and list the directories. There isn't otherwise any protocol or remote command to do this.
The problem is that not everything is exported at the root, so that won't tell you which mounts are actually filesystems. You'd have to traverse the entire tree looking for fsid transitions to determine that. What I suggested was adding an option to ganesha that would tell it to also expose v4-only mounts via MOUNTPROC3_DUMP. This would be a strictly opt-in thing for people that think they need showmount to work. We could even make this a per-export option as well. Though I do concede that this is a bit of an ugly hack.
Then what happens when someone does a v3 mount of that export?
Denied, just as we always would. We could (in principle) send a bogus filehandle in the dump in that case too.
Sorry, my bad -- not DUMP command but EXPORT command (that shows the export list).
This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle. Changing version to '31'.
This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle. Changing version to 31.
Hmm, not sure how I missed this one... Fundamentally we need some sort of network driven query to the server. Possible options: 1. DBUS (has issues in OpenStack 2. SNMP (dead) 3. showmount (RPC sideband protocol, can have issues with firewalls, also NFSv3 based) 4. Trigger some kind of log message or text file dump So for showmount (which uses the MNT_EXPORT RPC procedure), first off, it doesn't emit handles. We could if NFSv3 is otherwise disabled ONLY respond to NULL and EXPORT. However, that would result in NFSv3 mount attempts showing an error other than something that indicates the version isn't available which may be confusing. The rpcinfo command would also show the MOUNT protocol as active (though the NFS protocol would only show version 4). What sorts of management interface does OpenStack provide? Is there any way to hook into that?
Hmm, one more option, we could provide... We could actually have a "special" file in the Pseudo root which is basically a file interface to the same procedure than showmount triggers (including the same protections against showing clients exports they don't have access to). We add a config variable that specifies the name of this file and if that isn't configured the file doesn't exist. We want a config because some folks might have /exports/ as a directory in the PseudoFS while others might want to use /exports as the "special" file. The config could also specify permissions (and even an ACL). To access this information from a client you then: mount server:/ /mnt cat /mnt/special-export-file
> What sorts of management interface does OpenStack provide? Is there any way to hook into that? OpenStack Manila provides APIs for showing the export locations for a "share" rather than all the exports for an NFS server - e.g. $ manila share-export-location-list 1bafd6c6-5994-4b3b-81c7-8e6869621874 +--------------------------------------+------------------------------------------------------------------------+-----------+ | ID | Path | Preferred | +--------------------------------------+------------------------------------------------------------------------+-----------+ | 008c4e1e-0dc6-4bb5-bc09-ce82adcd39ce | 192.168.121.217:/volumes/_nogroup/e6fe0c79-c7eb-4cef-bfb6-e9ae59320d4c | False | +--------------------------------------+------------------------------------------------------------------------+-----------+ To use this command one needs to own the share (or otherwise have OpenStack policy rights to examine it). This provides some measure of security in that OpenStack tenant A can't discover the export locations for shares owned by OpenStack tenant B. In the case behind this BZ, the customer wants to be able to bypass these controls and just see all the exports at the service IP in order to facilitate mount automation from within the VM client without requiring that the client VM have OpenStack credentials. If we decide to offer this capability, I'm inclined to think it should be via a Ganesha configuration option. That way OpenStack will have it off by default (more secure). We can document how to turn it on if the OpenStack administrator decides that it's OK.
If this is still an issue please reopen