update_hostname module fails on CentOS/RHEL with systemd

[Albert Beauregard]

Cloud provider: OpenStack

#cloud-config
hostname: somehostname.somedomain
fqdn: somehostname.somedomain

 __init__.py[INFO]: /var/lib/cloud/data/previous-hostname differs from /etc/hostname, assuming user maintained hostname.

Error message is a little bit misleading, since when uses_systemd(), /etc/hostname isn't actually read, instead, the result of util.subp(['hostname']) is used.

Also, this comparison/test will never succeed, because when uses_systemd() and filename.endswitch('/previous-hostname'), the return is stripped of cr/lf, however, the result of util.subp(['hostname']) will contain a lf, and it is not being stripped:

(from rhel.py)
if self.uses_systemd() and filename.endswith('/previous-hostname'):
            return util.load_file(filename).strip()
        elif self.uses_systemd():
            (out, _err) = util.subp(['hostname'])
            if len(out):
                return out
            else:
                return default

The simplest solution appears to be to add .strip() to return out; but this fix may have other implications.

[Martin Steigerwald (ms-proact)]

I am currently preparing CentOS 7.5 Cloud Init images for my Linux trainings and am also affected by this bug. It might also be good to be able to disable this flaky auto detection, as there is already a config option `preserve_hostname` for preserving the hostname.

[Martin Steigerwald (ms-proact)]

Your work-around appears to work, thanks Albert.

[Albert Beauregard (albeauregard)]

I'm not sure how to get this reviewed by a contributor. It doesn't look like my bug report has had any action as it is still status New.

[Martin Steigerwald (ms-proact)]

The check of course also fails when using cloud-init to adapt a cloud-init image where cloud-init initially has been run:

2018-05-14 14:29:53,255 - __init__.py[INFO]: /var/lib/cloud/data/previous-hostname differs from /etc/hostname, assuming user maintained hostname.
2018-05-14 14:29:53,255 - __init__.py[INFO]: System hostname centos1.[…], previous hostname centostemplate.[…]

Interestingly enough it still renamed the host:

[root@centos1 ~]# hostname
centos1.qs.de

My stance of it: Either cloud-init manages the hostname or another tool like Puppet does it. Mixing both is a recipe for trouble, if you ask me.

[Ryan Harper (raharper)]

Thank you for filing the bug. Is this bug still affecting you?

[Albert Beauregard (albeauregard)]

It does not appear there has been any change to the source.
We continue to patch this internally in our environment.

[James Falcon (falcojr)]

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