[SRU] Hostname change is not preserved across reboot on Azure Ubuntu VMs

[Joe Clifford]

SRU Justification

[IMPACT] Cloud-init overrides the hostname each boot with the fabric provided name. Users expect that the hostname will not be reset each boot.

[Test Case 1] Upgrade from proposed
1. Install cloud-init from proposed
2. Change the hostname via /etc/hostname
3. Reboot
4. Confirm that the new hostname is used

[Test Case 2] Reprovision
(Follow Test Case 1)
1. Capture Azure VM
2. Start captured VM
3. Confirm that the new fabric name is used

[Test Case 3] New Image Launch
1. Build an Azure image from -proposed
2. Boot and confirm that hostname is set properly
3. Follow test case 1
4. Follow test case 2

[Regression Potential] As this is a backport of the 15.10 Datasource, there is a medium regression potential. The 15.10 Datasource fixes a number of Azure provisioning bugs and is thus desirable.

[ORIGINAL REPORT]

Whilst a hostname change is immediately effective using the hostname or hostnamectl commands, and changing the hostname this way is propagated to the hostname field in the Azure dashboard, upon rebooting the Ubuntu VM the hostname reverts to the Virtual Machine name as displayed in the Azure dashboard.

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: walinuxagent 2.0.8-0ubuntu1~14.04.0
ProcVersionSignature: Ubuntu 3.13.0-36.63-generic 3.13.11.6
Uname: Linux 3.13.0-36-generic x86_64
ApportVersion: 2.14.1-0ubuntu3.4
Architecture: amd64
Date: Mon Sep 29 12:48:56 2014
ProcEnviron:
 TERM=xterm
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=en_GB.UTF-8
 SHELL=/bin/bash
SourcePackage: walinuxagent
UpgradeStatus: No upgrade log present (probably fresh install)
mtime.conffile..etc.waagent.conf: 2014-09-29T09:37:10.758660

[Joe Clifford (joeclifford)]

private information obfuscated

[Joe Clifford (joeclifford)]

private information obfuscated

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Yue Zhang (yuezha)]

Cloud-init will reset hostname on every reboot. The hostname is stored in /var/lib/waagent/ovf-env.xml.

You could use the following command to change your hostname.
 sudo sed -e "s/your-old-hostname/your-new-hostname/" -i /var/lib/waagent/ovf-env.xml

[Ben Howard (darkmuggle)]

Pending merge proposal.

Cloud-init's default behavior was to set the hostname via the system hostname each boot and then bounce the interface. In taking a look at this, the dhcp configuration was using "gethostname()" in order to determine what name to send to the fabric. By having cloud-init set the hostname in the dchpclient configuration, this can be fixed. My patch brings cloud-init's hostname handling more inline with other datasources.

[Dan Watkins (daniel-thewatkins)]

This turned out to be something of an involved change, which I'm still working on.

Essentially, the cloud-init Azure data source will _always_ set the hostname to that provided by the fabric, even before the configuration modules that would normally do it (i.e. set_hostname and update_hostname). It does this so that the virtual IP address will be assigned correctly (by renewing the DHCP lease), but does this on every boot.

It has to set the hostname and bounce DHCP on every boot, because we can't know if this is the first boot of an instance until we have got our instance ID from SharedConfig.xml. We can't get SharedConfig.xml without network. We can't have network (on first boot) until we have performed the bounce[0]. Very Ouroborian.

My change sounds simple: after we have performed the DHCP bounce and walinuxagent has fetched SharedConfig.xml, we will set the hostname back to what it was before, to allow the regular cloud-init modules to perform hostname changing.

Unfortunately, this has lead to fairly major restructuring of the code in question, so this won't make it in to vivid's cloud-init (as we are releasing in just over a week). But we are making good progress!

[0] We also can't try to get SharedConfig.xml and then do the bounce if we fail, because this will add about a minute on to first boot times.

[Launchpad Janitor (janitor)]

This bug was fixed in the package cloud-init - 0.7.7~bzr1106-0ubuntu1

---------------
cloud-init (0.7.7~bzr1106-0ubuntu1) wily; urgency=medium

  * New upstream snapshot.
    * Azure: remove strict dependency on walinux-agent, but still utilize
      it for the time being.
    * fix read_seeded that is used in seeding user-data and meta-data
      from additional locations (LP: #1455233)
    * fix bug preventing partitioning of disks in many cases. (LP: #1311463)
    * Azure: do not override hostname if user has set it (LP: #1375252)
    * Fix GCE datasource not handling per-instance SSH keys (LP: #1403617)
    * Allow specifying of uid in user/group config.

 -- Scott Moser <email address hidden> Fri, 15 May 2015 17:04:19 -0400

[Brian Murray (brian-murray)]

Hello Joe, or anyone else affected,

Accepted cloud-init into vivid-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/cloud-init/0.7.7~bzr1091-0ubuntu2 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[Brian Murray (brian-murray)]

Hello Joe, or anyone else affected,

Accepted cloud-init into utopic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/cloud-init/0.7.6~bzr1022-0ubuntu4 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[Brian Murray (brian-murray)]

Hello Joe, or anyone else affected,

Accepted cloud-init into trusty-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/cloud-init/0.7.5-0ubuntu1.6 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[Ben Howard (darkmuggle)]

Verified -proposed package. Marking as verification-done.

[Launchpad Janitor (janitor)]

This bug was fixed in the package cloud-init - 0.7.5-0ubuntu1.6

---------------
cloud-init (0.7.5-0ubuntu1.6) trusty; urgency=medium

  * d/patches/lp-1375252-1458052-Azure-hostname_password.patch:
    Backport of 15.10 Azure Datasource to fix various issues:
    - Azure Datasource writes user password in plain text (LP: #1458052).
    - Hostname not preserved across Azure reboots (LP: #1375252).

 -- Ben Howard <email address hidden> Mon, 25 May 2015 09:30:20 -0600

[Adam Conrad (adconrad)]

The verification of the Stable Release Update for cloud-init has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

[Launchpad Janitor (janitor)]

This bug was fixed in the package cloud-init - 0.7.6~bzr1022-0ubuntu4

---------------
cloud-init (0.7.6~bzr1022-0ubuntu4) utopic; urgency=medium

  * d/patches/lp-1375252-1458052-Azure-hostname_password.patch:
    Backport of 15.10 Azure Datasource to fix various issues:
    - Azure Datasource writes user password in plain text (LP: #1458052).
    - Hostname not preserved across Azure reboots (LP: #1375252).

 -- Ben Howard <email address hidden> Mon, 25 May 2015 08:53:25 -0600

[Launchpad Janitor (janitor)]

This bug was fixed in the package cloud-init - 0.7.7~bzr1091-0ubuntu2

---------------
cloud-init (0.7.7~bzr1091-0ubuntu2) vivid; urgency=medium

  * Backport of 15.10 Azure Datasource to fix various issues:
    - Azure Datasource writes user password in plain text (LP: #1458052).
    - Hostname not preserved across Azure reboots (LP: #1375252).
    - Allow provisioning of Ubuntu Snappy w/out WALinuxAgent (LP: #1448885).

 -- Ben Howard <email address hidden> Mon, 25 May 2015 09:38:58 -0600

[Joe Clifford (joeclifford)]

Apologies for the tardy feedback. Many thanks to all involved, gratefully and much appreciated. From my perspective, this issue is now resolved.

I've just tried this on a freshly deployed Trusty VM in Azure - a change to the hostname with 'hostnamectl' is now preserved when the VM is rebooted.

I would like to point out though that, if not editing the /etc/hostname file directly, the 'hostnamectl' command must be used to set the hostname; using the 'hostname' command doesn't work (presumably because the hostname command doesn't change /etc/hostname).

Joe

[Dan Watkins (daniel-thewatkins)]

Hi Joe,

On 10/06/15 10:52, Joe Clifford wrote:
> Apologies for the tardy feedback. Many thanks to all involved,
> gratefully and much appreciated. From my perspective, this issue is now
> resolved.

Thanks for the feedback. Great to hear that we've resolved this for you!

> I've just tried this on a freshly deployed Trusty VM in Azure - a
> change to the hostname with 'hostnamectl' is now preserved when the VM
> is rebooted.
>
> I would like to point out though that, if not editing the /etc/hostname
> file directly, the 'hostnamectl' command must be used to set the
> hostname; using the 'hostname' command doesn't work (presumably because
> the hostname command doesn't change /etc/hostname).

As per the 'hostname' manpage:

When called with one argument ..., the commands set the host name ...
Note, that this is effective only until the next reboot. Edit
/etc/hostname for permanent change.

So that sounds like expected behaviour. :)

Thanks,

Dan

[Joe Clifford (joeclifford)]

On 10/06/15 13:31, Dan Watkins wrote:
> Hi Joe,
>
> On 10/06/15 10:52, Joe Clifford wrote:
>> Apologies for the tardy feedback. Many thanks to all involved,
>> gratefully and much appreciated. From my perspective, this issue is now
>> resolved.
>
> Thanks for the feedback. Great to hear that we've resolved this for you!
>
>> I've just tried this on a freshly deployed Trusty VM in Azure - a
>> change to the hostname with 'hostnamectl' is now preserved when the VM
>> is rebooted.
>>
>> I would like to point out though that, if not editing the /etc/hostname
>> file directly, the 'hostnamectl' command must be used to set the
>> hostname; using the 'hostname' command doesn't work (presumably because
>> the hostname command doesn't change /etc/hostname).
>
> As per the 'hostname' manpage:
>
> When called with one argument ..., the commands set the host name ...
> Note, that this is effective only until the next reboot. Edit
> /etc/hostname for permanent change.
>
> So that sounds like expected behaviour. :)
Indeed! It's been a long time since I read that manpage.

Thanks again.

>
>
> Thanks,
>
> Dan
>