Description of problem:
Cockpit does not provide a way to configure any aspects of NFS configuration.
There should be a way to set the NFSv4 domain.
Not required by this RFE but nice to have:
Mounting remote filesystems.
This should be a high level API which takes care to perform the necessary platform tasks (service restarts if needed).
Can we somehow raise the priority of this item?
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
Also tracked in upstream trello: https://trello.com/c/PZPciouD/146-nfs-client-configuration
I've created a wiki page for this feature here:
(In reply to Ryan Barry from comment #0)
> Description of problem:
> Cockpit does not provide a way to configure any aspects of NFS configuration.
> There should be a way to set the NFSv4 domain.
Let's start with setting the NFSv4 domain.
I don't know what a NFSv4 domain is. Can you point to some documentation?
How do you set the NFSv4 domain without Cockpit?
It's used for kerberized NFSv4.
We set it in the past by directly setting values in the file.
> We set it in the past by directly setting values in the file.
Sorry, I, dumb. Which file, what values?
Can you show a concrete shell/vi session that you would like to be replaced with clicking buttons in Cockpit?
Literally only "domain" in /etc/idmapd.conf
(In reply to Ryan Barry from comment #19)
> Literally only "domain" in /etc/idmapd.conf
So what's left here is setting the NFS 4 domain in /etc/idmapd.conf; the NFS client functionality for adding transient or permanent NFS mounts has existed for a while.
I experimented a bit with domain and ID mapping. On the server and client I added this to idmapd.conf:
Method = static
Domain = cockpit.lan
joe = joe
On the server, "joe" has uid 1002, on the client it has uid 1001. With just that, of the file on the client always appears to have uid:gid 1002:1002, i. e. is not mapped to the local "joe" user.
But when disabling the disabling (yay how confusing) of idmapping on the server with
echo N > /sys/module/nfsd/parameters/nfs4_disable_idmapping
systemctl restart nfs-idmapd
it works , i. e. the file now appears to belong to the local "joe" user. However, this is *independent* of the Domain= setting on the client, I can also set it to "Domain = foo" or leave it undefined, and it still works.
So it appears to me without a kerberos setup, that Domain= is completely irrelevant, and there is no way to demonstrate/test the NFS domain usage.
But with IPA/kerberos, what is the use case for setting a domain there? Wouldn't/shouldn't that always be the kerberos realm? What is the use case of having the NFS idmap domain be different from the kerberos one, if all the "global" user names are qualified by the krb domain anyway?
I. e. I'm still struggling with an actual use case / demonstration / detailed reproducer here. The documentation (https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/storage_administration_guide/ch-nfs and man idmapd.conf) say "domain must be the same on client and server", but don't give any details, and as shown above I don't see why a user would actually change this, and how to explain this in the UI.
Bug was acked for 7.5 but missed 7.5 (and 7.6).
Can we get a target mileston for having this bug fixed? 7.6.z? 7.7?
There is no target release yet, as the issue hasn't been well-defined yet. See comment #23. Before we can actually replicate the problem, we can't start on a solution.
Not included in 7.7, retrying with 8.1 for RHV 4.4
Setting back needsinfo, see https://bugzilla.redhat.com/show_bug.cgi?id=1228349#c23 -- it's still totally unclear to me what exactly is being asked here and how to test it.
Adding needinfo on Yuval
Sorry, I'm not sure I understand this as well, adding Ryan
We pretty much rely on this being handled by platform. That said, this is a very old RFE originally opened to get RHVH 4.x on feature parity with 3.x (and even there, the only QE was checking that the values were set). With no tickets in years, I'd suggest closing
According to comment #33 closing this with resolution wontfix.