On 2022-01-05 16:10:50 +0100, Vincent Lefevre wrote: > On 2022-01-05 15:56:33 +0100, Andrej Shadura wrote: > I can see: > > zira:~> ll /etc/resolvconf/update.d > total 12 > -rwxr-xr-x 1 root root 4641 2021-12-28 22:36:01 libc* > -rw-r--r-- 1 root root 661 2022-01-05 15:36:36 unbound > > While "libc" is executable, "unbound" is not. This may be the cause > of the bug (the resolvconf(8) man page is not explicit about the > behavior). I'm going to do some tests.
Indeed, this was the cause of the issue. After making unbound executable, I now get: # unbound-control forward 192.168.43.173 192.168.1.1 instead of "off". However, this is broken: 192.168.1.1 shouldn't be there!!! FYI: zira:~> cat /run/resolvconf/interface/NetworkManager nameserver 127.0.0.1 nameserver 192.168.43.173 Where does 192.168.1.1 come from? Perhaps /run/resolvconf/interface/original.resolvconf, which contains # Generated by NetworkManager nameserver 127.0.0.1 nameserver 192.168.1.1 So, in short, there seems to be 2 bugs: 1. One in unbound: /etc/resolvconf/update.d/unbound is not executable. 2. One in resolvconf, which adds an obsolete original.resolvconf in /run/resolvconf/interface (no mention of it in the resolvconf(8) man page). Moreover, the resolvconf(8) man page should be improved about the executable status of file in "/etc/resolvconf/update.d". -- Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
