sudo: unable to resolve host

[cmars]

Required information

$ cat /etc/os-release 
NAME="Ubuntu"
VERSION="16.04 (Xenial Xerus)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 16.04"
VERSION_ID="16.04"
HOME_URL="http://www.ubuntu.com/"
SUPPORT_URL="http://help.ubuntu.com/"
BUG_REPORT_URL="http://bugs.launchpad.net/ubuntu/"
UBUNTU_CODENAME=xenial

$ lxc info
apicompat: 0
auth: trusted
environment:
  addresses:
  - 192.168.88.234:8443
  - 192.168.122.1:8443
  - 10.0.3.1:8443
  - 10.172.66.136:8443
  - '[2001:67c:1562:8007::aac:4288]:8443'
  architectures:
  - x86_64
  - i686
  certificate: |
    -----BEGIN CERTIFICATE-----
    MIIFqjCCA5KgAwIBAgIQXpne6Qjwhg8de+RmyV1+mTANBgkqhkiG9w0BAQsFADA6
    MRwwGgYDVQQKExNsaW51eGNvbnRhaW5lcnMub3JnMRowGAYDVQQDDBFyb290QG1h
    d2hyaW4tc2tlbDAeFw0xNjAyMjgwMzEyMzdaFw0yNjAyMjUwMzEyMzdaMDoxHDAa
    BgNVBAoTE2xpbnV4Y29udGFpbmVycy5vcmcxGjAYBgNVBAMMEXJvb3RAbWF3aHJp
    bi1za2VsMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAzv/3uX3JWduq
    wmtbyTABmfJkup6Z5Lh4lKPXgL/H2gQ/mlccORKm1eDZhAGmv9UuQGeMRHEneJqD
    V9c3f7/9cJBwvz2loKlppWj0ohAzTP91L8paeUSfP4X9EAr702Qjyb2ig+xWv5tM
    cJxbdl0zGpjYO1P+xmUdthSidsFrzWQPXptOlcZvak7n0QL5GlkVXdqX+she2Pbs
    ONtyTaBSpF3zEYv6cM9ZeJYL4Hl7LEQ1/p8ojpOyaxO8B1Cn/gIbuDqgzRwmei90
    Aca06YDF4SHVcl8qFajrwkPF3jWW5pgS8sAJlYoq2+ROhl0CnpdBl4AiJrvfFsIs
    RL8dKSuFA6AcLhYooWgMy6UWR8mLbmYHp04ThuBDoRaTt0uGLDlTAfMg7e8Gwpz+
    aEwxSzzQhvJYr4e6TSP1C4zXNqS5mUHfm6RtfEccVFmq6vyqZGELAyREce76J88V
    FMf/V+KYlQYUxo0JH2k+BYMO4Iigar0+8p8o8drqh6Lks5zTP6idsKa0LSWA4rwm
    3+5hjnVJtFa9CVCItJW3r0+nczwtAbjvRojkr7Yb2Kifufhilb+I695qSk+Toug3
    HKOODTqc9sbH+urmfr7jBBexACtWVX/tMptWFnBmcqoN4ptSZutY7CPf+KR//9p0
    8fFRQP+ItmElJHRFO+madGOBMVrC7j8CAwEAAaOBqzCBqDAOBgNVHQ8BAf8EBAMC
    BaAwEwYDVR0lBAwwCgYIKwYBBQUHAwEwDAYDVR0TAQH/BAIwADBzBgNVHREEbDBq
    ggxtYXdocmluLXNrZWyCETE5Mi4xNjguODguMjM0LzI0ghxmZTgwOjozZWE5OmY0
    ZmY6ZmU1Njo0N2RjLzY0ggsxMC4wLjMuMS8yNIIcZmU4MDo6NThkNTpjMmZmOmZl
    ZTQ6NzJiYy82NDANBgkqhkiG9w0BAQsFAAOCAgEAB6aFItuxlZm5+2/IB2eCVAM0
    eQbO6dfvfF2khfiEbWWaKPtkZSYKlDIcoOph35obnNMQjT+y4zlnF/fepvjq8P1R
    yGd+Q+GMcXWVRht3uIMW2ZqwNqOujunyn9+Hl1SYi1dV1g/CH9lJt8I7FKIvyieh
    siZRe5Zp7TdPREkIJveuz8qB3X87WVh9bqvMpoX91Mgrjzd3qATef/tN0HP+b26Y
    XjtRz9rhOkUfJx9b5HsyBLuGOQS979twl9LPKc1WsIrJaavY1JBT7SIwX3W7u7CU
    UWueEQoVvA9pkgeL8NXYYoHOkkrfW3oqExkuA1pqucMt8iRjn88njV57Vk576tjZ
    +bNqLL6R4xoUvnr9VIwq7tMLvodK/E5WvsmP5GrdMru2sa/xd+fS0137oOYqP4Qb
    T296jMcehHg5Gg1ZR1DbTqzWFPKb+CtXU+bqI68Hplq5Lemufsman2C2dthmKwcm
    OumpykWiH9vNKauY52VR8iffppBsH7jup1+yVtIOiT4Whp5LGBtZdYri7GE77qv+
    qtBL7HdeBJxsBadRIfjdeLZlZPlMX7hV+v8Bzxz9fGuPKSnxDdpoPw1XF+zP1YAn
    VeDCRo7oCFV40nVFyb5wCreDoegtSFuQt7/Guv9u/gQSfmGoY1QyjlaHh2pJAAgS
    CPRGObnrdrQMMEqLDaI=
    -----END CERTIFICATE-----
  driver: lxc
  driverversion: 2.0.0.rc10
  kernel: Linux
  kernelarchitecture: x86_64
  kernelversion: 4.4.0-12-generic
  server: lxd
  serverpid: 2354
  serverversion: 2.0.0.rc3
  storage: zfs
  storageversion: "5"
config:
  core.https_address: '[::]'
  storage.zfs_pool_name: lxdpool
public: false

Issue description

When I use sudo in containers launched with LXD, I get an error message sudo: unable to resolve host

Steps to reproduce

$ lxc launch ubuntu-trusty bob
Creating bob
Starting bob
$ lxc exec bob bash
root@bob:~# sudo -i
sudo: unable to resolve host bob

I see these messages all the time in scripts that use sudo in my containers. It happens during Juju bootstrap for example but is in no way a Juju-specific issue, as the above demonstrates.

I've happily ignored this message and everything seems to work fine as far as I can tell. The problem with this message is that it tends to mislead users into thinking something is wrong -- it's a rough edge.

Let me know if anything else will help.

[stgraber]

That's because cloud-init doesn't update /etc/hosts by default and since we rely on cloud-init to setup the hostname, you end up with that error.

If you're already feeding cloud-init user data, you can add the "manage_etc_hosts: True" key to it.

@smoser what's the reason for cloud-init not updating /etc/hosts at the same time it does /etc/hostname by default?

[stgraber]

Closing this as there is nothing that LXD can do about this. Ubuntu cloud images are using cloud-init for their initial configuration, so if it makes sense to have the hosts line generated, this should be fixed there rather than in LXD.

[justinnoor]

Hi how are you, my name is Justin. I am new with LXD and I am not quite clear on the recommendation above:

"If you're already feeding cloud-init user data, you can add the "manage_etc_hosts: True" key to it."

I think this may relate to some really strange behavior that I get with LXD, but my issue seems to be slightly different.

I posted about it here but was unsuccessful in getting any responses.

[smoser]

For better or worse, some applications will essentially do hostname -f and then bind to that socket, or advertise that address as their address (bug 871966). That is why the default behavior in Ubuntu images is to not write an entry for hostname. To my knowledge, currently in lxd cloud-init would not have enough information to write an entry in /etc/hosts other than a localhost.

As suggested above, cloud-init can be told to a 127.0.1.1 entry into /etc/hosts for the hostname via emanage_etc_hosts: True. That is not the default behavior of cloud-init. Instead, it is assumed that that the cloud platform that set the hostname will also provide reverse lookup in dns. The cloud platform is in a much better position than a one-time-initialization program to provide a reverse lookup for dns.

Lastly, This is working as desired on my lxd locally:

$ lxc network show lxdbr0 | sed '/used_by/q'
config:
  ipv4.address: 10.75.205.1/24
  ipv4.nat: "true"
  ipv6.address: fd42:eee5:7c43:3d62::1/64
  ipv6.dhcp.stateful: "true"
name: lxdbr0
type: bridge
used_by:

$ lxc launch ubuntu-daily:trusty t1
$ sleep 10
$ lxc exec t1 /bin/bash

## This is inside container now.
# sudo echo hi
hi
# host t1
t1.lxd has address 10.75.205.227
# grep t1 /etc/hosts || echo not found
not found

# grep -v "^#" /etc/resolv.conf 
nameserver 10.75.205.1
search lxd

# host t1 10.75.205.1
Using domain server:
Name: 10.75.205.1
Address: 10.75.205.1#53
Aliases: 

t1.lxd has address 10.75.205.227

Given that.... should this bug be marked fixed?

[stgraber]

@smoser well, this was a reply to a closed bug, so not much closing we can do :)

But yes, I also couldn't reproduce it here with recent LXD. It "may" be a problem with older LXDs though where dnsmasq isn't managed by LXD itself. Though even then, dhclient running in the container will create the required DNS entries...

The most obvious case where this wouldn't work is if directly bridged to an existing external network where the DHCP running on that network doesn't also control the DNS.