In F33 the fallback-hostname default has been changed from 'localhost' to 'fedora' [0], possibly for branding reasons[1]. This however broke all higher level components that want to ensure that a proper dedicated hostname is set (i.e. that the machine is not using the well-known 'localhost' default). As an example, breakage has been observed in the wild by Fedora CoreOS users and reported at https://github.com/coreos/fedora-coreos-tracker/issues/649. While I do not disagree with branding goals, I'd prefer if we could revert the systemd RPM default to a well-known and IETF-reserved identifier, and instead apply the branding sugar in some better way that can be controlled at runtime (e.g. in Anaconda or via filesystem/initramfs content) later on. This ticket specifically asks about reverting the default to 'localhost', as an immediate hotfix to unbreak affected consumers. [0] https://github.com/peckato1/fedora-systemd-package/commit/6eb8bcde288dda39b163e87ee0926f6f30fcad73 [1] https://bugzilla.redhat.com/show_bug.cgi?id=1392925
> In F33 the fallback-hostname default has been changed from 'localhost' to 'fedora' [0], possibly for branding reasons[1]. Yes. Also, "localhost" is a bad name. The hostname is used to identify machines in the local network and such, and 'localhost' is useless in this role. To see whether a permanent hostname is configured, check if /etc/hostname is non-empty. The in-kernel hostname can be set from other sources too, for example from DHCP, depending on network configuration. Relying on gethostname() returning a specific string is very brittle.
> The in-kernel hostname can be set from other sources too, for example from DHCP, depending on network configuration. Unfortunately that's indeed part of the scenario that broke. If the client-hostname provided via DHCP is invalid (most common failure: longer than the kernel limit), the fallback-hostname may end up being used. Up to now, consumers were able to detect this by checking against the reserved 'localhost' identifier. Again, I'm not opposing the renaming and the underlying "pick a more useful value" goal. However, I'm arguing that the attempt here was both 1) at a too low level (systemd) and 2) too much coarse-grained (build-time setting). I guess my sweet spot here would be retaining the well-known identifier at the inner level and retargeting the renaming effort either higher up (e.g. OS installer) OR to a mechanism that can be still overridden at boot-time (e.g. a OEM factory file in initramfs).
> and instead apply the branding sugar in some better way that can be controlled at runtime (e.g. in Anaconda or via filesystem/initramfs content) later on. To elaborate/clarify that the proposal is probably to make this change Workstation specific right? I don't think server cases need this.
Bastien, comments?
(In reply to Zbigniew Jędrzejewski-Szmek from comment #4) > Bastien, comments? I don't see how "the fallback hostname" can really be applied anywhere else, because the whole point is to have a fedora hostname if one isn't set, not to overwrite the default one and thus set one. Can someone explain why the coreOS issue can't be worked around? (In reply to Colin Walters from comment #3) > > and instead apply the branding sugar in some better way that can be controlled at runtime (e.g. in Anaconda or via filesystem/initramfs content) later on. > > To elaborate/clarify that the proposal is probably to make this change > Workstation specific right? > I don't think server cases need this. This change is probably also one we'd want on everything _but_ on coreOS where that seems to be a problem. I don't think Workstation is the outlier.
> I don't see how "the fallback hostname" can really be applied anywhere else, because the whole point is to have a fedora hostname if one isn't set, not to overwrite the default one and thus set one. The specific proposal here would be that systemd would support something like `/usr/lib/systemd/fallback-hostname` - that could be part of fedora-release-workstation. > This change is probably also one we'd want on everything _but_ on coreOS where that seems to be a problem. I don't think Workstation is the outlier. Going back to your original bug: https://bugzilla.redhat.com/show_bug.cgi?id=1392925 All it says is "helps with branding recognition" but doesn't e.g. say precisely *where* that hostname is seen. For sure the default bash prompt shows it - is that your primary goal? I don't see where it's really shown in a default GNOME login outside of that and more obscure places like the sharing panel. (Oh hmm I guess it may show up in zeroconf/MDNS) But yeah this all does seem workstation/desktop specific - for the server case I don't see this being too important. Concretely I don't think Fedora Server and Fedora CoreOS (or Fedora IoT) need this.
(In reply to Colin Walters from comment #6) > > I don't see how "the fallback hostname" can really be applied anywhere else, because > the whole point is to have a fedora hostname if one isn't set, not to > overwrite the > default one and thus set one. > > The specific proposal here would be that systemd would support something like > `/usr/lib/systemd/fallback-hostname` - that could be part of > fedora-release-workstation. That's probably fine, though this wasn't specifically mentioned here before. > > This change is probably also one we'd want on everything _but_ on coreOS where that > seems to be a problem. I don't think Workstation is the outlier. > > Going back to your original bug: > https://bugzilla.redhat.com/show_bug.cgi?id=1392925 > All it says is "helps with branding recognition" but doesn't e.g. say > precisely *where* that hostname is seen. > > For sure the default bash prompt shows it - is that your primary goal? I > don't see where it's really shown in a default GNOME login outside of that > and more obscure places like the sharing panel. > (Oh hmm I guess it may show up in zeroconf/MDNS) It's the default name on the local prompt, but more importantly, it's the name that ends up being visible in remote shares of any kind, whether it's advertised through mDNS or DLNA, or visible through Bluetooth, or shown as a default ssh key name. It helps set the Fedora apart from other Linux installations. > But yeah this all does seem workstation/desktop specific - for the server > case I don't see this being too important. Concretely I don't think Fedora > Server and Fedora CoreOS (or Fedora IoT) need this. I still don't understand why the existing systemd mechanism needs to be changed, I read through the original issue and was overwhelmed by TLAs, and this bug report doesn't explain *why* it needs to be changed in systemd either, whatever the mechanism.
This also breaks DHCP-advertised hostnames [0], which is a nice feature for mobile workstations (notebooks) that often switch between different networks (home/work). [0] https://bugzilla.redhat.com/show_bug.cgi?id=1893417
I think hostnames provided by DHCP still work fine (assuming NetworkManager): ``` Nov 30 21:13:57 fedora NetworkManager[1056]: <info> [1606770837.2968] dhcp4 (ens8): option dhcp_lease_time => '86400' Nov 30 21:13:57 fedora NetworkManager[1056]: <info> [1606770837.2969] dhcp4 (ens8): option domain_name_servers => '10.0.2.3' Nov 30 21:13:57 fedora NetworkManager[1056]: <info> [1606770837.2969] dhcp4 (ens8): option expiry => '1606857237' Nov 30 21:13:57 fedora NetworkManager[1056]: <info> [1606770837.2969] dhcp4 (ens8): option host_name => 'cosa-devsh' Nov 30 21:13:57 fedora NetworkManager[1056]: <info> [1606770837.2969] dhcp4 (ens8): option ip_address => '10.0.2.15' Nov 30 21:13:57 fedora NetworkManager[1056]: <info> [1606770837.2969] dhcp4 (ens8): option next_server => '10.0.2.2' Nov 30 21:13:57 fedora NetworkManager[1056]: <info> [1606770837.2969] dhcp4 (ens8): option requested_broadcast_address => '1' Nov 30 21:13:57 fedora NetworkManager[1056]: <info> [1606770837.2969] dhcp4 (ens8): option requested_domain_name => '1' Nov 30 21:13:57 fedora NetworkManager[1056]: <info> [1606770837.2969] dhcp4 (ens8): option requested_domain_name_servers => '1' Nov 30 21:13:57 fedora NetworkManager[1056]: <info> [1606770837.2969] dhcp4 (ens8): option requested_domain_search => '1' Nov 30 21:13:57 fedora NetworkManager[1056]: <info> [1606770837.2969] dhcp4 (ens8): option requested_host_name => '1' Nov 30 21:13:57 fedora NetworkManager[1056]: <info> [1606770837.2969] dhcp4 (ens8): option requested_interface_mtu => '1' Nov 30 21:13:57 fedora NetworkManager[1056]: <info> [1606770837.2969] dhcp4 (ens8): option requested_ms_classless_static_routes => '1' Nov 30 21:13:57 fedora NetworkManager[1056]: <info> [1606770837.2969] dhcp4 (ens8): option requested_nis_domain => '1' Nov 30 21:13:57 fedora NetworkManager[1056]: <info> [1606770837.2969] dhcp4 (ens8): option requested_nis_servers => '1' Nov 30 21:13:57 fedora NetworkManager[1056]: <info> [1606770837.2969] dhcp4 (ens8): option requested_ntp_servers => '1' Nov 30 21:13:57 fedora NetworkManager[1056]: <info> [1606770837.2969] dhcp4 (ens8): option requested_rfc3442_classless_static_routes => '1' Nov 30 21:13:57 fedora NetworkManager[1056]: <info> [1606770837.2970] dhcp4 (ens8): option requested_root_path => '1' Nov 30 21:13:57 fedora NetworkManager[1056]: <info> [1606770837.2970] dhcp4 (ens8): option requested_routers => '1' Nov 30 21:13:57 fedora NetworkManager[1056]: <info> [1606770837.2970] dhcp4 (ens8): option requested_static_routes => '1' Nov 30 21:13:57 fedora NetworkManager[1056]: <info> [1606770837.2970] dhcp4 (ens8): option requested_subnet_mask => '1' Nov 30 21:13:57 fedora NetworkManager[1056]: <info> [1606770837.2970] dhcp4 (ens8): option requested_time_offset => '1' Nov 30 21:13:57 fedora NetworkManager[1056]: <info> [1606770837.2970] dhcp4 (ens8): option requested_wpad => '1' Nov 30 21:13:57 fedora NetworkManager[1056]: <info> [1606770837.2970] dhcp4 (ens8): option routers => '10.0.2.2' Nov 30 21:13:57 fedora NetworkManager[1056]: <info> [1606770837.2970] dhcp4 (ens8): option subnet_mask => '255.255.255.0' Nov 30 21:13:57 fedora NetworkManager[1056]: <info> [1606770837.2970] dhcp4 (ens8): state changed unknown -> bound Nov 30 21:13:57 fedora NetworkManager[1056]: <info> [1606770837.2978] device (ens8): state change: ip-config -> ip-check (reason 'none', sys-iface-state: 'managed') Nov 30 21:13:57 fedora NetworkManager[1056]: <info> [1606770837.2991] device (ens8): state change: ip-check -> secondaries (reason 'none', sys-iface-state: 'managed') Nov 30 21:13:57 fedora NetworkManager[1056]: <info> [1606770837.2992] device (ens8): state change: secondaries -> activated (reason 'none', sys-iface-state: 'managed') Nov 30 21:13:57 fedora NetworkManager[1056]: <info> [1606770837.2994] manager: NetworkManager state is now CONNECTED_LOCAL Nov 30 21:13:57 fedora NetworkManager[1056]: <info> [1606770837.3000] manager: NetworkManager state is now CONNECTED_SITE Nov 30 21:13:57 fedora NetworkManager[1056]: <info> [1606770837.3001] policy: set 'Wired Connection' (ens8) as default for IPv4 routing and DNS Nov 30 21:13:57 fedora NetworkManager[1056]: <info> [1606770837.3002] policy: set-hostname: set hostname to 'cosa-devsh' (from DHCPv4) Nov 30 21:13:57 fedora NetworkManager[1056]: <info> [1606770837.3004] device (ens8): Activation: successful, device activated. Nov 30 21:13:57 cosa-devsh systemd-hostnamed[1075]: Changed hostname to 'cosa-devsh' ``` I think what doesn't work now is that reverse DNS lookup to set the hostname doesn't get attempted (which apparently a lot of people rely on) because the NM code detection is based on `localhost`: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/d0df9bf0bd982ebf3dd9cf34dc240bf517012ff8/src/nm-policy.c#L832 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/d0df9bf0bd982ebf3dd9cf34dc240bf517012ff8/shared/nm-glib-aux/nm-shared-utils.c#L5560-5561 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/d0df9bf0bd982ebf3dd9cf34dc240bf517012ff8/shared/nm-glib-aux/nm-shared-utils.c#L5495-5502 If I have a Fedora 33 system that doesn't get hostname from DHCP and enable debugging logging of NM (uncomment out some debugging configuration in NetworkManager.conf), then I see: ``` Nov 30 22:02:51 fedora NetworkManager[692]: <info> [1606773771.3634] manager: NetworkManager state is now CONNECTED_SITE Nov 30 22:02:51 fedora NetworkManager[692]: <info> [1606773771.3637] policy: set 'Wired Connection' (enp1s0) as default for IPv4 routing and DNS Nov 30 22:02:51 fedora NetworkManager[692]: <debug> [1606773771.3637] manager: PrimaryConnection now Wired Connection Nov 30 22:02:51 fedora NetworkManager[692]: <trace> [1606773771.3641] policy: set-hostname: updating hostname (routing and dns) Nov 30 22:02:51 fedora NetworkManager[692]: <trace> [1606773771.3641] policy: get-hostname: "fedora" (from dbus) Nov 30 22:02:51 fedora NetworkManager[692]: <trace> [1606773771.3641] policy: get-hostname: "fedora" (from dbus) Nov 30 22:02:51 fedora NetworkManager[692]: <trace> [1606773771.3641] policy: set-hostname: hostname already set to 'fedora' (from system startup) ``` So it detects that there is a hostname (`fedora`) and it passes the `nm_utils_is_specific_hostname()` check, so reverse DNS lookup doesn't get tried. On a Fedora 32 system I see that reverse DNS does get tried: ``` Nov 30 22:09:44 localhost NetworkManager[694]: <info> [1606774184.3160] manager: NetworkManager state is now CONNECTED_SITE Nov 30 22:09:44 localhost NetworkManager[694]: <info> [1606774184.3161] policy: set 'Wired Connection' (enp1s0) as default for IPv4 routing and DNS Nov 30 22:09:44 localhost NetworkManager[694]: <debug> [1606774184.3162] manager: PrimaryConnection now Wired Connection Nov 30 22:09:44 localhost NetworkManager[694]: <trace> [1606774184.3164] policy: set-hostname: updating hostname (routing and dns) Nov 30 22:09:44 localhost NetworkManager[694]: <trace> [1606774184.3164] policy: get-hostname: "localhost" (from dbus) Nov 30 22:09:44 localhost NetworkManager[694]: <debug> [1606774184.3165] dns-mgr: (update_routing_and_dns): DNS configuration changed Nov 30 22:09:44 localhost NetworkManager[694]: <debug> [1606774184.3166] dns-mgr: (update_routing_and_dns): no DNS changes to commit (1) Nov 30 22:09:44 localhost NetworkManager[694]: <debug> [1606774184.3166] dns-mgr: (device_state_changed): DNS configuration changed Nov 30 22:09:44 localhost NetworkManager[694]: <debug> [1606774184.3167] dns-mgr: (device_state_changed): committing DNS changes (0) Nov 30 22:09:44 localhost NetworkManager[694]: <debug> [1606774184.3168] dns-mgr: update-dns: updating resolv.conf Nov 30 22:09:44 localhost NetworkManager[694]: <trace> [1606774184.3168] dns-mgr: config: 100 best v4 2 : 192.168.122.1 Nov 30 22:09:44 localhost NetworkManager[694]: <trace> [1606774184.3169] dns-mgr: plugin: add domain '~' (i=2, p=100) Nov 30 22:09:44 localhost NetworkManager[694]: <trace> [1606774184.3169] dns-sd-resolved[1cb6ff4693404492]: send-updates: no name owner. Try start service... Nov 30 22:09:44 localhost NetworkManager[694]: <trace> [1606774184.3171] dns-mgr: update-resolv-no-stub: '/run/NetworkManager/no-stub-resolv.conf' successfully written Nov 30 22:09:44 localhost dbus-broker-launch[729]: Activation request for 'org.freedesktop.resolve1' failed: The systemd unit 'dbus-org.freedesktop.resolve1.service' could not be found. Nov 30 22:09:44 localhost nm-dispatcher[758]: req:2 'connectivity-change', "/usr/lib/NetworkManager/dispatcher.d/20-chrony": complete Nov 30 22:09:44 localhost nm-dispatcher[758]: req:2 'connectivity-change', "/etc/NetworkManager/dispatcher.d/20-coreos-chrony-dhcp": run script Nov 30 22:09:44 localhost NetworkManager[694]: <trace> [1606774184.3199] dns-mgr: update-resolv-conf: write to /etc/resolv.conf succeeded (rc-manager=symlink) Nov 30 22:09:44 localhost NetworkManager[694]: <trace> [1606774184.3200] dns-mgr: update-resolv-conf: write internal file /run/NetworkManager/resolv.conf succeeded Nov 30 22:09:44 localhost NetworkManager[694]: <trace> [1606774184.3201] policy: get-hostname: "localhost" (from dbus) Nov 30 22:09:44 localhost NetworkManager[694]: <debug> [1606774184.3201] policy: restarting reverse-lookup thread for address 192.168.122.252 ``` I think right now the positives/negatives of changing the default from `localhost` to `fedora` isn't very high. Can we at least manage to switch this back and make it configurable so we can enable it for non-Workstation variants and not for others?
Looking at the code a bit more, some of this has changed since 1.26.0 of NM. Here is the link for 1.26.4: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/d256565e57af6e7f707be3f0d415eb2f225c4b78/src/nm-policy.c#L680 Notably since then there is commit https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/commit/09c8387 which reorders the comment from: ``` /* Hostname precedence order: * * 1) a configured hostname (from settings) * 2) automatic hostname from the default device's config (DHCP, VPN, etc) * 3) the last hostname set outside NM * 4) reverse-DNS of the best device's IPv4 address * */ ``` to ``` /* Hostname precedence order: * * 1) a configured hostname (from settings) * 2) automatic hostname from DHCP of eligible interfaces * 3) reverse-DNS lookup of the first address on eligible interfaces * 4) the last hostname set outside NM */ ``` So maybe newer NM can handle this appropriately.
Another example where higher level tools (outside of our control) are using `localhost` as some sort of indicator that the hostname has not been configured: https://github.com/openshift/okd/issues/394#issuecomment-737490694 In this case the vsphere-hostname.sh check against `localhost` is now inappropriate.
This change really should have been discussed as a Fedora Change proposal - this has system wide consequences, causes breakage downstream which require fedora-specific hacks as workarounds, see e.g. https://github.com/openshift/machine-config-operator/pull/2282 for OKD. I vote for reverting this change.
(In reply to Christian Glombek from comment #12) > This change really should have been discussed as a Fedora Change proposal - > this has system wide consequences, causes breakage downstream which require > fedora-specific hacks as workarounds, see e.g. > https://github.com/openshift/machine-config-operator/pull/2282 for OKD. > > I vote for reverting this change. From my perspective, even if it had been discussed on the fedora-devel list, and mentioned in the release notes, we'd still be at the same point with some regressions caused by code assuming "hostname == localhost" meaning it hasn't been set.
(The default hostname set by Fedora kernels is "(none)", not "localhost".)
"localhost" was the previous systemd fallback. I guess we're just trying to highlight the change in behavior between Fedora 32 and Fedora 33.
(In reply to Bastien Nocera from comment #13) > > From my perspective, even if it had been discussed on the fedora-devel > list, and mentioned in the release notes, we'd still be at the same point > with some regressions caused by code assuming "hostname == localhost" > meaning it hasn't been set. I'm not so sure. The fact that NetworkManager has a significant behavioral change based on the different hostname could have possibly been caught. Though, you're probably right about a lot of other software that isn't as tightly integrated with Fedora.
IIUC, any Fedora node which relied on rDNS for hostname setting will find their hostname changed to `fedora` now (though I did not test this yet). That would mean this is no longer an FCOS/OKD-specific problem. Let's discuss paths forward here: 1. change the implementation to use a file in /usr as Colin proposed above: this would allow FCOS (and ideally Server/Cloud/IoT as well) to revert back to `localhost`. 2. have systemd signal in some way that it used the fallback hostname: then NM could notice this and use DHCP or rDNS-based hostname setting only if the fallback was used. 3. have the fallback *name* live in e.g. fedora-release-common, but the fallback *logic* live in the network manager (i.e. NM and systemd-networkd): then it naturally would only be used if all other auto-config methods (DHCP/rDNS) supported by the network manager failed. 4. revert this change and keep using `localhost`: it's a well-known, reserved, identifier which is hardcoded in lots of lots of software already. (Any other proposals?) While we discuss this, could we at least temporarily revert the change while we hash out a better long-term solution?
> (Any other proposals?) 5. have systemd re-expose the value of the "fallback-hostname" in a read-only file somewhere under /usr (if hardcoded at build-time) or /run (if configurable as in option 1), so that consumers have a way to know what is the default fallback value on a specific running system. My preference would be for a mix of 1 / 4 / 5, as potentially other distros may fall into this minefield in the future too. I think we could temporarily revert this (4), lay down all the pieces in systemd for runtime introspection (5) and possibly runtime overriding (1), adapt consumers to use the introspected value, and then re-introduce the branding change (maybe in Anaconda though?) or pin the legacy value where needed.
https://src.fedoraproject.org/rpms/systemd/pull-request/42
(In reply to Bastien Nocera from comment #19) > https://src.fedoraproject.org/rpms/systemd/pull-request/42 Thanks! (In reply to Luca BRUNO from comment #18) > > (Any other proposals?) > > 5. have systemd re-expose the value of the "fallback-hostname" in a > read-only file somewhere under /usr (if hardcoded at build-time) or /run (if > configurable as in option 1), so that consumers have a way to know what is > the default fallback value on a specific running system. FWIW, I don't think this is foolproof because if the current hostname is the same as the fallback hostname, it's doesn't necessarily mean that systemd actually did the fallback since a user/other app might've actually wanted to set it to the same name as the fallback. Hence why I think if we leave the logic in systemd, we would need to define a clear API that other apps can use to know if the current hostname is set because it's a fallback, or for other reasons (this is what (2) is trying to establish).
#42 was merged. After hacking on this a bit, I propose the following simple logic: 1. hostnamed just uses the static hostname, if configured, and the transient hostname if configured, and otherwise falls back to the fallback hostname. It doesn't try to figure out if the configured hostname is "right". If it is configured and syntactically valid, it is used. https://github.com/systemd/systemd/pull/17859 2. NetworkManager tells the transient hostname to hostnamed always when it figures out a transient hostname. It doesn't try to compare the hostname with the fallback hostname. With the change in 1., the transient hostname will be used if appropriate. 2b. The same would apply to other network configuration tools. If they are configured to extract a transient hostname, they should just pass it along to hostnamed. 3. Anaconda doesn't pointlessly put "localhost.localdomain" in /etc/hostname. This way the logic in 1. can actually work. https://github.com/rhinstaller/anaconda/pull/3040 In the systemd PR I exposed various bits of information, though this is mostly for introspection and debugging. No tools need to make use of this, since the hostname setting logic is fully encapsulated in systemd. The Anaconda PR is to start discussion.
#42 was subsequently reverted in https://src.fedoraproject.org/rpms/systemd/c/0a51c274d6b8e1b36208bb682e1f5db9b50ade2f?branch=master Another thing I found is that if I try to workaround this by having a systemd unit set the transient hostname early in boot: ``` [Unit] Description=Reset the hostname to localhost [Service] Type=oneshot ProtectHome=read-only StandardInput=data StandardInputText=localhost ExecStart=tee /proc/sys/kernel/hostname RemainAfterExit=yes [Install] WantedBy=multi-user.target ``` `hostnamectl` will just lie and say the transient hostname is still `fedora`. ``` [core@localhost ~]$ hostname localhost [core@localhost ~]$ hostnamectl Static hostname: n/a Transient hostname: fedora Icon name: computer-vm Chassis: vm Machine ID: 2b2abf32403e4e61bc4990cfeeb79bff Boot ID: 6fdab30c76c54a6ebd108af68e36e1eb Virtualization: kvm Operating System: Fedora CoreOS 33.20201210.dev.4 CPE OS Name: cpe:/o:fedoraproject:fedora:33 Kernel: Linux 5.9.12-200.fc33.x86_64 Architecture: x86-64 [core@localhost ~]$ cat /proc/sys/kernel/hostname localhost ``` maybe upstream #17859 addresses this.
(In reply to Zbigniew Jędrzejewski-Szmek from comment #21) > 1. hostnamed just uses the static hostname, if configured, and the transient > hostname if configured, and otherwise falls back to the fallback hostname. Done: https://github.com/systemd/systemd/commit/d39079fcaa > 2. NetworkManager tells the transient hostname to hostnamed always when it > figures out a transient hostname. > It doesn't try to compare the hostname with the fallback hostname. With > the change in 1., the transient hostname > will be used if appropriate. > 2b. The same would apply to other network configuration tools. If they are > configured to extract a transient hostname, > they should just pass it along to hostnamed. > 3. Anaconda doesn't pointlessly put "localhost.localdomain" in > /etc/hostname. This way the logic in 1. can actually work. Done: https://github.com/rhinstaller/anaconda/pull/3044 > Hence why I think if we leave the logic in systemd, we would need to define a clear API that > other apps can use to know if the current hostname is set because it's a fallback, or for other reasons Done: https://github.com/systemd/systemd/commit/60e4fb4240 How do we proceed?
> (In reply to Zbigniew Jędrzejewski-Szmek from comment #23) > How do we proceed? Had a chat with Zbigniew about this today. He's agreed to work on making the fallback hostname configurable, possibly via a field in `/etc/os-release`. Then FCOS (and maybe Server/IoT too) could set it back to localhost (or maybe it should just be flipped around so that systemd defaults to localhost and only Workstation configures it to `fedora`). That will at least allow us to stop pinning systemd in FCOS. And then, once we fix https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/601, we should be able to revert the other hacks in FCOS as well which neuter systemd-resolved.
> Had a chat with Zbigniew about this today. He's agreed to work on making the fallback hostname configurable, possibly via a field in `/etc/os-release`. This is done now and part of systemd v248. I've verified that it fixes the issue. Thanks Zbigniew! So now here's where we are: - For FCOS, starting from f34 we can stop pinning systemd and use DEFAULT_HOSTNAME=localhost, but we still keep on neutering systemd-resolved (so that rDNS works) - For other variants, we keep on not neutering systemd-resolved, and the default hostname is still fedora The only big chunk of work left then is https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/601. At which point, we can (1) stop neutering systemd-resolved in FCOS, and (2) consider flipping things around so that the default compiled hostname is back to localhost (i.e. we revert this revert: https://src.fedoraproject.org/rpms/systemd/c/0a51c274d6b8e1b36208bb682e1f5db9b50ade2f?branch=master), and only on Workstation do we override it via DEFAULT_HOSTNAME=fedora. Thoughts on the above?
Sounds reasonable, except this part: > (2) consider flipping things around so that the default compiled hostname is back to localhost (i.e. we revert this revert: https://src.fedoraproject.org/rpms/systemd/c/0a51c274d6b8e1b36208bb682e1f5db9b50ade2f?branch=master), and only on Workstation do we override it via DEFAULT_HOSTNAME=fedora. The new hostname is there to stay and there is no plan to revert it. It's fine to temporarily make it different in fcos for compatibility reasons, but other Fedora editions have no reason to go back. Stepping back a bit, the name became a problem because a a specific value of a user-configurable string was hardcoded and various pieces of software were doing literal comparisons and determining system and network configuration behaviour from this. This was an accident of implementation that was copied over into other places without any plan. There is no reason to keep doing this forever. I think fcos should make a plan how to transition to the new name (without harcoding a specific value obviously, in case we want to switch the distro default yet again, or make it randomized, or whatever). Apart from any name being better than "localhost", keeping "localhost" means diverging from othe variants for no good reason. Each such diversion is a grain on the sand pile of technical debt.
This message is a reminder that Fedora 33 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 33 on 2021-11-30. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '33'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 33 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 33 changed to end-of-life (EOL) status on 2021-11-30. Fedora 33 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.