Public bug reported: On CentOS 7 (systemd based), with cloud-init 0.7.5, cc_update_hostname will *always* overwrite the hostname, even if it shouldn't.
This is pretty easy to reproduce: 1) Add a 'hostname: metadata.example.com' to your user-data 2) Run 'hostnamectl set-hostname test.example.com' 3) Reboot the server 4) Check the hostname, it'll still be 'metadata.example.com' 5) Repeat 2-4, hostname will still be set Looking at the code, this is because rhel.py doesn't populate the previous-hostname file correctly: def _write_hostname(self, hostname, out_fn): if self._dist_uses_systemd(): util.subp(['hostnamectl', 'set-hostname', str(hostname)]) else: host_cfg = { 'HOSTNAME': hostname, } rhel_util.update_sysconfig_file(out_fn, host_cfg) So, Distros::update_hostname calls _write_hostname to try and save the previous hostname to /var/lib/cloud/data/previous-hostname .. however, all this does is run the hostnamectl command, which doesn't actually update this file. This means that on the next cloud-init run, /var/lib/cloud/data/previous-hostname doesn't exist so the hostname gets blindly updated again. The fix here seems pretty simple, we just need to update previous- hostname as well when running hostnamectl. I attached a patch that does this, though I don't know the best way to implement this.. my patch fails if cloud-init's data path is changed ** Affects: cloud-init Importance: Undecided Status: New ** Patch added: "centos-7-hostname.patch" https://bugs.launchpad.net/bugs/1424710/+attachment/4325548/+files/centos-7-hostname.patch -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1424710 Title: CentOS 7: update-hostname always overwrites hostname Status in Init scripts for use on cloud images: New Bug description: On CentOS 7 (systemd based), with cloud-init 0.7.5, cc_update_hostname will *always* overwrite the hostname, even if it shouldn't. This is pretty easy to reproduce: 1) Add a 'hostname: metadata.example.com' to your user-data 2) Run 'hostnamectl set-hostname test.example.com' 3) Reboot the server 4) Check the hostname, it'll still be 'metadata.example.com' 5) Repeat 2-4, hostname will still be set Looking at the code, this is because rhel.py doesn't populate the previous-hostname file correctly: def _write_hostname(self, hostname, out_fn): if self._dist_uses_systemd(): util.subp(['hostnamectl', 'set-hostname', str(hostname)]) else: host_cfg = { 'HOSTNAME': hostname, } rhel_util.update_sysconfig_file(out_fn, host_cfg) So, Distros::update_hostname calls _write_hostname to try and save the previous hostname to /var/lib/cloud/data/previous-hostname .. however, all this does is run the hostnamectl command, which doesn't actually update this file. This means that on the next cloud-init run, /var/lib/cloud/data/previous-hostname doesn't exist so the hostname gets blindly updated again. The fix here seems pretty simple, we just need to update previous- hostname as well when running hostnamectl. I attached a patch that does this, though I don't know the best way to implement this.. my patch fails if cloud-init's data path is changed To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1424710/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp