Debian10 + snap. DHPC failure?

LXD
1

Hi,

I’m trying to set up LXD on Debian10. I can create containers, but they don’t get IPs

So far this is what I’ve done.

apt install snapd
snap install lxd

lxd init
Would you like to use LXD clustering? (yes/no) [default=no]: no
Do you want to configure a new storage pool? (yes/no) [default=yes]: yes
Name of the new storage pool [default=default]: 
Name of the storage backend to use (btrfs, ceph, dir, lvm) [default=btrfs]: dir
Would you like to connect to a MAAS server? (yes/no) [default=no]: 
Would you like to create a new local network bridge? (yes/no) [default=yes]: yes
What should the new bridge be called? [default=lxdbr0]: 
What IPv4 address should be used? (CIDR subnet notation, “auto” or “none”) [default=auto]: 
What IPv6 address should be used? (CIDR subnet notation, “auto” or “none”) [default=auto]: none
Would you like LXD to be available over the network? (yes/no) [default=no]: 
Would you like stale cached images to be updated automatically? (yes/no) [default=yes] 
Would you like a YAML "lxd init" preseed to be printed? (yes/no) [default=no]:

Updated root’s path editing ~/.bashrc with PATH=$PATH:/snap/bin

Created a container

lxc launch images:debian/buster mariadb
lxc stop mariadb
lxc network attach lxdbr0 mariadb eth0 eth0
lxc config device set mariadb eth0 ipv4.address 10.??.??.??
lxc start mariadb

lxc list outputs

+---------+---------+------+------+------------+-----------+
|  NAME   |  STATE  | IPV4 | IPV6 |    TYPE    | SNAPSHOTS |
+---------+---------+------+------+------------+-----------+
| mariadb | RUNNING |      |      | PERSISTENT | 0         |
+---------+---------+------+------+------------+-----------+

Here’s what ip add sh ouputs

lxdbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 42:c0:b0:ae:58:70 brd ff:ff:ff:ff:ff:ff
    inet 10.32.10.1/24 scope global lxdbr0
       valid_lft forever preferred_lft forever
    inet6 fe80::30a2:bff:fe59:2f33/64 scope link 
       valid_lft forever preferred_lft forever
9: vethf4aa558b@if8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master lxdbr0 state UP group default qlen 1000
    link/ether 42:c0:b0:ae:58:70 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet6 fe80::40c0:b0ff:feae:5870/64 scope link 
       valid_lft forever preferred_lft forever

and dhcp seems to be running ps -ef |grep dhcp

lxd        811     1  0 15:45 ?        00:00:00 dnsmasq --strict-order --bind-interfaces --pid-file=/var/snap/lxd/common/lxd/networks/lxdbr0/dnsmasq.pid --except-interface=lo --no-ping --interface=lxdbr0 --quiet-dhcp --quiet-dhcp6 --quiet-ra --listen-address=10.32.10.1 --dhcp-no-override --dhcp-authoritative --dhcp-leasefile=/var/snap/lxd/common/lxd/networks/lxdbr0/dnsmasq.leases --dhcp-hostsfile=/var/snap/lxd/common/lxd/networks/lxdbr0/dnsmasq.hosts --dhcp-range 10.32.10.2,10.32.10.254,1h -s lxd -S /lxd/ --conf-file=/var/snap/lxd/common/lxd/networks/lxdbr0/dnsmasq.raw -u lxd
1000000   1951  1881  0 16:09 ?        00:00:00 /sbin/dhclient -4 -v -i -pf /run/dhclient.eth0.pid -lf /var/lib/dhcp/dhclient.eth0.leases -I -df /var/lib/dhcp/dhclient6.eth0.leases eth0

Could it possible be a firewall issue?

iptables -L -vn

Chain INPUT (policy DROP 1392 packets, 142K bytes)
 pkts bytes target     prot opt in     out     source               destination         
    4   336 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0           
 2996  488K ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED
   13   780 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:22
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:80
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:443

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 2306 packets, 341K bytes)
 pkts bytes target     prot opt in     out     source               destination         
# Warning: iptables-legacy tables present, use iptables-legacy to see them

iptables-legacy -L -vn

Chain INPUT (policy ACCEPT 4420 packets, 621K bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 ACCEPT     tcp  --  lxdbr0 *       0.0.0.0/0            0.0.0.0/0            tcp dpt:53 /* generated for LXD network lxdbr0 */
    0     0 ACCEPT     udp  --  lxdbr0 *       0.0.0.0/0            0.0.0.0/0            udp dpt:53 /* generated for LXD network lxdbr0 */
   54 17712 ACCEPT     udp  --  lxdbr0 *       0.0.0.0/0            0.0.0.0/0            udp dpt:67 /* generated for LXD network lxdbr0 */

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 ACCEPT     all  --  *      lxdbr0  0.0.0.0/0            0.0.0.0/0            /* generated for LXD network lxdbr0 */
    0     0 ACCEPT     all  --  lxdbr0 *       0.0.0.0/0            0.0.0.0/0            /* generated for LXD network lxdbr0 */

Chain OUTPUT (policy ACCEPT 2356 packets, 348K bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 ACCEPT     tcp  --  *      lxdbr0  0.0.0.0/0            0.0.0.0/0            tcp spt:53 /* generated for LXD network lxdbr0 */
    0     0 ACCEPT     udp  --  *      lxdbr0  0.0.0.0/0            0.0.0.0/0            udp spt:53 /* generated for LXD network lxdbr0 */
    0     0 ACCEPT     udp  --  *      lxdbr0  0.0.0.0/0            0.0.0.0/0            udp spt:67 /* generated for LXD network lxdbr0 *

iptables-legacy reports Input policy as ACCEPT and iptables reports input policy as DROP (as I want it).

Any thoughts?

Thanks a lot.
:slight_smile:

2

OK. It seems I need to learn more about nf_tables.

Meanwhile, to solve snap’s apparent disagreement with debian’s defaults, I solved this with

update-alternatives --set iptables /usr/sbin/iptables-legacy
update-alternatives --set ip6tables /usr/sbin/ip6tables-legacy

Rebooted, and the container gets it’s IP.

Cheers.

2 Likes
3

Ah yeah, Debian switched to the nft wrappers which are very confusing and also only partially correct.
We have an open issue to implement direct nft support into LXD which will solve this kind of situation properly in the near future.

2 Likes
4

Thanks so much for that, @buttle!

A wee note, I avoided the reboot by doing:

# snap restart lxd
1 Like
5

Here’s the issue for the nf_tables migration. I’m actively tracking this issue too. https://github.com/lxc/lxd/issues/6223

6

A tentative solution might be to write your own rules for the bridge in the iptables interface. Should have only to write once. You will need to make changes if you want to forward specific ports to your containers, however.

Make sure you move all the rules as there as some in the mangle (for checksum) and nat tables.