I’m trying to do a LXC setup with 2 network devices.
First I changed /etc/network/interfaces, because multi device is not supported by dietpi-config
Because DietPi should not access the network connected to eth0 in normal mode, the cable is disconnected most the time.
Only during updates, internet access is required and eth0 is connected.
iface lo inet loopback
# Ethernet with wan access
iface eth0 inet dhcp
# restricted network only
iface jail inet static
When starting the machine with eth0 disconnected, I got the correct nameserver.
After pluggin in the eth0 network cable nothing changed. I did not get an IP address on eth0.
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
2: eth0@if206: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state LOWERLAYERDOWN group default qlen 1000
link/ether b6:29:aa:ea:bd:58 brd ff:ff:ff:ff:ff:ff link-netnsid 0
3: jail@if207: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether e2:9e:0f:67:83:75 brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet 192.168.203.220/24 brd 192.168.203.255 scope global jail
valid_lft forever preferred_lft forever
So I tried installing ifplugd.
With ifplugd installed eth0 gets an IP via dhcp and /etc/resolv.conf changed.
Thats what I was looking for. Fine. But …
When I disconnect the /etc/resolv.conf did not change anymore to the correct nameserver.
How to setup the correct dns server handling?
You need to use resolvconf for this, to remember the nameservers for each connection.
Thank you for your hint. And sorry, I’m not very familiar with DietPi or any other Debian baesd distro yet.
So I can guess only what to do…
There is no resolvconf installed. The systemd-resolved service is installed but not enabled by default. Ok. But as I said before the /etc/resoved.conf is changed by somebody. But who did it?
Hm, should I use the old resolvcontrol or the newer systemd service? Whats the up-to-date way?
When starting systemd-resolved the service is running. But trying to us systemd-resolved I got an error:
sd_bus_open_system: No such file or directory
Digging deeper. Found that dbus is missing in DietPi, but required by systemd-resolve. After installing dbus and enabling dbus service resolvctl seems to work.
But in effect nothing with DNS handling has changed
How to go on?
I think that its in fact a DietPi Problem.
The first question that arises here: Is systemd strategic under DietPi or not. Each distribution can decide that for itself.
If yes, then resolvcontrol is not the right approach since systemd-resolved is a part of systemd. And this means that any possible documentation relating to resolvcontrol would be irrelevant.
In addition, DietPi cannot be compared with a desktop Linux because it is designed as a small, slim system. In addition, desktop systems usually use NetWorkManager to configure the network by the user. So only server distributions remain for comparison.
But server distributions in particular can handle several network interfaces out of the box. Completely different then DietPi.
And if I need ifplugd anyway so that I can recognize under DietPi that a network cable has been removed, then I can also rewrite the /etc/resolv.conf with just a few lines of code in the ifplugd script depending on the active network connection.
Then all the rest is just unnecessary ballast.
But is this the strategically right path for DietPi?
Only DietPi itself can answer this question. Nothing about Ubuntu, SuSE, RedHat or Debian is of any use to me
You need to install
dbus, it’s not installed by default.
Your usecase can be covered with
sudo nano /etc/systemd/network/eth0.network
then create the same file for your other interface and restart the service
sudo systemctl restart systemd-resolved
DietPi is not a separate OS or distro. It’s a set of scripts on top of a base image (Debian or Raspbian)
I think one of the main problems is that DietPi doesn’t register when the network connection is cut.
The eth0 device remains active if it was active druing boot and it also retains the address assigned via DHCP. The dhclient tries to get an address, but doesn’t get one because the cable was cut.
Even after the lease time has expired and the DHCP server has assigned the address to someone else, the address remains active.
If the connection is reestablished afterwards, an address conflict will occur.
If you want or need to correct this behavior, ifplugd must be installed and configured.
I can’t solve the dns problem with systemd-resolved yet. I have to restart the network by hand to make things work. But this ended in about 1 minute total connection loss (like on boot).
So I modded the ifplugd.action script. And everything worked like a charm.