might be enough for guaranteeing rpc.statd to start/stop altogether with nfsd when CTDB starts/stops the services on the nodes.
I have also to verify missing (or deactivated) environmental variables (NEED_GSSD or NEED_SVCGSSD, for example) brought by /etc/default/nfs-* and, nowadays, with systemd, read by script /usr/lib/systemd/scripts/nfs-utils_env.sh, generating an environment file in /run, executed by nfs-config.service as a "oneshot" service whenever nfs is restarted (will verify if any of those would change by CTDB, for example). This will cover your initial comment:
" ... ctdb is able to control NFS daemons, but it never looks for /etc/init.d/nfs-kernel-server for startup or /etc/default/nfs-kernel-server for settings ... ".
I'll have to think of something for the RPC ports :\. You said in comment #10 that this:
needed to be included in /etc/default/nfs-kernel-server, possibly because CTDB needs those environment variables (apart from the "same ports on all nodes need"). If CTDB manipulates systemctl to start/stop the services, then I would have to make sure those are parsed by the nfs-config.service logic (nfs-config -> nfs-utils_env.sh -> /run/sysconfig/nfs-utils environment file).
That would work for needed NFS_HOSTNAME environment variable.. and, for the ports, I could create systemd overrides to set all RPC services to the same port, or provide those commented and give the user a message to comment them out (since touching that during package installation does not seem appropriate to me).
We have 2 other things:
/etc/modprobe.d/lockd.conf -> that is most likely a no-go, like the LOCKD_UDPPORT=599 approach. I mean, at least not automatically (possibly commented, telling user to make sure its all commented out in all CTDB nodes).
And:
Disabling NFSv4.. (and rpc.idmapd), which could follow the same thing... providing information to final user about not having it enabled (specially because installing CTDB would require to have all nfs-* services disabled anyway, so CTDB postinst can't definitely activate systemd services by default, for example).
That is all I can think of to check/implement in Ubuntu Eoan. Please, let me know if there is anything else you can think of.
I'm testing all this in the following scenario:
2 gluster servers providing 1 volume to 3 ctdb servers in 1 network, and those 3 ctdb servers providing a NFS with LVS network IP to 2 NFS clients.
It is very likely that CTDB will need a similar work to make sure samba, for example, is supported, out-of-the-box, like what we are doing here, by Ubuntu CTDB package.
Robert,
I'll verify your patch on comment #6, since the nfs-kernel-server:
(k)inaddy@ ctdbserver01: /lib/systemd$ systemctl list-dependencies nfs-kernel- server. service server. service rpcgss- module. service service service service fs-nfsd. mount service
nfs-kernel-
● ├─auth-
● ├─nfs-config.
● ├─nfs-idmapd.
● ├─nfs-mountd.
● ├─proc-
● ├─rpc-svcgssd.
● ├─rpcbind.socket
● ├─system.slice
● └─network.target
might be enough for guaranteeing rpc.statd to start/stop altogether with nfsd when CTDB starts/stops the services on the nodes.
I have also to verify missing (or deactivated) environmental variables (NEED_GSSD or NEED_SVCGSSD, for example) brought by /etc/default/nfs-* and, nowadays, with systemd, read by script /usr/lib/ systemd/ scripts/ nfs-utils_ env.sh, generating an environment file in /run, executed by nfs-config.service as a "oneshot" service whenever nfs is restarted (will verify if any of those would change by CTDB, for example). This will cover your initial comment:
" ... ctdb is able to control NFS daemons, but it never looks for /etc/init. d/nfs-kernel- server for startup or /etc/default/ nfs-kernel- server for settings ... ".
I'll have to think of something for the RPC ports :\. You said in comment #10 that this:
NFS_HOSTNAME= "servername"
RQUOTAD_PORT=598 PORT=596 "$NFS_HOSTNAME"
LOCKD_UDPPORT=599
LOCKD_TCPPORT=599
STATD_PORT=595
STATD_OUTGOING_
STATD_HOSTNAME=
needed to be included in /etc/default/ nfs-kernel- server, possibly because CTDB needs those environment variables (apart from the "same ports on all nodes need"). If CTDB manipulates systemctl to start/stop the services, then I would have to make sure those are parsed by the nfs-config.service logic (nfs-config -> nfs-utils_env.sh -> /run/sysconfig/ nfs-utils environment file).
That would work for needed NFS_HOSTNAME environment variable.. and, for the ports, I could create systemd overrides to set all RPC services to the same port, or provide those commented and give the user a message to comment them out (since touching that during package installation does not seem appropriate to me).
We have 2 other things:
/etc/modprobe. d/lockd. conf -> that is most likely a no-go, like the LOCKD_UDPPORT=599 approach. I mean, at least not automatically (possibly commented, telling user to make sure its all commented out in all CTDB nodes).
And:
Disabling NFSv4.. (and rpc.idmapd), which could follow the same thing... providing information to final user about not having it enabled (specially because installing CTDB would require to have all nfs-* services disabled anyway, so CTDB postinst can't definitely activate systemd services by default, for example).
That is all I can think of to check/implement in Ubuntu Eoan. Please, let me know if there is anything else you can think of.
I'm testing all this in the following scenario:
2 gluster servers providing 1 volume to 3 ctdb servers in 1 network, and those 3 ctdb servers providing a NFS with LVS network IP to 2 NFS clients.
It is very likely that CTDB will need a similar work to make sure samba, for example, is supported, out-of-the-box, like what we are doing here, by Ubuntu CTDB package.
I'll get back to you soon.