Description of problem: When setting the hostname using FQDN including the trailing dot (for root zone), which can be omitted as stated in RFC 1034 section 3.1, the command set-hostname interprets the hostname differently compared to when the trailing dot is omitted. The both names should be equivalent. Version-Release number of selected component (if applicable): systemd-219-18.fc22.x86_64 How reproducible: always Steps to Reproduce: root@unused-4-137 ~ # hostnamectl set-hostname test.example.com root@unused-4-137 ~ # hostnamectl Static hostname: test.example.com Icon name: computer-laptop Chassis: laptop Machine ID: 7cf0abb27a534e3f957ff44f9277154a Boot ID: e9be9ca9b8a64fb88c970f0660271323 Operating System: Fedora 22 (Twenty Two) CPE OS Name: cpe:/o:fedoraproject:fedora:22 Kernel: Linux 4.0.6-300.fc22.x86_64 Architecture: x86-64 root@unused-4-137 ~ # hostnamectl set-hostname test.example.com. root@unused-4-137 ~ # hostnamectl Static hostname: test.example.com Pretty hostname: test.example.com. Icon name: computer-laptop Chassis: laptop Machine ID: 7cf0abb27a534e3f957ff44f9277154a Boot ID: e9be9ca9b8a64fb88c970f0660271323 Operating System: Fedora 22 (Twenty Two) CPE OS Name: cpe:/o:fedoraproject:fedora:22 Kernel: Linux 4.0.6-300.fc22.x86_64 Architecture: x86-64 Actual results: The interpretation of FQDN is different Expected results: The interpretation of FQDN should be the same Additional info:
Aren't servers actual hostnames always supposed to be relative domain only so the trailing dot for fqdn in static hostnames is always omitted? That said the pretty hostname is just a free-form UTF8 host name for presentation to the user. T There is no correlation with that name and the static hostname ( FQDN ) and pretty hostname is not bound to any RFC so those names ( static and pretty ) aren't equivalent and can ( and usually are ) completely different. You can set the pretty hostname to Tomas laptop, ice cream, beer or whatever and that name will pop up for example in the device name section, in the details section in Gnome.
(In reply to Jóhann B. Guðmundsson from comment #1) > Aren't servers actual hostnames always supposed to be relative domain only > so the trailing dot for fqdn in static hostnames is always omitted? Based on what? Is there some standard? I would expect hostnamectl to omit the trailing dot if it is there and treat the hostname as if there was no dot. This is how any DNS related software works. > That said the pretty hostname is just a free-form UTF8 host name for > presentation to the user. T I'm not really interested in the pretty name as such. Also I read the hostnamectl man page before creating this bug. > There is no correlation with that name and the static hostname ( FQDN ) and > pretty hostname is not bound to any RFC so those names ( static and pretty ) > aren't equivalent and can ( and usually are ) completely different. There is an obvious difference in the interpretation. I didn't said that pretty names are bound to RFC. Only that the dot at the end can be omitted, so the hostnames are technically equivalent. > You can set the pretty hostname to Tomas laptop, ice cream, beer or whatever > and that name will pop up for example in the device name section, in the > details section in Gnome. I don't have such need.
https://github.com/systemd/systemd/pull/730
(In reply to Zbigniew Jędrzejewski-Szmek from comment #3) > https://github.com/systemd/systemd/pull/730 Thank you.
I am sorry, but I really disagree with this issue. The behaviour might be surprising, but correct. Sounds more like a documentation issue, rather than anything to "fix". For a longer explanation see: https://github.com/systemd/systemd/pull/730#issuecomment-125159395
After some discussion, "Foobar.org." is now accepted. "Foobar." is not. https://github.com/systemd/systemd/commit/73974f6768ef5314a572eb93f5cfc7f0f29c9549 I guess we'll want this backported.
Thank you for all your effort. I checked the final behavior description and it makes sense. From my point of view as reporter, the issue is really not critical, so the backport is up to you. ;)
Right, the work-around is easy enough :)