On 6/14/22 07:13, Neal Gompa wrote:
On Tue, Jun 14, 2022 at 6:53 AM Peter Boy <pboy(a)uni-bremen.de>
wrote:
>
>
>
>> Am 14.06.2022 um 06:25 schrieb Matthew Miller <mattdm(a)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.