On 6/14/22 07:13, Neal Gompa wrote:
On Tue, Jun 14, 2022 at 6:53 AM Peter Boy pboy@uni-bremen.de wrote:
Am 14.06.2022 um 06:25 schrieb Matthew Miller mattdm@fedoraproject.org:
On Mon, Jun 13, 2022 at 11:08:21PM +0200, Peter Boy wrote:
So we might have to handle this differently for desktop type and server type systems.
I think the key difference is whether basic configuration is expected as part of Anaconda, or whether there's a further configuration step. The first approach is common for individual desktop or server installs. But the latter is common for image-based installs -- whether it be Fedora IoT or a server VM or cloud image, or a pre-installed desktop.
Given that cloud-init, for example, can configure a system as fine-grained as Anaconda, I think it's more about whether a system is running in a managed or unmanaged environment.
Practically more important seems to me that Anaconda on the workstation live medium is so reduced that you can configure neither the network nor a hostname (only keyboard, storage medium and time zone). Therefore, we need to configure a plausible default hostname on desktops anyways, and the Change Proposal is for server type systems only.
And with server type systems, perhaps we can assume that system administrators knows what they are doing?
In my experience, this statement is so rarely true (in terms of understanding the full consequences of choices and defaults) that it's a bad cop-out. Anaconda does not require you to set a hostname as part of installation. Since it does not require that, having a decent fallback hostname is useful. The problem is that when you have multiple machines with the same hostname, WINS/DNS and mDNS are completely unusable.
This Change originally came out of Fedora CoreOS, where OpenShift couldn't tolerate machines with the "fedora" hostname[1]. The problem is that the machine-config-operator doesn't know how to handle fallback hostnames *at all* and has hard coded logic to fix the hostname only if it's "localhost". The operator's logic has not been fixed to determine whether the machine's hostname is a fallback hostname (and thus eligible to be reconfigured). If there was an easy way for the operator code to determine that we're running with the fallback hostname so that it knows to replace it, that would allow OpenShift folks to fix the problem on their end.
I think the OpenShift example is a good example of a class of problems. If I thought we'd never hit this problem again if we just changed that OpenShift code then I would go that route instead of this route.
I would be happy to withdraw this Change if we had solutions to these problems, because from a Fedora Cloud perspective, we basically nearly never hit the fallback case except for Vagrant (where it makes sense to have it trigger). For desktops, we'd prefer to have the fallback hostname be "fedora", but fixing it so that a randomly generated string is appended would make it work properly in the multi-machine home network case (which is commonplace these days).
I would still prefer to not withdraw this change. If we could make changes to make it more likely that a user will set a hostname properly then that is great and they won't hit the fallback case.