docker: add option to force hostname for linstor

[WanzenBug]

Add a new environment variable that, if set, forces the LINSTOR components to run with a specific hostname.

This may be useful in an environment where we don't have complete control over the names of the created containers, such as kubernetes. While LINSTOR is capable of dealing with changing hostnames, it does lead to weird issues later:

• LINSTOR names connections based on the peers uname. If that uname is changed, LINSTOR tries to update the resource, but renaming the connection does not always work.
• For TLS to work, we use the peer name as the name to validate in the certificate. However, if the name is not under our control, it is hard to generate a certificate that is valid for the names.
• Some external components such as monitoring and so on also rely on the peer name to generate useful output.

So in order to have a stable hostname for LINSTOR and DRBD, we add an option to start LINSTOR in a new UTS namespace with the forced hostname set.

We use a new UTS namespace because if we would just force the hostname to be set in all cases, we potentially override the "root" namespace if the container is started in the host network. We do not want to make unneeded changes to the host, so using a new UTS namespace is the simplest solution.

Using unshare with a new UTS namespace also means that the created namespace is automatically removed once the LINSTOR processes exits.

We also update the await-election tool: this now uses execve() to run the command when not running the leader election. This means that in case a satellite is started, the entry.sh script will become PID 1 in the container. This in turn makes the unshare()-d process PID 1, which is nice, as now docker|kubectl exec'ing into the container will also put us into the same namespace, so all drbdadm commands will work as expected.

[WanzenBug]

unshare needs certain privs, how does that match running the LINSTOR controller unprivileged?

It doesn't really. I mostly added the option for the controller for symmetry, but I could also remove it: it only really makes sense for Satellites, which already need to run as privileged containers, so unshare is fine.

[rck]

It doesn't really. I mostly added the option for the controller for symmetry, but I could also remove it: it only really makes sense for Satellites, which already need to run as privileged containers, so unshare is fine.

totally agree, only makes sense for the satellite and there it is fine. Then I suggest you remove it from the controller call, just we don't raise some "expectations"