Salt: network.system not setting hostname in hosts file, preventing sudo.

[nixjdm]

Description of Issue/Question

I'm currently using https://docs.saltstack.com/en/latest/ref/states/all/salt.states.network.html to set the hostname of my instance with

system:
  network.system:
    - enabled: True # only neccessary as a bypass for https://github.com/saltstack/salt/issues/6922
    - hostname: 'sample-hostname'
    - apply_hostname: True
    - retain_settings: True

This does modify my /etc/hostname correctly, but it does not set the hostname in /etc/hosts, instead, there it is the same as before the salt state was ran, so now there's a mismatch. Granted, I'm aware that https://docs.saltstack.com/en/latest/ref/states/all/salt.states.host.html exists, which allows for further modifications of /etc/hosts, but I assumed the network state call would completely set my hostname, across the whole system. Is it not supposed to? For me with the hostname mismatch, I couldn't use sudo. See https://askubuntu.com/questions/59458/error-message-when-i-run-sudo-unable-to-resolve-host-none as to why sudo stops working in this case. I'm sure many other things would break too.

I'm unclear. I want to call this a bug, because I don't know why you'd want to change the hostname in only one place. I would have expected it to wipe out all remnants of the previous hostname. Perhaps it is meant to be this way though, in which case a documentation change should really happen to explain more precisely what this state is supposed to do.

Setup

Debian 8 with

system:
  network.system:
    - enabled: True # only necessary as a bypass for https://github.com/saltstack/salt/issues/6922
    - hostname: 'sample-hostname'
    - apply_hostname: True
    - retain_settings: True

Steps to Reproduce Issue

Provision an Debian 8 instance with the above state.

Versions Report

Salt: 2017.7.0

[garethgreenaway]

At the moment on Debian & Ubuntu based systems it doesn't update /etc/hosts. Originally network.system only supported Red Hat based systems, which set the hostname, etc. in specific files. Debian based systems don't have this so we simply set it in /etc/hostname. Based on this, we should also try to update any hosts in /etc/hosts as well.

[nixjdm]

I also just discovered that the minion_id (residing at /etc/salt/minion_id) is not changed either. It is the previous hostname. Can we add that to the list? Another ticket?

[mattLLVW]

There is already a function to change the host in salt.modules.network.py(mod_hostname).

The problem is during the build_network_settings function in salt.modules.debian_ip.py(which is called by network.system), the new hostname is written in /etc/hostname.

Then apply_network_settings from salt.modules.debian_ip.py is called, which effectively use mod_hostname, but when it try to fetch the 'old hostname' using hostnamectl status it trigger a d-bus activated systemd hostname service, changing the Static hostname to the new one(because there was a change in /etc/hostname) thus preventing the change in /etc/hosts.

There is already a TODO in salt.modules.debian_ip.py to change _write_file_network(hostname, _DEB_HOSTNAME_FILE) by a call to network.mod_hostname, but i don't think it should be build_network_settings that should call it.
If it's called here, then it's called twice, once in build_network_settings and once in apply_network_settings.

By just removing the block with _write_file_network(hostname, _DEB_HOSTNAME_FILE) , it works as expected.