Not all platforms running cloud-init end up with the system hostname resolveable by default

[ubuntu-server-builder]

This bug was originally filed in Launchpad as LP: #1741277

Launchpad details

affected_projects = ['cloud-images', 'cloud-init (Ubuntu)']
assignee = None
assignee_name = None
date_closed = None
date_created = 2018-01-04T15:05:13.488874+00:00
date_fix_committed = None
date_fix_released = None
id = 1741277
importance = undecided
is_complete = False
lp_url = https://bugs.launchpad.net/cloud-init/+bug/1741277
milestone = None
owner = smoser
owner_name = Scott Moser
private = False
status = confirmed
submitter = racb
submitter_name = Robie Basak
tags = []
duplicates = []

Launchpad user Robie Basak(racb) wrote on 2018-01-04T15:05:13.488874+00:00

Except for existing setups, almost everyone will want manage_etc_hosts: localhost by default. Without this, various things end up broken because a system can't look up its own hostname.

Are there any use cases where a default of manage_etc_hosts: localhost will cause problems?

To avoid stepping on people's toes, I'm not suggesting making the change retrospectively. But if new Ubuntu releases start doing it (eg. with Bionic) and old releases maintain existing behaviour, then we'd get there over time. Is there any existing mechanism or process for changing cloud-init defaults like this?

[ubuntu-server-builder]

Launchpad user Robie Basak(racb) wrote on 2018-01-04T15:28:25.835565+00:00

15:25 I suppose the real intention of my bug is "not all platforms running cloud-init make the system hostname resolveable by default" 15:26 I'd consider it resolved as soon as that is true.

[ubuntu-server-builder]

Launchpad user Robie Basak(racb) wrote on 2018-01-04T15:29:52.910735+00:00

Scott pointed out that on a "proper" cloud, the hostname is resolveable by DNS because that's the name given to the instance by the cloud. This isn't the case on lxd though, for example. And I'm not sure that it makes sense to round trip local hostname lookups through the network in the "proper" cloud case anyway.

[ubuntu-server-builder]

Launchpad user Scott Moser(smoser) wrote on 2018-01-04T15:52:38.078086+00:00

fwiw, its sudo that is causing the roundtrip. you can certainly come up with reasons to pay a round trip. the infrastructure then can make changes and each system magically picks them up. its the reason we don't ship /etc/hosts files around anymore.

all that said, this issue can definitely be handled better than it is. A couple options:

a.) cloud-init could use manage_etc_hosts=localhost on platforms it knows will not provide dns lookup (this though coudl change, and probably should change on lxd, and then cloud-init has to be updated to accomodate... it gets tricky to service that logic if it ever changes as customers will use different versions of lxd).

b.) libnss-myhostname might be able to help. that is mentioned by xnox in a related bug bug 1730744.

More conversation took place in IRC at https://irclogs.ubuntu.com/2018/01/04/%23ubuntu-server.html#t14:57

[ubuntu-server-builder]

Launchpad user Scott Moser(smoser) wrote on 2018-01-04T15:54:11.363810+00:00

marked as cloud-images as that is where the change for nss-myhostname would be made (i think).

[ubuntu-server-builder]

Launchpad user Steve Langasek(vorlon) wrote on 2018-01-04T17:25:54.703200+00:00

We have repeatedly rejected nss-myhostname as a solution in Ubuntu; it adds additional runtime complexity for an issue that had been serviceably addressed by configuring /etc/hosts in tandem with /etc/hostname. The only case where nss-myhostname actually makes sense is if you have a read-only /etc, which is not true here.

AIUI lxd is setting /etc/hostname, but is not adding the Ubuntu-standard entry (127.0.1.1 hostname.domain hostname) to /etc/hosts; so that should be fixed in lxd.

[ubuntu-server-builder]

Launchpad user Robie Basak(racb) wrote on 2018-01-04T17:41:40+00:00

On Thu, Jan 04, 2018 at 05:25:54PM -0000, Steve Langasek wrote:

AIUI lxd is setting /etc/hostname, but is not adding the Ubuntu-standard entry (127.0.1.1 hostname.domain hostname) to /etc/hosts; so that should be fixed in lxd.

That's not currently an Ubuntu-standard on clouds, AIUI. cloud-init can arrange to make it so, but it doesn't by default. System hostname lookup works on cloud services because their respective infrastructures provide DNS resolution for instance hostnames.

We could have lxd always ensure the entry in /etc/hosts. That won't conflict with cloud-init, and will resolve my problem. But what about Ubuntu on cloud services? Do you think the current behaviour is wrong?

[ubuntu-server-builder]

Launchpad user Steve Langasek(vorlon) wrote on 2018-01-04T17:57:32+00:00

On Thu, Jan 04, 2018 at 05:41:40PM -0000, Robie Basak wrote:

On Thu, Jan 04, 2018 at 05:25:54PM -0000, Steve Langasek wrote:

AIUI lxd is setting /etc/hostname, but is not adding the Ubuntu-standard entry (127.0.1.1 hostname.domain hostname) to /etc/hosts; so that should be fixed in lxd.

That's not currently an Ubuntu-standard on clouds, AIUI. cloud-init can arrange to make it so, but it doesn't by default. System hostname lookup works on cloud services because their respective infrastructures provide DNS resolution for instance hostnames.

We could have lxd always ensure the entry in /etc/hosts. That won't conflict with cloud-init, and will resolve my problem. But what about Ubuntu on cloud services? Do you think the current behaviour is wrong?

Yes. Anywhere that we are setting /etc/hostname, we should also be updating /etc/hosts for 127.0.1.1.

[ubuntu-server-builder]

Launchpad user Scott Moser(smoser) wrote on 2018-01-04T18:00:19.133971+00:00

I agree with Robie, yes we can fix lxd to modify file contents in the guest more than it already does. But that is quite hacky. It would be equivalent to having cloud-init set manage_etc_hosts to localhost on lxd.

that does not solve the problem everywhere though.

[ubuntu-server-builder]

Launchpad user Robie Basak(racb) wrote on 2018-01-04T18:00:47.034126+00:00

We could have lxd always ensure the entry in /etc/hosts. That won't conflict with cloud-init, and will resolve my problem.

uvtool and multipass will also need to be adjusted. Currently I don't think either do anything to the image except through cloud-init. Perhaps the right way in this case is to have them vendor-data manage_etc_hosts?

[ubuntu-server-builder]

Launchpad user Jeremy Bícha(jbicha) wrote on 2018-04-24T17:50:13.444337+00:00

The only case where nss-myhostname actually makes sense is if you have a read-only /etc, which is not true here.

I disagree. It is annoying that system administrators need to change both /etc/hostname and /etc/hosts instead of being able to change just one place: /etc/hostname (or use hostnamectl).

On recent standard Ubuntu, systemd-resolved handles this. Otherwise, libnss-myhostname is what the systemd documentation recommends.

https://www.freedesktop.org/wiki/Software/systemd/hostnamed/ https://manpages.debian.org/unstable/nss-resolve

[ubuntu-server-builder]

Launchpad user Steve Langasek(vorlon) wrote on 2018-04-24T20:31:56+00:00

On Tue, Apr 24, 2018 at 05:50:13PM -0000, Jeremy Bicha wrote:

The only case where nss-myhostname actually makes sense is if you have a read-only /etc, which is not true here.

I disagree. It is annoying that system administrators need to change both /etc/hostname and /etc/hosts instead of being able to change just one place: /etc/hostname (or use hostnamectl).

hostnamectl should manage both /etc/hostname and /etc/hosts on Ubuntu. I am fairly certain that it did in the past.

I think that, aside from users who would use gnome-control-center + hostnamectl anyway, changing a hostname is a very infrequent operation and any admins who are doing this are not going to be troubled by editing /etc/hosts in addition to /etc/hostname.

I don't like increasing the number of moving parts involved in host resolution. We pay a cost for each additional nss module that we have to fall through when searching, and I am not at all convinced that this module is worth it.

On recent standard Ubuntu, systemd-resolved handles this. Otherwise, libnss-myhostname is what the systemd documentation recommends.

We don't take upstream documentation as gospel when it comes to questions of how we integrate Ubuntu.

[puck]

Would this be easily resolved for the Ubuntu case by adding a hosts.ubuntu.tmpl file with the suitable line? (Just copy hosts.debian.tmpl)

Perhaps there could be a default template that is selected? Users/Clouds can always disable management of /etc/hosts if they don't want it.