> Am 14.06.2022 um 13:13 schrieb Neal Gompa <ngomp...@gmail.com>:
> 
> On Tue, Jun 14, 2022 at 6:53 AM Peter Boy <p...@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. 


 

_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Reply via email to