https://fedoraproject.org/wiki/Changes/FallbackHostname
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.
== Summary == This proposal is for the fallback hostname for server like variants of Fedora to use `localhost` as the fallback hostname.
== Owner == * Name: [[User:dustymabe| Dusty Mabe]] (Fedora CoreOS) * Email: dustymabe@redhat.com * Name: [[User:davdunc| David Duncan]] (Fedora Cloud) * Email: davdunc@gmail.com * Name: [[User:pwhalen| Paul Whalen]] (Fedora IoT) * Email: pwhalen@redhat.com * Name: [[User:salimma| Michel Alexandre Salim]] (Fedora Server) * Email: michel@michel-slm.name * Name: [[User:ngompa| Neal Gompa]] (Fedora Workstation/KDE) * Email: ngompa13@gmail.com
== Detailed Description ==
In Fedora 33 the default fallback hostname was changed from `localhost` to `fedora` for Fedora Linux instances that didn't get the hostname set in any other way (i.e. it's the fallback if it's not set anywhere else). This change came in a systemd update and was never proposed as a change in Fedora itself.
The enablement upstream was in https://github.com/systemd/systemd/pull/5175 and the BZ requesting the change in Fedora was https://bugzilla.redhat.com/show_bug.cgi?id=1392925. The original reasoning being that `localhost` is a bad hostname for auto-discovery protocols (think `avahi`) that are useful for more desktop applications.
Unfortunately, this caused issues because setting the hostname via reverse DNS lookups (via NetworkManager) stopped working along with breaking third party tools that set the hostname. The NetworkManager problem was subsequently fixed, but it still remains that a lot of third party software will check to see if an instance's hostname is "unset" by checking the current hostname against the string "localhost". Additionally it appears this change will never be picked up by Fedora's primary downstream in CentOS/RHEL (see https://src.fedoraproject.org/rpms/systemd/c/13d1341b108a24d13f5922054307b5c...).
The proposal here is to enable variants of Fedora Linux to configure their default/fallback hostname and to set the default for variants targetting servers (Cloud, CoreOS, IoT, Server) to `localhost`.
== Benefit to Fedora == With this change Fedora's server-like variants will become more compatible with third party tools that expect a hostname of `localhost` means the system is unconfigured. It also will mean system administrator's will see `localhost` and assume the hostname is unconfigured.
== Scope == * Proposal owners: The feature owners will update the systemd compile time switch for fallback hostname back to `localhost`. The `fedora-release` package will be updated such that the Fedora Server, IoT, Cloud, and CoreOS editions will use `localhost` as the fallback hostname. All other variants of Fedora (the ones that target desktop/laptop uses) will default to `fedora` as the fallback hostname.
The proposed changes are a relatively small amount of a work.
* Other developers: For any variants other than Cloud, CoreOS, IoT, and Server they will see no change. Work with QA to verify other editions continue to have a fallback hostname of `fedora`.
For Cloud, CoreOS, IoT, and Server the default fallback hostname would be `localhost`.
* Release engineering: No changes needed for release engineering.
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: N/A
== Upgrade/compatibility impact ==
There will be NO upgrade impact to systems where:
* An admin statically set the hostname * A hostname was provided to a system via DHCP * A hostname was found for a system via reverse DNS lookup
In the case where none of the above are true for a system (i.e. a fallback hostname will be used) the following upgrade impact will be observed:
* Fedora Cloud: No impact. A booted Fedora Cloud 36 instance has `/etc/hostname` written by `cloud-init` on first boot. * Fedora CoreOS: No impact. Already using `localhost` as fallback hostname. * Fedora IoT: Some impact. The fallback hostname will change from `fedora` to `localhost` after upgrade. * Fedora Server: Some impact. The fallback hostname will change from `fedora` to `localhost` after upgrade.
For Fedora IoT and Fedora Server we will announce the change and encourage users to statically set a hostname for their machines if they don't want the change in behavior.
== How To Test ==
Boot an instance of the flavor of Fedora you are testing in an environment where there is no DHCP hostname provided and no answer to a reverse DNS lookup for the instance IP. Run `hostnamectl hostname` and verify that it matches expectation. For Fedora Cloud, CoreOS, IoT, Server it should be `localhost`. For all others it should be `fedora`.
== User Experience == For Cloud, CoreOS, IoT and Server users will notice intances now default to `localhost` if a hostname is not provided to an instance by any other means. For all other variants of Fedora there will be no change.
== Dependencies == There will be changes to the `systemd` and `fedora-release` packages for this change.
== Contingency Plan == * Contingency mechanism: Revert the pull requests to the `systemd` and `fedora-release` packages. * Contingency deadline: Final Freeze * Blocks release? Yes
== Documentation == The fallback hostname has now changed to `localhost` for the Cloud, CoreOS, IoT, and Server variants of Fedora.
== Release Notes == The fallback hostname has now changed for the Cloud, CoreOS, IoT, and Server editions of Fedora to `localhost`. The fallback hostname is the hostname that is set if the hostname cannot be determined by any other mechanism (statically set, DHCP, or reverse DNS). This change was done in order to conform to the common expectation that a hostname of `localhost` on a system means the hostname is "unset".
On Thu, Jun 02, 2022 at 03:27:43PM -0400, Ben Cotton wrote:
https://fedoraproject.org/wiki/Changes/FallbackHostname The proposal here is to enable variants of Fedora Linux to configure their default/fallback hostname and to set the default for variants targetting servers (Cloud, CoreOS, IoT, Server) to `localhost`.
== Benefit to Fedora == With this change Fedora's server-like variants will become more compatible with third party tools that expect a hostname of `localhost` means the system is unconfigured. It also will mean system administrator's will see `localhost` and assume the hostname is unconfigured.
I'm a bit sad. This is giving in to crappy software. In particular if you do actually configure the hostname as localhost, this software will still assume that the hostname is unconfigured. But maybe it's easier to accept that than to fight it :(
Zbyszek
On Fri, Jun 10, 2022 at 3:55 PM Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:
On Thu, Jun 02, 2022 at 03:27:43PM -0400, Ben Cotton wrote:
https://fedoraproject.org/wiki/Changes/FallbackHostname The proposal here is to enable variants of Fedora Linux to configure their default/fallback hostname and to set the default for variants targetting servers (Cloud, CoreOS, IoT, Server) to `localhost`.
== Benefit to Fedora == With this change Fedora's server-like variants will become more compatible with third party tools that expect a hostname of `localhost` means the system is unconfigured. It also will mean system administrator's will see `localhost` and assume the hostname is unconfigured.
I'm a bit sad. This is giving in to crappy software. In particular if you do actually configure the hostname as localhost, this software will still assume that the hostname is unconfigured. But maybe it's easier to accept that than to fight it :(
The problem is that the hostname is never unique. If it was, then we wouldn't be in this mess.
openSUSE uses a randomly generated suffix for default hostnames, which neatly solves this problem. It makes autodiscovery and other things actually work properly. As it is, having just "fedora" breaks too much stuff. If it was "fedora-XXXXX", then we could probably keep it.
At least everything knows to ignore "localhost" properly.
-- 真実はいつも一つ!/ Always, there's only one truth!
On Fri, Jun 10, 2022 at 04:01:03PM -0400, Neal Gompa wrote:
openSUSE uses a randomly generated suffix for default hostnames, which neatly solves this problem. It makes autodiscovery and other things actually work properly. As it is, having just "fedora" breaks too much stuff. If it was "fedora-XXXXX", then we could probably keep it.
How do they implement this? I wonder if it would make sense to have systemd-hostname understand some character like # (which isn't valid in hostnames) in DEFAULT_HOSTNAME to be replaced with a random number seeded from the machine-id?
On Mon, Jun 13, 2022 at 2:10 PM Matthew Miller mattdm@fedoraproject.org wrote:
On Fri, Jun 10, 2022 at 04:01:03PM -0400, Neal Gompa wrote:
openSUSE uses a randomly generated suffix for default hostnames, which neatly solves this problem. It makes autodiscovery and other things actually work properly. As it is, having just "fedora" breaks too much stuff. If it was "fedora-XXXXX", then we could probably keep it.
How do they implement this? I wonder if it would make sense to have systemd-hostname understand some character like # (which isn't valid in hostnames) in DEFAULT_HOSTNAME to be replaced with a random number seeded from the machine-id?
YaST generates a linux-XXXX hostname when you install it. The "XXXX" string is alphanumeric.
On Mon, Jun 13, 2022 at 2:11 PM Neal Gompa ngompa13@gmail.com wrote:
On Mon, Jun 13, 2022 at 2:10 PM Matthew Miller mattdm@fedoraproject.org wrote:
On Fri, Jun 10, 2022 at 04:01:03PM -0400, Neal Gompa wrote:
openSUSE uses a randomly generated suffix for default hostnames, which neatly solves this problem. It makes autodiscovery and other things actually work properly. As it is, having just "fedora" breaks too much stuff. If it was "fedora-XXXXX", then we could probably keep it.
How do they implement this? I wonder if it would make sense to have systemd-hostname understand some character like # (which isn't valid in hostnames) in DEFAULT_HOSTNAME to be replaced with a random number seeded from the machine-id?
YaST generates a linux-XXXX hostname when you install it. The "XXXX" string is alphanumeric.
Also, yeah, I think if systemd-hostname could do something like that, we could do that instead of forcing localhost.
Am 13.06.2022 um 20:15 schrieb Neal Gompa ngompa13@gmail.com:
On Mon, Jun 13, 2022 at 2:11 PM Neal Gompa ngompa13@gmail.com wrote:
... YaST generates a linux-XXXX hostname when you install it. The "XXXX" string is alphanumeric.
Also, yeah, I think if systemd-hostname could do something like that, we could do that instead of forcing localhost.
One big argument pro change proposal was resp. is, that many tools recognise localhost as unconfigured and don’t work anymore when you change to something different.
Doesn't a change to linux-xxxx contradict the original rationale pro the change proposal?
On Mon, Jun 13, 2022 at 09:38:01PM +0200, Peter Boy wrote:
YaST generates a linux-XXXX hostname when you install it. The "XXXX" string is alphanumeric.
Also, yeah, I think if systemd-hostname could do something like that, we could do that instead of forcing localhost.
One big argument pro change proposal was resp. is, that many tools recognise localhost as unconfigured and don’t work anymore when you change to something different.
Doesn't a change to linux-xxxx contradict the original rationale pro the change proposal?
My take is: a freshly- but fully-installed Fedora Server or Fedora Workstation system _shouldn't_ be "unconfigured". It should be basically ready to go. And it's ideal of we can get to that state without asking a litany of questions.
For Fedora Server, it may be that "configure your DNS" is actually part of what's expected. But for Fedora Workstation, that's probably not reasonable — lots of laptops which move networks, etc.
Am 13.06.2022 um 22:12 schrieb Matthew Miller mattdm@fedoraproject.org:
On Mon, Jun 13, 2022 at 09:38:01PM +0200, Peter Boy wrote:
YaST generates a linux-XXXX hostname when you install it. The "XXXX" string is alphanumeric.
Also, yeah, I think if systemd-hostname could do something like that, we could do that instead of forcing localhost.
One big argument pro change proposal was resp. is, that many tools recognise localhost as unconfigured and don’t work anymore when you change to something different.
Doesn't a change to linux-xxxx contradict the original rationale pro the change proposal?
My take is: a freshly- but fully-installed Fedora Server or Fedora Workstation system _shouldn't_ be "unconfigured". It should be basically ready to go. And it's ideal of we can get to that state without asking a litany of questions.
Agreed. This has long been one of Fedora's strengths compared to other distributions.
However, the initiators of the change proposal (almost?) all come from server type variants, especially cloud. On the one hand, they want the option to configure via DHCP back again, and on the other hand, they want the option to explicitly leave the hostname „unconfigured“ = "localhost", because this triggers various post-installation tools that automatically adapt post-installation tasks to adapt the system to different runtime environments. The unconfigured hostname thus paradoxically becomes practically part of a fully configured installed system.
At least that is how I understood our discussion.
For Fedora Server, it may be that "configure your DNS" is actually part of what's expected. But for Fedora Workstation, that's probably not reasonable — lots of laptops which move networks, etc.
Yes, for desktops und specifically laptops an unkonfigured hostname is generally bad. But, the current situation having a network with dozens of Workstation all named fedora is similarly bad as all named localhost (before the switch to fedora).
So we might have to handle this differently for desktop type and server type systems.
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.
Am 14.06.2022 um 06:25 schrieb Matthew Miller mattdm@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?
On Tue, Jun 14, 2022 at 6:53 AM Peter Boy pboy@uni-bremen.de wrote:
Am 14.06.2022 um 06:25 schrieb Matthew Miller mattdm@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 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
Am 14.06.2022 um 13:13 schrieb Neal Gompa ngompa13@gmail.com:
On Tue, Jun 14, 2022 at 6:53 AM Peter Boy pboy@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.
On Tue, Jun 14, 2022 at 03:41:14PM +0200, Peter Boy wrote:
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.
Agree to all of this. Thanks for the summary!
On 6/14/22 07:13, Neal Gompa wrote:
On Tue, Jun 14, 2022 at 6:53 AM Peter Boy pboy@uni-bremen.de wrote:
Am 14.06.2022 um 06:25 schrieb Matthew Miller mattdm@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.
On Tue, Jun 14, 2022 at 12:53:19PM +0200, Peter Boy wrote:
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.
As I understand it, it's about the "hand off" between initial install and the second step, whatever that might be (cloud-init, ignition, GNOME initial setup).
On Tue, Jun 14, 2022 at 10:29 AM Matthew Miller mattdm@fedoraproject.org wrote:
On Tue, Jun 14, 2022 at 12:53:19PM +0200, Peter Boy wrote:
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.
As I understand it, it's about the "hand off" between initial install and the second step, whatever that might be (cloud-init, ignition, GNOME initial setup).
GNOME Initial Setup does not offer the ability to set your computer name. I'm not sure why given that both Windows and Mac do to ensure things work properly on a network, but it's not a thing with GNOME's initial setup wizard.
On Tue, Jun 14 2022 at 10:42:59 AM -0400, Neal Gompa ngompa13@gmail.com wrote:
GNOME Initial Setup does not offer the ability to set your computer name. I'm not sure why given that both Windows and Mac do to ensure things work properly on a network, but it's not a thing with GNOME's initial setup wizard.
I think we should add this.
However, gnome-initial-setup is a bit late because currently anaconda uses hostname to name your btrfs subvolumes. :(
anaconda would perhaps be a better place, but only if it uses hostnamed so as to allow spaces, Unicode, etc. We don't want anaconda to use stricter rules for hostnames than the installed system does.
Michael
On Tue, Jun 14, 2022 at 09:50:17AM -0500, Michael Catanzaro wrote:
However, gnome-initial-setup is a bit late because currently anaconda uses hostname to name your btrfs subvolumes. :(
Changing the subject because I've caused the thread to drift from the change proposal... :)
I don't think hostname is the best choice for volume name anyway. The initial hostname might change after install -- `fedora_dhcp-192-168-5-45-home` isn't very useful. Let alone the case where it gets named "fedora_localhost-live"!
Are there other reasons to do it that early? If not, I think maybe the solution here is to change from using the hostname to using something like mount point plus a random (first 8 of the UUID?).
On Tue, Jun 14, 2022 at 1:43 PM Matthew Miller mattdm@fedoraproject.org wrote:
On Tue, Jun 14, 2022 at 09:50:17AM -0500, Michael Catanzaro wrote:
However, gnome-initial-setup is a bit late because currently anaconda uses hostname to name your btrfs subvolumes. :(
Changing the subject because I've caused the thread to drift from the change proposal... :)
I don't think hostname is the best choice for volume name anyway. The initial hostname might change after install -- `fedora_dhcp-192-168-5-45-home` isn't very useful. Let alone the case where it gets named "fedora_localhost-live"!
Are there other reasons to do it that early? If not, I think maybe the solution here is to change from using the hostname to using something like mount point plus a random (first 8 of the UUID?).
The name should not be hard to type in a basic terminal, since we don't have a graphical rescue/recovery environment that makes fancier names not painful.
-- 真実はいつも一つ!/ Always, there's only one truth!
On Tue, Jun 14, 2022 at 4:50 PM Michael Catanzaro mcatanzaro@gnome.org wrote:
I think we should add this.
However, gnome-initial-setup is a bit late because currently anaconda uses hostname to name your btrfs subvolumes. :(
anaconda would perhaps be a better place, but only if it uses hostnamed so as to allow spaces, Unicode, etc. We don't want anaconda to use stricter rules for hostnames than the installed system does.
I think we currently hardcode all live images to have "localhost-live" hostname in the kickstart, because of some x11 bug a long time ago which failed with a plain "localhost": https://pagure.io/fedora-kickstarts/blob/main/f/fedora-live-base.ks#_207
Changing it to "fedora-NNNN" would be great.
On Wed, Jun 15, 2022 at 02:11:11PM +0200, Kamil Paral wrote:
I think we currently hardcode all live images to have "localhost-live" hostname in the kickstart, because of some x11 bug a long time ago which failed with a plain "localhost": https://pagure.io/fedora-kickstarts/blob/main/f/fedora-live-base.ks#_207
Oh, _there's_ some irony!
On Mon, Jun 13, 2022 at 04:12:49PM -0400, Matthew Miller wrote:
On Mon, Jun 13, 2022 at 09:38:01PM +0200, Peter Boy wrote:
YaST generates a linux-XXXX hostname when you install it. The "XXXX" string is alphanumeric.
Also, yeah, I think if systemd-hostname could do something like that, we could do that instead of forcing localhost.
That sounds like it would be very simple to implement.
This could be a useful feature, e.g. I'd finally be able to distuinguish all my fedora VMs without figuring out unique names for them.
One big argument pro change proposal was resp. is, that many tools recognise localhost as unconfigured and don’t work anymore when you change to something different.
Doesn't a change to linux-xxxx contradict the original rationale pro the change proposal?
And this is the hard part: the question is whether those … subpar tools that hardcode "localhost" will be happy with anything else.
(For people who are not familiar with the backstory: we now have an D-Bus API where you can query the hostname but also the origin of that configuration: static/transient/default).
My take is: a freshly- but fully-installed Fedora Server or Fedora Workstation system _shouldn't_ be "unconfigured". It should be basically ready to go. And it's ideal of we can get to that state without asking a litany of questions.
For Fedora Server, it may be that "configure your DNS" is actually part of what's expected. But for Fedora Workstation, that's probably not reasonable — lots of laptops which move networks, etc.
Zbyszek
On 6/13/22 14:15, Neal Gompa wrote:
On Mon, Jun 13, 2022 at 2:11 PM Neal Gompa ngompa13@gmail.com wrote:
On Mon, Jun 13, 2022 at 2:10 PM Matthew Miller mattdm@fedoraproject.org wrote:
On Fri, Jun 10, 2022 at 04:01:03PM -0400, Neal Gompa wrote:
openSUSE uses a randomly generated suffix for default hostnames, which neatly solves this problem. It makes autodiscovery and other things actually work properly. As it is, having just "fedora" breaks too much stuff. If it was "fedora-XXXXX", then we could probably keep it.
How do they implement this? I wonder if it would make sense to have systemd-hostname understand some character like # (which isn't valid in hostnames) in DEFAULT_HOSTNAME to be replaced with a random number seeded from the machine-id?
YaST generates a linux-XXXX hostname when you install it. The "XXXX" string is alphanumeric.
Also, yeah, I think if systemd-hostname could do something like that, we could do that instead of forcing localhost.
I agree that having a template like linux-XXXX that could be substituted in would be useful and I think we should probably do that for all variants that will stick with the existing fallback hostname today. Maybe in a followup change proposal?
I don't think that fixes all concerns that are embedded in this proposal, though.
Dusty
On Mon, Jun 13, 2022 at 02:09:35PM -0400, Matthew Miller wrote:
How do they implement this? I wonder if it would make sense to have systemd-hostname understand some character like # (which isn't valid in hostnames) in DEFAULT_HOSTNAME to be replaced with a random number seeded from the machine-id?
Zbyszek, do you think we could get something like this into upstream systemd?
We used to ask about it in the installer, and then maybe also initial setup. But in the interest of asking fewer questions, we don't anymore. I can see the argument either way.
On Thu, Jun 02, 2022 at 03:27:43PM -0400, Ben Cotton wrote:
The enablement upstream was in https://github.com/systemd/systemd/pull/5175 and the BZ requesting the change in Fedora was https://bugzilla.redhat.com/show_bug.cgi?id=1392925. The original reasoning being that `localhost` is a bad hostname for auto-discovery protocols (think `avahi`) that are useful for more desktop applications.
In retrospect, that pretty clearly should have gone through the system-wide change process. Oh well.
I'm not fond of "fedora" as the default hostname — leaving aside my "Fedora is the _project_" windmill-tilting, it's just not likely to be unique. But I think this proposal (which includes just keeping that) is reasonable enough for now.