Bug 748053

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.

The problem is that I need to add "Enable NFSv4" (see bnc#681190; which is NFS_SECURITY_GSS="yes" in the file /etc/sysconfig/nfs) into yast2-nfs-client. However this can cause conflict with similar setup for yast2-nfs-server. 

The proposed solution is suggestion how to find out that (e.g.) yast2-nfs-server requires NFS_SECURITY_GSS=yes, otherwise configuration of yast2-nfs-server can be influenced by setup in yast2-nfs-client.

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?

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).

Introduce new variable *_CLIENT may work. However, it will lead to cascade of cloning. As I can see it, at least NFS4_SUPPORT should be cloned too. This was the reason why I tried to script it in the original post.

(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.