GNOME Bugzilla – Bug 699458
dns: keyfile settings plugin should support /etc/hostname
Last modified: 2015-07-07 15:14:29 UTC
The keyfile settings plugin currently only supports using NetworkManager.conf for the hostname setting. However, at least systemd-using systems provide /etc/hostname as well as the DBus service org.freedesktop.hostname1. I think the keyfile plugin should be using these if available. Otherwise you just end up having yet another location specifying the system hostname, which has to be kept in sync manually.
This is similar in nature to downstream Fedora bug: https://bugzilla.redhat.com/show_bug.cgi?id=831735 The fedora one was closed with the following commit: commit a7eb3476557dae28880333544c797705ee2f5b5a Author: Dan Winship <danw@gnome.org> Date: Tue Jun 19 10:07:17 2012 -0400 ifcfg-rh: /etc/hostname should override /etc/sysconfig/network When determining the system hostname, /etc/hostname should override /etc/sysconfig/network, so monitor both files. When setting the hostname, set it in /etc/hostname, and delete the /etc/sysconfig/network HOSTNAME entry if present. https://bugzilla.redhat.com/show_bug.cgi?id=831735 As heftig says, /etc/hostname is used on systemd systems. It is also used in Debian-based distributions and probably also other distributions. I believe that the handling should be shared among configuration plugins.
we should probably read /etc/hostname from NM core, and only get the hostname from the settings plugins as fallback
Is that targeted for 0.9.10, then?
Please comment on the first version of this feature. http://cgit.freedesktop.org/NetworkManager/NetworkManager/log/?h=th/bgo532815_hostname Thank you!
Dan suggested making /etc/hostname the first option and the settings plugin the fallback. You implemented the inverse.
That is (In reply to comment #5) That is true, I implemented it in reverse, because that's how I understood it should work, that the NM core provides a fallback. Otherwise, NM always short-cuts the plugins (if /etc/hostname exists). What the patch does not, is setting the hostname. I think it needs some more discussion, how and who should write the hostname. For example, now ifcfg-rh writes /etc/hostname and clears the name from the sysconfig. If NM would write the hostname first, ifcfg-rh would only have clear the sysconfig -- which seems counter intuitive, that when you set the hostname property of the plugin, it gets cleared instead. Please ignore the patch above, this needs some more thinking :)
(In reply to comment #6) > That is (In reply to comment #5) > > That is true, I implemented it in reverse, because that's how I understood it > should work, that the NM core provides a fallback. Otherwise, NM always > short-cuts the plugins (if /etc/hostname exists). > > What the patch does not, is setting the hostname. I think it needs some more > discussion, how and who should write the hostname. First of all, you should never write to /etc/hostname unless explicitly requested by the administrator (e.g. by directly editing /etc/hostname). > For example, now ifcfg-rh writes /etc/hostname and clears the name from the sysconfig. Yep, that's an exception with ifcfg-rh because Fedora and derivatives explicitly want to *migrate* from sysconfig to /etc/hostname (none of them specific to NetworkManager). Such actions are normally done by migration scripts but (probably for simplicity) it's performed by the plugin itself. With 'keyfile', the hostname is in the NetworkManager.conf itself (or now in '/etc/hostname'). You could: a) Implement a similar migration path. b) Prefer /etc/hostname and issue a deprecation warning for keyfile.hostname. c) Prefer keyfile.hostname. I personally would prefer #b (or #a which I regard a bit unnecessary). > If NM would write the hostname first, You cannot write the permanent hostname to /etc/hostname without reading it from sysconfig, otherwise you are writing bogus information there. Please keep in might that it's really just a migration tool, not configuration logic.
(In reply to comment #7) > First of all, you should never write to /etc/hostname unless explicitly > requested by the administrator (e.g. by directly editing /etc/hostname). You mean: NetworkManager should never ever write /etc/hostname, that should only be done manually by the administrator? As of now, ifcfg-rh actually writes this file every time from pk_hostname_cb in nm-settings.c > With 'keyfile', the hostname is in the NetworkManager.conf itself (or now in > '/etc/hostname'). You could: > > a) Implement a similar migration path. > > b) Prefer /etc/hostname and issue a deprecation warning for keyfile.hostname. > > c) Prefer keyfile.hostname. > > I personally would prefer #b (or #a which I regard a bit unnecessary). > > > If NM would write the hostname first, The 'keyfile' plugin gets loaded automatically anyway. From that point of view, it does not really make a difference, whether NM-core writes/reads the hostname or the 'keyfile' plugin. Except you care about the deprecation warning (which is also not raised from ifcfg-rh). - I think the confusing part of it is, that *all* plugins with CAP_MODIFY_HOSTNAME get to write the hostname. I don't see, why that is even necessary and how to meaningful consolidate two plugins that both want to write the same file. So, what about two plugins that both want to write to /etc/hostname? Should the code from ifcfg-rh code move to keyfile/NM-core? If so, should setting the HOSTNAME for ifcfg-rh only clear the sysconfig and nothing else? - What about systems, that do not want to use /etc/hostname? > You cannot write the permanent hostname to /etc/hostname without reading it > from sysconfig, otherwise you are writing bogus information there. Please keep > in might that it's really just a migration tool, not configuration logic. If you want to only use it for migration, then ifcfg-rh should - try to read /etc/hostname - if that fails, read sysconfig (and on success, immediately write it to /etc/hostname). Anyway, right now, ifcfg-rh writes the file whenever called from pk_hostname_cb. It would not change at all, whether bogus values will written or not.
I've made my own attempt at this bug: https://github.com/heftig/NetworkManager/commits/bgo699458_hostname Comments, please?
just very quickly skimming; there's no need for the configuring-what-hostname-file-to-use patch. Everyone should be using /etc/hostname these days, and if not, then the distro-specific plugin can have its own overrides.
I the meantime, handling the persistent hostname moved from the settings plugins out to NMSettings. It is thus independent from the settings plugin, but dependent on either compile-time and runtime configuration. Most implementations now read the hostname from /etc/hostname. But also support for systemd-hostnamed was added -- which will be preferred if present. The NetworkManager.conf entry keyfile.hostname is no longer supported. Specifying it in the configuration will cause a warning in the logfile. The relevant merge is: http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=135999c2ec567683b6d71cc328584a2126167144 This patch is currently on master, but not backported to any stable branches (yet). For the moment, there are no plans to do so. Closing this bug as fixed. If there are needs for backporting, please comment/reopen.