Description of problem: 1. type a network hostname ending with a period (example: fedora.keithb-pc.int.ftdna.com.) 2. attempt to set that hostname by clicking "Apply" 3. watch Anaconda die Version-Release number of selected component: anaconda-29.24.7 The following was filed automatically by anaconda: anaconda 29.24.7 exception report Traceback (most recent call first): File "/usr/lib/python3.7/site-packages/pydbus/proxy_method.py", line 102, in __call__ raise error File "/usr/lib64/python3.7/site-packages/pyanaconda/network.py", line 1293, in set_hostname network_proxy.SetCurrentHostname(hn) File "/usr/lib64/python3.7/site-packages/pyanaconda/ui/gui/spokes/network.py", line 1645, in on_apply_hostname network.set_hostname(hostname) pyanaconda.modules.common.errors.DBusError: g-dbus-error-quark: GDBus.Error:org.freedesktop.DBus.Error.InvalidArgs: Invalid hostname 'fedora.keithb-pc.int.ftdna.com.' (16) Additional info: addons: com_redhat_kdump, com_redhat_docker blivet-gui-utils.log: cmdline: /usr/bin/python3 /sbin/anaconda cmdline_file: BOOT_IMAGE=vmlinuz initrd=initrd.img inst.stage2=hd:LABEL=Fedora-WS-dvd-x86_64-29 rd.live.check quiet executable: /sbin/anaconda hashmarkername: anaconda kernel: 4.18.16-300.fc29.x86_64 product: Fedora release: Cannot get release name. type: anaconda version: 29
Created attachment 1503442 [details] File: anaconda-tb
Created attachment 1503443 [details] File: anaconda.log
Created attachment 1503444 [details] File: dbus.log
Created attachment 1503445 [details] File: dnf.librepo.log
Created attachment 1503446 [details] File: environ
Created attachment 1503447 [details] File: hawkey.log
Created attachment 1503448 [details] File: lorax-packages.log
Created attachment 1503449 [details] File: lsblk_output
Created attachment 1503450 [details] File: lvm.log
Created attachment 1503451 [details] File: nmcli_dev_list
Created attachment 1503452 [details] File: os_info
Created attachment 1503453 [details] File: program.log
Created attachment 1503454 [details] File: storage.log
Created attachment 1503455 [details] File: syslog
Created attachment 1503456 [details] File: ifcfg.log
Created attachment 1503457 [details] File: packaging.log
Thank you for the report! This is rather convoluted. Anaconda itself validates the hostname such that it allows the trailing dot. Anaconda then both directly writes /etc/hostname *and* changes the hostname immediately by calling systemd via D-Bus [0]. The systemd call rejects the trailing dot as invalid and the crash happens. So, to reproduce only the crash root cause: $ sudo gdbus call --system --dest org.freedesktop.hostname1 --object-path /org/freedesktop/hostname1 --method org.freedesktop.hostname1.SetHostname "blah.blah" false && hostnamectl (...) Static hostname: <your normal hostname> Transient hostname: blah.blah (...) $ sudo gdbus call --system --dest org.freedesktop.hostname1 --object-path /org/freedesktop/hostname1 --method org.freedesktop.hostname1.SetHostname "blah.blah." false Error: GDBus.Error:org.freedesktop.DBus.Error.InvalidArgs: Invalid hostname 'blah.blah.' (hostnamectl would show the same as before) On the systemd side, this is a conscious choice [1,2]. Systemd does allow entering FQDNs with trailing dots into hostnamectl, but the dots are silently eaten before usage in the lower layers - see [3-5] for the actual implementation and [6,7] for some context how the world got there :) [0] https://www.freedesktop.org/wiki/Software/systemd/hostnamed/ [1] https://github.com/systemd/systemd/issues/6369#issuecomment-315684435 [2] https://github.com/systemd/systemd/pull/730#issuecomment-125159395 [3] https://github.com/systemd/systemd/blob/master/src/hostname/hostnamectl.c#L237 [4] https://github.com/systemd/systemd/blob/master/src/basic/hostname-util.c#L90 [5] https://github.com/systemd/systemd/blob/master/src/basic/hostname-util.c#L140 [6] https://bugzilla.redhat.com/show_bug.cgi?id=1238246 [7] https://github.com/systemd/systemd/pull/751
Writing something with a trailing dot into /etc/hostname gives me no trailing dot in hostname, hostnamectl, uname -a, sysctl kernel.hostname,... you get the picture. Hostnamectl mangles the trailing dot and errors with --static and the dot. That means it will never write the dot into the actual file. So I think there are only two realistic choices going forward: 1) Anaconda stops accepting the trailing dot = instant fix, one-liner, breaks compatibility. 2) Anaconda accepts the trailing dot and then drops it. I will look at other GNOME and Fedora things that must face the same problem.
Some more data: - GNOME Control Center (Settings-About-Details aka info-overview-panel) takes the user input as pretty name and mangles it to get a real hostname. [8] - The pre-systemd system I could try (RHEL 6) does not consider the trailing period even if put into /etc/sysconfig/network. - A systemd person told me "hostname is not domain name". (sic) [8] https://gitlab.gnome.org/GNOME/gnome-control-center/blob/master/panels/common/hostname-helper.c#L103
One more data point - Cockpit actually exposes both the pretty and "real" hostname 1:1 as systemd has them.
Pull request that forbids the dot: https://github.com/rhinstaller/anaconda/pull/2200
It seems that historically, Anaconda actually always allowed the dot as input, and propagated it to the resulting system, but the immediate setting of hostname in installation environment is where changes happened: The dot stopped being used with change hostname->hostnamectl, and is now an error after change hostnamectl->systemd dbus. Here's some compatibility comparison for RHEL: - RHEL6: Anaconda sets hostname by calling hostname, which writes /etc/sysconfig/network; then copies the config files to the newly installed system. Note also I had mixed results trying various RHEL6 installations that all claimed to be 6.10 - while previously I saw the dot being ignored, on another system it showed just fine. - RHEL7: Anaconda sets hostname by calling hostnamectl, which silently eats the dot; then writes /etc/hostname on new system. Also writes dummy text to /etc/sysconfig/network but that is irrelevant. - RHEL8: Same as RHEL7. - RAWHIDE: Anaconda sets hostname by calling systemd directly over d-bus, which crashes on the dot; then writes /etc/hostname on new system.
This message is a reminder that Fedora 29 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 29 on 2019-11-26. 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 '29'. 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 29 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.
Switching to rawhide as that's where I validated it.
According to someone better versed in DNS than me, a FQDN in hostname is a not so good idea, and a trailing dot even worse, so likely not to be encountered. That seems in agreement with the rest, aka no dots in hostname. Pull request needs further changes because anaconda validates with a single test not just hostnames but also server addresses, where the dot *is* valid.
Pull request merged. https://github.com/rhinstaller/anaconda/pull/2200
Hi @Vladimir, Thank you for working to get this issue fixed. I write software. I particularly like `gethostname()` returning the FQDN of the machine running the process. I've used FQDN hostnames without a trailing dot for a long time on a variety of operating systems and haven't noticed any issues with them (other than this crash bug). I only noticed this crash when I typoed a FQDN and left off the TLD of the FQDN. Can you, or the someone better versed in DNS, point to why a FQDN in hostname is not a good idea? I'd specifically like to read an RFC on the matter. I understand that Fedora 31 has already been launched. Am I correct to understand that the merged fix should be available in Fedora 32's installer? Thanks, Keith
Hi Keith, > Can you, or the someone better versed in DNS, point to why a FQDN in hostname is not a good idea? I'd specifically like to read an RFC on the matter. Sorry, I am not able to help you in this well enough. What I did was I asked a colleague who internally repackages bind for RHEL, and his opinion had a lot of "probably" to it, too. Here's a rather loose recap of my notes, in case it helps: >> You can set hostname with fqdn, but it brings unexpected consequences. If you set hostname with a fqdn value "foo.redhat.com", the domain is used as if resolv.conf contained domain "redhat.com" . So if you then try to search for name "bar", "bar.redhat.com" is tried automatically first, and plain "bar" only afterwards. No idea what the dot changes, would have to test that. Known only what that does when used as a search query, but not as a hostname. Actually a trailing dot/period could make sense only when asking for a name (?). There doesn't seem to be a good reason to use it when setting your own name. In the end, the theory would only further justify the decision, as there isn't a way to set and announce a system's hostname with a trailing dot on contemporary Linux = kernel + systemd. > I understand that Fedora 31 has already been launched. Am I correct to understand that the merged fix should be available in Fedora 32's installer? Yes, exactly.
This bug appears to have been reported against 'rawhide' during the Fedora 32 development cycle. Changing version to 32.
Released with F32.