nfsserver: Fix NFSv4 lock failover: set NFS Server Scope (#1688)
- Fix NFSv4 lock failover: set NFS Server Scope
Problem: https://github.com/ClusterLabs/resource-agents/issues/1644
RFC8881, 8.4.2.1 State Reclaim:
| If the server scope is different, the client should not attempt to |
| reclaim locks. In this situation, no lock reclaim is possible. |
| Any attempt to re-obtain the locks with non-reclaim operations is |
| problematic since there is no guarantee that the existing |
| filehandles will be recognized by the new server, or that if |
| recognized, they denote the same objects. It is best to treat the |
| locks as having been revoked by the reconfiguration event. |
That's why for lock reclaim to even be attempted, we have to define and set
the same server scope for NFSD on all cluster nodes in the NFS failover
cluster. And in linux, that is done by setting the uts nodename for the
command that starts the nfsd kernel threads.
For "init scripts", just set it directly using unshare --uts.
For systemd units, add NFS_SERVER_SCOPE to some environment files
and inject the "unshare --uts" into the ExecStart command lines
using override drop-in files.
- Fix NFSv4 lock failover: set NFS Server Scope, regardless of EXEC_MODE
Debian (and other systems) may provide "init scripts",
which will only redirect back to systemd.
If we just unshare --uts the init script invocation,
the uts namespace is useless in that case.
If systemd is running, mangle the nfs-server.service unit,
independent of the "EXEC_MODE".
- Fix NFSv4 lock failover: add missing "|cut -f1" in remove_unshare_uts_dropins
- Fix NFSv4 lock failover: get rid of "world-inaccessible" warning
by temporarily changing the umask before generating the dropins
- Fix NFSv4 lock failover: deal with "special executable prefix" chars in ExecStart
- Fix NFSv4 lock failover: add rpc-statd-notify to the comment list of potentially interesting services