Am 14.06.2022 um 13:13 schrieb Neal Gompa
<ngompa13(a)gmail.com>:
On Tue, Jun 14, 2022 at 6:53 AM Peter Boy <pboy(a)uni-bremen.de> wrote:
>
>
>
>
> 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.
If I try to summarise all the comments and discussions, the change proposal, as it is, is
not perfect. But each participant can be happy with the resulting configuration.
- desktops, because nothing changes for them
- cloud, they use cloud-init to configure hostname anyway on first boot with the exception
of vagrant, where localhost can be useful
- CoreOS, use localhost already, but it resolves the OpenShift issue
- IoT, may have so set hostname explicitly, but don’t have any objection
- Server, usually set hostname explicitly according to some local naming convention or use
DHCP/revers DNS, gain the option to use some post-installation tools, and otherwise don’t
care anyway or doesn’t matter if it is fedora or localhost
So, it is fine to go with it.
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).
Attaching a somehow generated unique string would be really an improvement. But that would
be another Change Proposal, maybe for F38.
This would affect desktops in particular. All others should be given the option to switch
to this unique default or to leave it at localhost.
I think for servers a unique default would be useful, especially for a bulk creation of
server VMs in an un-managed environment. But we would have to change the default naming of
the first Volume Group from fedora_{hostname} to something like fedora_system to avoid a
too complex VG naming.