yahoo-eng-team team mailing list archive

[James Falcon <1424710@xxxxxxxxxxxxxxxxxx>]

Tracked in Github Issues as https://github.com/canonical/cloud-
init/issues/2527

** Bug watch added: github.com/canonical/cloud-init/issues #2527
   https://github.com/canonical/cloud-init/issues/2527

** Changed in: cloud-init
       Status: Confirmed => Expired

-- 
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 cloud-init:
  Expired

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