Closed Wgsem closed 2 years ago
Pls try to reboot your system and check the log afterwards
journalctl -u unbound
-- Journal begins at Sat 2022-04-09 09:37:22 BST, ends at Sat 2022-04-09 09:38:0
3 BST. --
Apr 09 09:37:40 DietPi systemd[1]: Starting Unbound DNS server...
Apr 09 09:37:40 DietPi unbound[468]: [468:0] info: start of service (unbound 1.1
3.1).
Apr 09 09:37:40 DietPi systemd[1]: Started Unbound DNS server.
This is what I get after reboot. Makes me think it's working?
Yes looks like. You can check following as well
systemctl status unbound.service
This is the output:
root@DietPi:~# systemctl status unbound.service
● unbound.service - Unbound DNS server
Loaded: loaded (/lib/systemd/system/unbound.service; enabled; vendor preset
: enabled)
Drop-In: /etc/systemd/system/unbound.service.d
└─dietpi.conf
Active: active (running) since Sat 2022-04-09 09:37:40 BST; 4min
9s ago
Docs: man:unbound(8)
Process: 460 ExecStartPre=/usr/lib/unbound/package-helper chroot_setup (code
=exited, status=0/SUCCESS)
Process: 465 ExecStartPre=/usr/lib/unbound/package-helper root_trust_anchor_
update (code=exited, status=0/SUCCESS)
Main PID: 468 (unbound)
Tasks: 1 (limit: 2137)
CPU: 183ms
CGroup: /system.slice/unbound.service
└─468 /usr/sbin/unbound -d -p
Apr 09 09:37:40 DietPi systemd[1]: Starting Unbound DNS server...
Apr 09 09:37:40 DietPi unbound[468]: [468:0] info: start of service (unbound 1.1
3.1).
Apr 09 09:37:40 DietPi systemd[1]: Started Unbound DNS server.
But... Below is my installed list and unbound isn't showing
┌─────────────────────────────┤ DietPi-Software ├───────────────
│ [ ] 0 OpenSSH Client: Feature-rich SSH, SFTP and SCP client
│ [ ] 5 ALSA: Advanced Linux Sound Architecture
│ [ ] 6 X.Org X Server: aka X11 - X Window System implementation
│ [ ] 23 LXDE: ultra lightweight desktop
│ [ ] 66 RPi-Monitor: Web interface for Raspberry Pi real-time monitoring
│ [ ] 67 Firefox: web browser for desktop
│ [ ] 103 DietPi-RAMlog: Makes /var/log a RAM disk, preserves file structure
│ [ ] 105 OpenSSH Server: Feature-rich SSH server with SFTP and SCP support
│ [ ] 120 RealVNC Server: desktop for remote connection
If I try to install Unbound from inside Dietpi-software (where it's not showing as installed) this is what I get:
│ - Command: systemctl restart unbound
│ - Exit code: 1
│ - DietPi version: v8.3.1 (MichaIng/master) | HW_MODEL: 4 | HW_ARCH: 3
│ DISTRO: 6
│ - Image creator: DietPi Core Team
│ - Pre-image: from scratch
│ - Error log:
│ Warning: The unit file, source configuration file or drop-ins of
│ unbound.service changed on disk. Run 'systemctl daemon-reload' to reload
│ units.
│ Job for unbound.service failed because the control process exited with error
│ code.
Edit: for some reason all my replies show up twice :/
Somehow you are posting everything twice.
If you are hit by the issue, you should have an error handling menu. There should be an option to open a sub shell. Do this and execute systemctl daemon-reload
. Exit the sub shell and retry.
Did as you suggested, check status again and this is the outcome. I don't understand why it's not showing under software but is apparently installed but not running. Again, not sure why I'm double-posting my reply's. Sorry for that.
root@DietPi:~# systemctl status unbound.service ● unbound.service - Unbound DNS server Loaded: loaded (/lib/systemd/system/unbound.service; enabled; vendor preset: enabled) Drop-In: /etc/systemd/system/unbound.service.d └─dietpi.conf Active: failed (Result: exit-code) since Sat 2022-04-09 09:54:02 BST; 32s ago Docs: man:unbound(8) Process: 3519 ExecStartPre=/usr/lib/unbound/package-helper chroot_setup (code=exited, status=0/SUCCESS) Process: 3522 ExecStartPre=/usr/lib/unbound/package-helper root_trust_anchor_update (code=exited, status=0/SUCCESS) Process: 3525 ExecStart=/usr/sbin/unbound -d -p $DAEMON_OPTS (code=exited, status=1/FAILURE) Process: 3526 ExecStopPost=/usr/lib/unbound/package-helper chroot_teardown (code=exited, status=0/SUCCESS) Main PID: 3525 (code=exited, status=1/FAILURE) CPU: 83ms
Apr 09 09:54:02 DietPi systemd[1]: unbound.service: Scheduled restart job, restart counter is at 5. Apr 09 09:54:02 DietPi systemd[1]: Stopped Unbound DNS server. Apr 09 09:54:02 DietPi systemd[1]: unbound.service: Start request repeated too quickly. Apr 09 09:54:02 DietPi systemd[1]: unbound.service: Failed with result 'exit-code'. Apr 09 09:54:02 DietPi systemd[1]: Failed to start Unbound DNS server.
The dietpi-software
installation needs to be completed before it is showing up as installed software.
What does the log is stating now
journalctl -u unbound
Unbound tries to connect to IPv6 interface. Question, do you use IPv6? Yes or No?
unbound[3525:0] error: cannot open control interface ::1
can you check what configuration exist?
ls -la /etc/unbound/unbound.conf.d
No, I don't use IPv6.
This is the output:
root@DietPi:~# ls -la /etc/unbound/unbound.conf.d
total 16
drwxr-xr-x 2 root root 4096 Apr 9 09:03 .
drwxr-xr-x 3 root root 4096 Apr 9 09:03 ..
-rw-r--r-- 1 root root 3122 Apr 9 09:03 dietpi.conf
-rw-r--r-- 1 root root 190 Feb 9 2021 root-auto-trust-anchor-file.conf
Could this have anything to do with dietpi-vpn? I'm trying to run my outgoing traffic over VPN (Nordvpn/Nordlynx) and I did a fresh install and setup Nordvpn first (using dietpi-vpn). I've installed both AG Home and Unbound before with zero problems.
can you share unbound configuration as well as IP config
ip a
cat /etc/unbound/unbound.conf.d/dietpi.conf
Output:
root@DietPi:~# ip a
cat /etc/unbound/unbound.conf.d/dietpi.conf
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: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether e4:5f:01:98:3f:ba brd ff:ff:ff:ff:ff:ff
inet 192.168.1.100/24 brd 192.168.1.255 scope global dynamic eth0
valid_lft 82198sec preferred_lft 82198sec
3: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 500
link/none
inet 10.8.1.10/24 scope global tun0
valid_lft forever preferred_lft forever
# https://nlnetlabs.nl/documentation/unbound/unbound.conf/
server:
# Do not daemonize, to allow proper systemd service control and status estimation.
do-daemonize: no
# A single thread is pretty sufficient for home or small office instances.
num-threads: 1
# Logging: For the sake of privacy and performance, keep logging at a minimum!
# - Verbosity 2 and up practically contains query and reply logs.
verbosity: 0
log-queries: no
log-replies: no
# - If required, uncomment to log to a file, else logs are available via "journalctl -u unbound".
#logfile: "/var/log/unbound.log"
# Set interface to "0.0.0.0" to make Unbound listen on all network interfaces.
# Set it to "127.0.0.1" to listen on requests from the same machine only, useful in combination with Pi-hole.
interface: 127.0.0.1
# Default DNS port is "53". When used with Pi-hole, set this to e.g. "5335", since "5353" is used by mDNS already.
port: 5335
# Control IP ranges which should be able to use this Unbound instance.
# The DietPi defaults permit access from official local network IP ranges only, hence requests from www are denied.
access-control: 0.0.0.0/0 refuse
access-control: 10.0.0.0/8 allow
access-control: 127.0.0.1/8 allow
access-control: 172.16.0.0/12 allow
access-control: 192.168.0.0/16 allow
access-control: ::/0 refuse
access-control: ::1/128 allow
access-control: fd00::/8 allow
access-control: fe80::/10 allow
# Private IP ranges, which shall never be returned or forwarded as public DNS response.
# NB: 127.0.0.1/8 is sometimes used by adblock lists, hence DietPi by default allows those as response.
private-address: 10.0.0.0/8
private-address: 172.16.0.0/12
private-address: 192.168.0.0/16
private-address: 169.254.0.0/16
private-address: fd00::/8
private-address: fe80::/10
# Define protocols for connections to and from Unbound.
# NB: Disabling IPv6 does not disable IPv6 IP resolving, which depends on the clients request.
do-udp: yes
do-tcp: yes
do-ip4: yes
do-ip6: yes
# DNS root server information file. Updated monthly via cron job: /etc/cron.monthly/dietpi-unbound
root-hints: "/var/lib/unbound/root.hints"
# Maximum number of queries per second
ratelimit: 1000
# Defend against and print warning when reaching unwanted reply limit.
unwanted-reply-threshold: 10000
# Set EDNS reassembly buffer size to match new upstream default, as of DNS Flag Day 2020 recommendation.
edns-buffer-size: 1232
# Increase incoming and outgoing query buffer size to cover traffic peaks.
so-rcvbuf: 4m
so-sndbuf: 4m
# Hardening
harden-glue: yes
harden-dnssec-stripped: yes
harden-algo-downgrade: yes
harden-large-queries: yes
harden-short-bufsize: yes
# Privacy
use-caps-for-id: yes # Spoof protection by randomising capitalisation
rrset-roundrobin: yes
qname-minimisation: yes
minimal-responses: yes
hide-identity: yes
identity: "Server" # Purposefully a dummy identity name
hide-version: yes
# Caching
cache-min-ttl: 300
cache-max-ttl: 86400
serve-expired: yes
neg-cache-size: 4M
prefetch: yes
prefetch-key: yes
msg-cache-size: 50m
rrset-cache-size: 100m
Not sure why but your unbound configuration has IPv6 enabled > do-ip6: yes
try following
G_CONFIG_INJECT 'do-ip6:' ' do-ip6: no' /etc/unbound/unbound.conf.d/dietpi.conf
systemctl restart unbound
you should be able to install unbound + AGH now
dietpi-software install 126 182
The issue is that IPv6 is disabled automatically when connecting to the VPN. Most VPN providers do not support IPv6, NordVPN, AFAIK on a few selected servers only, so to prevent IPv6 leaks, it needs to be disabled. But Unbound is configured based on whether IPv6 is generally enabled (without taking the VPN into account).
As a quick solution, you can hence disable IPv6 via dietpi-config
> Network Options: Adapters.
Not sure if/how we can address this properly. Disabling IPv6 (hence starting the VPN) while Unbound is running is not an issue (hence no issue on Unbound start at reboot, before VPN is up), but when (re)starting the server, like during (re)install, of course it cannot bind to IPv6 when it's down. We could check whether the Internet facing adapter currently has an IPv6 address to decide whether to set the IPv6 flag, instead of for the general IPv6 toggle. So if the VPN is up during (re)install, it is configured to listen on and use IPv4 only. When the VPN is down, it depends on whether IPv6 is enabled or disabled in general. Sounds actually like a robust solution. I mean having IPv6 disabled for Unbound has no real downsides: It can still resolve AAAA records (IPv6 hosts), but clients can use IPv4 connections only to connect to it and it uses IPv4 connections to connect to upstream/root DNS servers.
In most cases, unbound is used together with PiHole or AGH. Means for this combination, no IPv6 is required at all. Isn't it?
Yes, I mean I don't know any case where IPv6 is "required", as long as not for whatever reasons people setup an IPv6-only LAN 😄. With Pi-hole and AGH at least dietpi-software
uses the IPv4 loopback address as upstream to connect to Unbound, so that is fine. This option, as far as I documented it that time, also affects how Unbound connects to upstream/root DNS, where it would somehow support modern Internet when IPv6 is used whenever possible, but, well, public VPN is another case which blocks that.
I'll have a look through Unbound options again. Probably there is a separation possible between Unbound port binding (connections to Unbound) and connections from Unbound. And probably there is some "auto" option for both or the latter, to simply use IPv6 only when the interface has an IPv6 address.
Not sure why but your unbound configuration has IPv6 enabled >
do-ip6: yes
try following
G_CONFIG_INJECT 'do-ip6:' ' do-ip6: no' /etc/unbound/unbound.conf.d/dietpi.conf systemctl restart unbound
you should be able to install unbound + AGH now
dietpi-software install 126 182
Sorry, yesterday I had to leave. I just tried the above, did a reboot and tried to install both again. Keep running into the same error. IPv6 shows turned off in dietpi-config. Only thing I can think of is dietpi-vpn causing the issue, but I'm too new to Dietpi to know for sure. Compared to earlier installs this is the only thing that changed.
I'm leaning towards starting from fresh again and install both AG + Unbound, check IPv6 before running dietpi-vpn.
Edit: still don't understand why all my replies show up twice too
is the VPN active while you try to install Unbound? And what is the actual setting in unbound configuration? Anouther thing to share is the log again
cat /etc/unbound/unbound.conf.d/dietpi.conf | grep do-ip6
journalctl -u unbound
Ah, I think the dietpi-config
option shows On/Off based on whether an IPv6 address has been assigned, while dietpi-software
looks for the dietpi.txt
setting. It should be the other way round so that dietpi-config
can be always toggled, despite IPv6 being temporarily disabled or due to a 3rd party/custom config, and dietpi-software
never enables IPv6 for software when it's disabled in any way.
Please stop the VPN, then disable IPv6 via dietpi-config
, then you can install Unbound with VPN again up. And after the installation, you can also enable IPv6 again via dietpi-config
, which has only an effect when the VPN is stopped.
Ok, here is what I did.
Set auto-reboot off in dietpi-vpn, rebooted the pi. Used dietpi-software to install Adguard, Unbound and Home Assistant. Rebooted again, turned IPv6 off and signed in to my VPN again.
By the looks of it everything is working but I haven't really set things up, I just don't get an error now. Are there any things usefull to test now? Thanks for helping me out so far, I didn't expect a reply this fast.
Set auto-reboot off in dietpi-vpn, rebooted the pi. Used dietpi-software to install Adguard, Unbound and Home Assistant.
Did you disable IPv6 before installing AdGuard Home and Unbound? That is the important part, as only then Unbound is configured to not used IPv6. After the installation finished, you can theoretically re-enable IPv6 (on the system) without any issues.
However, as Unbound has now successfully installed, no need to redo everything but you can now adjust the config manually:
G_CONFIG_INJECT 'do-ip6:[[:blank:]]' ' do-ip6: no' /etc/unbound/unbound.conf.d/dietpi.conf
systemctl restart unbound
Solved with: https://github.com/MichaIng/DietPi/commit/9407a8d
The same issue was true for Tor: We allowed to enter an IP address and enabled IPv6 usage for ORPort and exit relay only based on the dietpi.txt
setting. Much more robust to check whether there is an actual IPv6 default route, required not only for port binding but also to do an actual IPv6 connection to the Internet. If IPv6 is disabled via dietpi-config
, it is done for all interfaces, making it impossible to have an IPv6 default route, so this change does not add additional cases where functional IPv6 is assumed, but it only reduces the cases by those where IPv6 is temporarily disabled (e.g. due to a VPN connection), where it was manually disabled (without using dietpi-config
/dietpi.txt
) or where it was disabled for the individual Internet facing interface only.
Impressed by the help I got and how fast this is solved. Thanks
(Along with some coding changes) I changed dietpi-config
accordingly to show the IPv6 status (and allow enabling/disabling it) based on the dietpi.txt
setting. Previously it was checked whether any IPv6 address is assigned: https://github.com/MichaIng/DietPi/commit/054ae42
This way round it makes more sense, so one can toggle the DietPi controlled sysctl config independently from VPN or other temporary/custom/manual IPv6 changes. This means it then shows IPv6 "On" while it may be currently off due to VPN or other reasons. So the meaning changes more to "whether a DietPi generated configuration file disables IPv6 for all interfaces (Off) or not (On)". Not perfect either, but it solves practical issues. We could make it more complicated by adding some text when the dietpi.txt
setting is "On" while currently IPv6 is disabled for other reasons, but I'll wait for an actual report before adding this additional code.
I was having the exact same issue running ubuntu server 20.04 on a raspberry pi 4. My specific problem was that I am tunneling my raspberry pi server through a cloud instance vpn in order to obtain a fresh IP address, and get proper PTR records for my server. This took me forever to figure out why unbound wasn't installing, but this issue helped me resolve it. You are correct that having ipv6 interfaces enabled while running as an ipv4 only vpn client was indeed the problem. You can solve the isssue by disabling all ipv6 interfaces in
/etc/sysctl.conf
(the equivilent of/etc/unbound/unbound.conf.d/dietpi.conf
), by adding the following lines:
net.ipv6.conf.all.disable_ipv6=1
net.ipv6.conf.default.disable_ipv6=1
net.ipv6.conf.lo.disable_ipv6=1
net.ipv6.conf.eth0.disable_ipv6=1
net.ipv6.conf.wlan0.disable_ipv6=1
then running the command sudo sysctl -p
.
Theoretically, this should be all you need to do to fully disable ipv6, thus allowing unbound to have a successful install. HOWEVER, I chose to disable ipv6 on all interfaces via a much easier approach. This solution works for raspberry pi only, but you can find the equivilent file in x86 versions of grub to edit.
All I did to solve this was add "ipv6.disable=1" to the /boot/firmware/cmdline.txt
file. So the entire line on my /boot/firmware/cmdline.txt
file looks like this:
net.ifnames=0 dwc_otg.lpm_enable=0 console=serial0,115200 console=tty1 root=LABEL=writable rootfstype=ext4 elevator=deadline rootwait fixrtc ipv6.disable=1
I'm certain dietpi has an equivilent file to cmdline.txt on the raspberry pi version. Hope this helps to anyone reading and having the problem with installing unbound on ubuntu server 20.04.
Not exactly the same issue, since in the case here having IPv6 disabled system-wise wouldn't have solved the issue. The problem only was do-ip6: yes
in Unbound setting, causing it to attempt binding to the respective IPv6 TCP port.
However, it makes much sense to disable IPv6 when you connect to an IPv4-only VPN, else otherwise IPv6 leaks are likely, i.e. the system bypassing the VPN for connections to every host which does have an AAAA record, as IPv6 is usually preferred, when available.
Details:
Linux DietPi 5.15.32-v8+ #1538 SMP PREEMPT Thu Mar 31 19:40:39 BST 2022 aarch64 GNU/Linux
systemctl restart unbound
Steps to reproduce:
Expected behaviour:
Actual behaviour:
Extra details:
Additional logs:
Systemctl status unbound.service log