https://bugzilla.novell.com/show_bug.cgi?id=748053 https://bugzilla.novell.com/show_bug.cgi?id=748053#c1 Neil Brown changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID --- Comment #1 from Neil Brown 2012-03-12 23:02:18 UTC --- NFS_SECURTY_GSS does not force anyone to use GSS, it just makes it available. Both the server process and the client process of NFS_SECURITY_GSS are identical - they cause certain modules to be loaded into the kernel. The same module is used by the server and client. So sharing there is the correct thing to do. NFS4_SUPPORT is very similar. It cause idmapd to be run - this daemon is used equally by server and client. You cannot run just half of it, and would not want to. 'grepping' for things in /etc/fstab is not a reliable indicator that the feature might be wanted. For example, if an automounter is used to mount NFS filesystems, it might want GSS and NFSv4 without either being mentioned in /etc/fstab. grepping /etc/exports might be a little more reliable, however the "fsid=0" tag a temporary mechanism to indicate v4 usage until proper 'pseudo root filesystem' functionality is provided (which is now ready upstream I believe). So grepping for that would not be future-proof. In short: there is no real problem here and the suggested fixes are not appropriate. If you have an actual symptom of an actual problem, please re-open and report that. Until then, this is resolved as Invalid. thanks anyway. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=748053 https://bugzilla.novell.com/show_bug.cgi?id=748053#c3 Neil Brown changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |NEEDINFO InfoProvider| |mfilka@suse.com --- Comment #3 from Neil Brown 2012-03-13 07:35:52 UTC --- It seems that problem is that yast cannot manage one sysconfig variable from two different config pages. So maybe the easiest thing to do is to add another config variable NFS_SECURITY_GSS_CLIENT and then change the nfs-utils scripts to "or" that into the original. Would that solve the problem? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=748053 https://bugzilla.novell.com/show_bug.cgi?id=748053#c5 Neil Brown changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |INVALID --- Comment #5 from Neil Brown 2012-05-03 04:44:55 UTC --- (In reply to comment #4)

In my opinion, it is not YaST problem. I think that the problem is that two components (yast2-nfs-server, yast2-nfs-client) can independently (and correctly) require different value for one shared variable (NFS_SECURITY_GSS).

This is not correct, as I tried to explain above. You cannot enable gss separately for the client and the server. That is not possible. It is either enabled for both or for neither. Whether the client actually uses gss depends on how each filesystems is mounted. Whether the server uses it depends on how remote clients perform mounts. But you simply cannot enable it for one without the other. The same is very nearly true for NFSv4. There is a slight difference but not an important one. If you might need GSS at all, you should enable it. If you might need NFSv4 at all you should enable it. Then either can be used, or not, as required. A script simply cannot tell what a sysadmin might want to do, so a script cannot help. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.