On 6/14/22 07:13, Neal Gompa wrote: > 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 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. _______________________________________________ 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
