/etc/hosts is updated based on /etc/cloud/templates/hosts.tmpl

[John Baptist]

Binary package hint: cloud-init

The /etc/cloud/templates/ contains templates which are used to update various configuration files in response to changing cloud metadata. The files /etc/apt/sources.list and /etc/default/locale are updated in this manner. However, the file /etc/cloud/templates/hosts.tmpl, which should be a template for /etc/hosts, is ignored. Changes to this files, followed by reboots or calls to cloud-init will not result in changes to /etc/hosts. This is especially problematic, because it's important to update the /etc/hosts files so that the cloud can refer to itself by its own hostname.

I'm testing this on Ubuntu 10.04.2, using cloud-init 0.5.10-0ubuntu1.5, but the problem persists even on cloud-init version 0.6.0.

[Scott Moser (smoser)]

Thank you for opening this bug.

bug 407861 has more information on why this change was made.
We decided not to overwrite /etc/hosts, and let that stay user-managed.

It would be easy for you to add a upstart job or startup script to handle this if you wanted.

I'm not 100% sold on the solution that is in place, but it would take careful execution, and would be a change (possibly harmful) to start writing /etc/hosts from a template again.

What do you think?

[John Baptist (jepst79)]

I understand that overwriting /etc/hosts, just like overwriting /etc/hostname and other important files, can cause problems, depending on how names get assigned by the cloud and how the user wants to configure the system. Similarly, _not_ overwriting them can cause problems; in my case, I discovered this problem because the command "ping `hostname`" didn't work, but "ping localhost" did. So, I would say that each of these overwritings should be optional and should be configurable in a fairly obvious way.

What's bad about the current set up is that it's not obvious that /etc/cloud/templates/hosts.tmpl is in fact completely ignored. I spent a few hours looking through source code and (non-existent) documentation in order to convince myself that there was in fact no way to activate overwriting of /etc/hosts on the basis of that template. So it's misleading that that file exists, since some files in /etc/cloud/templates/ are used, and some aren't, and without reading source code, there's no way to find out which is which.

If you decide that /etc/hosts should never be overwritten, then please at least remove /etc/cloud/templates/hosts.tmpl. But I'd prefer a compromise: perhaps if hosts.tmpl exists, then it is used to overwrite /etc/hosts, otherwise the original stands. That way a user who wants to disable templates just needs to delete the template file.

[Scott Moser (smoser)]

> If you decide that /etc/hosts should never be overwritten, then please
> at least remove /etc/cloud/templates/hosts.tmpl. But I'd prefer a
> compromise: perhaps if hosts.tmpl exists, then it is used to overwrite
> /etc/hosts, otherwise the original stands. That way a user who wants to
> disable templates just needs to delete the template file.

I'm really weary about changing the current behavior, just because it
would be unexpected to users and their /etc/hosts would be destroyed.
How about this:
 - leave the file in place, but by default doing nothing
 - if cloud-config (/etc/cloud/cloud.cfg) specifies
      manage_etc_hosts: True
   then it will be used
 - comment in the top of /etc/cloud/templates/hosts.tmpl that
   tells about manage_etc_hosts

Would you be ok with that ?

To be honest, the file hosts.tmpl should have just been deleted when the
code was changed to not use it.

[John Baptist (jepst79)]

Hi Scott,

Your proposal works fine for me.

[John Baptist (jepst79)]

Although there is something to be said for a more general solution that lets arbitrary files be updated automatically, according to the user's preferences.

[Scott Moser (smoser)]

fix was applied.
I actually like this for Eucalyptus when there is no dns being managed. Then you wont get warnings from 'sudo' saying it doesn't know your hostname.

[Eric Hammond (esh)]

I would like to see a solution like the following for this and other files generated at startup (e.g., apt sources):

If the user has not modified the file since it was created from a template, then the system should feel free to continue maintaining that file by regenerating it from the template on reboot, instance stop/start, booting of a new instance of an AMI based on an old instance, etc.

This could be done by saving a hash or signature of the file after generating it from the template. If the signature no longer matches, then the file should not be overwritten again, but if the signature still matches, then the system should update the file to match the current environment (IP addresses, EC2 region, etc.).

I think this solves most of the problems that folks are experiencing with the files not being maintained, while not creating the problems that would be experienced by users who want to manage their own files.

[Scott Moser (smoser)]

On Thu, 17 Feb 2011, Eric Hammond wrote:

> If the user has not modified the file since it was created from a
> template, then the system should feel free to continue maintaining that
> file by regenerating it from the template on reboot, instance
> stop/start, booting of a new instance of an AMI based on an old
> instance, etc.

Eric, could you open a bug requesting this?

Scott

[Launchpad Janitor (janitor)]

This bug was fixed in the package cloud-init - 0.6.1-0ubuntu1

---------------
cloud-init (0.6.1-0ubuntu1) natty; urgency=low

  * New upstream release.
  * fix for puppet configuration options (LP: #709946) [Ryan Lane]
  * fix pickling of DataSource, which broke seeding.
  * turn resize_rootfs default to True
  * avoid mounts in DataSourceOVF if 'read' on device fails
    'mount /dev/sr0' for an empty virtual cdrom device was taking 18 seconds
  * add 'manual_cache_clean' option to select manual cleaning of
    the /var/lib/cloud/instance/ link, for a data source that might
    not be present on every boot
  * make DataSourceEc2 retries and timeout configurable
  * add 'bootcmd' like 'runcmd' to cloud-config syntax for running things early
  * move from '#opt_include' in config file format to conf_d.
    now local config files should live in /etc/cloud/cloud.cfg.d/
  * move /etc/cloud/distro.cfg to /etc/cloud/cloud.cfg.d/90_dpkg.cfg
  * allow /etc/hosts to be written from hosts.tmpl. which allows
    getting local-hostname into /etc/hosts (LP: #720440)
  * better handle startup if there is no eth0 (LP: #714807)
  * update rather than append in puppet config [Marc Cluet]
  * add cloud-config for mcollective [Marc Cluet]
 -- Scott Moser <email address hidden> Sat, 19 Feb 2011 01:16:10 -0500

[James Falcon (falcojr)]

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