This is a follow up to this issue: "routed" LXC containers with public IP in Vagrant . I realized that I was using “Ubuntu” image accidentally. My intention was to use Debian 10 though, and after changing image to “Debian 10 (cloud)” one, my setup broke.
Specifically: there is something different in Debian when it comes to routing and domain resolution.
Debian 10 container doesn’t connect to the internet by default, but we can make it work by setting up NAT on the host with:
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
Do anyone know why for Ubuntu container it wasn’t required? I could learn something new.
What still doesn’t work is domain resolution. As you can see below, I have 8.8.8.8 defined as a nameserver in my cloud-init configuration but it doesn’t work:
root@mail-server:~# ping google.com
ping: google.com: Temporary failure in name resolution
There is nothing suspicious in the /var/log/cloud-init-output.log .
In /etc/network/interfaces.d/50-cloud-init
I have:
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet static
address 192.168.7.201/32
dns-nameservers 8.8.8.8
post-up route add default gw 169.254.0.1 || true
pre-down route del default gw 169.254.0.1 || true
/etc/resolv.conf
contains only comments.
Host runs on Ubuntu 20.04 . Container is Debian 10.
LXC version: 4.0.4
My configuration:
config:
core.https_address: '[::]:8443'
core.trust_password: true
networks: []
storage_pools:
- config:
source: /home/luken/lxd-storage-pools
description: ""
name: default
driver: dir
profiles:
- config:
user.user-data: |
#cloud-config
users:
- name: luken
gecos: ''
primary_group: luken
groups: "sudo"
shell: /bin/bash
sudo: ALL=(ALL) NOPASSWD:ALL
ssh_authorized_keys:
- <REDACTED>
description: Default LXD profile
devices:
root:
path: /
pool: default
type: disk
name: default
- config:
user.network-config: |
#cloud-config
version: 2
ethernets:
eth0:
addresses:
- 192.168.7.201/32
nameservers:
addresses:
- 8.8.8.8
routes:
- to: 0.0.0.0/0
via: 169.254.0.1
on-link: true
description: Mail Server LXD profile
devices:
eth0:
ipv4.address: 192.168.7.201
nictype: routed
parent: eth1
type: nic
name: mail-server
I mean, I KNOW how to make it work, I could add nameserver 8.8.8.8
to /etc/resolv.conf
or something, but there is something wrong that cloud-init cannot handle it, so instead of hacking some workaround, I (and probably other lxc users) would rather like to know how to make cloud-init work correctly, or understand why it fails at that.
Any help would be appreciated
Added:
I also noticed a weird thing on the guest:
root@mail-server:/etc/resolvconf/resolv.conf.d# systemctl --failed
UNIT LOAD ACTIVE SUB DESCRIPTION
● networking.service loaded
failed failed Raise network interfaces
● systemd-journald-audit.socket loaded failed fail
ed Journal Audit Socket
LOAD = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB = The low-level unit activation state, values depend on unit type.
2 loaded units listed. Pass --all to see loaded but inactive units, t
oo.
To show all installed unit files use 'systemctl list-unit-files'.
root@mail-server:/etc/resolvconf/resolv.conf.d# systemctl status networking
● networking.service - Raise network interfaces
Loaded: loaded (/lib/systemd/system/networking.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Sun 2021-01-24 12:07:03 UTC; 7min ago
Docs: man:interfaces(5)
Process: 89 ExecStart=/sbin/ifup -a --read-environment (code=exited, status=1/FAILURE)
Main PID: 89 (code=exited, status=1/FAILURE)
Jan 24 12:07:03 mail-server systemd[1]: Starting Raise network interfaces...
Jan 24 12:07:03 mail-server ifup[89]: RTNETLINK answers: File exists
Jan 24 12:07:03 mail-server ifup[89]: ifup: failed to bring up eth0
Jan 24 12:07:03 mail-server systemd[1]: networking.service: Main process exited, code=exite
d, status=1/FAILURE
Jan 24 12:07:03 mail-server systemd[1]: networking.service: Failed with result 'exit-code'.
Jan 24 12:07:03 mail-server systemd[1]: Failed to start Raise network interfaces.
This is on barebones testing configuration, so I think it’s worth figuring out what’s going on here, as it may blocking a lot of people from enjoing lxc, because it looks like even Debian 10 doesn’t work without issues out of the box here.