On Tue, Jun 14, 2022 at 6:53 AM Peter Boy <pboy@xxxxxxxxxxxxx> wrote: > > > > > Am 14.06.2022 um 06:25 schrieb Matthew Miller <mattdm@xxxxxxxxxxxxxxxxx>: > > > > 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 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). [1]: https://github.com/coreos/fedora-coreos-tracker/issues/649 -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
