Get rid of "option dhcpscript '/etc/resolver/dhcp_host_domain_ng.py'"

dns

#1

After each reboot no clients getting IPv4 addresses anymore.

I have to connect to TO and delete in “/etc/config/dhcp” following line:
option dhcpscript ‘/etc/resolver/dhcp_host_domain_ng.py’

After restart of dnsmasq everything is working again. After next reboot, this option comes back.

How can I get rid of this option permanently?


#2

The variable in /etc/config/dhcp is set in /etc/init.d/resolver

set_dhcp_script() {
    uci_set dhcp "@dnsmasq[0]" dhcpscript "$DHCP_SCRIPT"
    uci_commit dhcp
}

It’s also turned on in /etc/config/kresd if dynamic domains is turned on. It’s not turned on for me, but it’s already been set permanently on in resolver

        if [ "$DYNAMIC_DOMAINS" = "1" ]; then
            echo "Enable dhcp script"
            config_foreach set_dnsmasq_dhcp_script dnsmasq "$DHCP_SCRIPT"
            #reload dhcp config with script param
            /etc/init.d/dnsmasq reload
    fi

I don’t have the patience to figure out what it’s supposed to do exactly, but I am guessing it’s supposed to do for kresd/unbound what dnsmasq does automatically.

So, it would really be best if, instead of automatically enabling it every time without choice, there was some way to turn it off.

[EDIT]
If I comment out

DHCP_SCRIPT=/etc/resolver/dhcp_host_domain_ng.py

in /etc/init.d/resolver makes the entry in /etc/config/dhcp go away after I restart resolver (/etc/init.d/resolver restart). I then had to restart dnsmasq (/etc/init.d/dnsmasq restart).


#3

thats pretty nasty shit. I didnt notice this renewal before.

I believe easiest way is erase /etc/resolver/dhcp_host_domain_ng.py content. (no fiddling with config of kresd/resolver).

This is the first time, when Omnia overrides MY configuration by own. Until now, disabling opkg to overwrite config files was fine and work very well…


#4

AFAIK this should be fixed in next minor release of TurrisOS - 3.8.5, which should be really soon.


#5

I tried version from github, but still got occasionally errors:

> y[]: Refresh kresd leases
> 2017-10-21 06:24:29 debug dnsmasq-script[30137]: Add_lease, hostname check failed
> 2017-10-21 06:24:29 debug dnsmasq-script[2525]: Last message 'Add_lease, hostname ' repeated 1 times, suppressed by syslog-ng on Doma
> 2017-10-21 06:24:29 debug dnsmasq-script[30137]: DHCP add new hostname [jirka_tablet,10.0.6.222]
> 2017-10-21 06:24:29 debug dnsmasq-script[30137]: __call_kresd hints.config('/tmp/dhcp.empty')
> 2017-10-21 06:24:29 debug dnsmasq-script[30137]: ret >
> 2017-10-21 06:24:29 debug dnsmasq-script[30137]: __call_kresd hints.add_hosts('/tmp/kresd/hints.tmp')
> 2017-10-21 06:24:29 debug dnsmasq-script[30137]: ret >
> 2017-10-21 06:24:29 debug dnsmasq-script[30137]: Refresh kresd leases

Anyway, I really dont want to have log spammed with those “debug” messages. I dont have DNS for local hostnames enabled in Foris, I just use static IPs for .lan devices, and hostname resolving works as it should (quite a long time, didnt remember version of turris, but it works without dnsmasq/kresd port fiddling) without this annoying python(!) script… Both for obyvak.lan and obyvak, for example.


#6

btw, I see that watchdog restarts resolver each 10 min? Dont know when this starts, but I am sure that resolver is OK and doesnt need to restart all the time…

I thing watchdog has a serious bug, because detection resolver on default Omnia configuration is broken.

/etc/init.d/resolver generates wrong resolver.pid file. Mine always contains more numbers, because running process:

/etc/init.d/resolver restart

meanwhile running resolver restart…

root@Doma:~# pidof kresd
11245 11238
root@Doma:~# ps | grep 11238
11238 root 1228 S {kresd} /bin/sh /etc/rc.common /etc/init.d/kresd start
11255 root 1088 R grep 11238

… resolver script ends

root@Doma:~# pidof kresd
11245

11245 - correct PID, which should be on resolver.pid
11238 - bogus PID form script, which I assume broke watchdog functionality

Unfortunatelly, pidof @Omnia doesnt have -s option, but seriously, this is very bad design…


/etc/init.d/resolver generates wrong resolver.pid file (Kresd)
#7

Meanwhile I am on 3.8.6.

The situation is the same as before. On each reboot dnsmasq does not start because of “option dhcpscript ‘/etc/resolver/dhcp_host_domain_ng.py’” in /etc/config/dhcp. And so long dnsmasq is not running, no ipv4 adresses are distributed to any device (lan and wlan). Very annoying!

I don’t want to fiddle in init.d files to fix this.

So am I right, that dnsmasq is the preferred service to distribute ipv4 adresses? If yes, why it does not start?

Formerly I did this adaption to my router, so that dnsmasq resolves local host names (Dnsmasq .lan domain while still using knot resolver). But as I understand all my adaptions should be overwritten by new opkg versions of knot-resolver.

So how can I get back to TO which can (automatically) be rebooted and ALL devices are getting network connections?

Regards
Thomas


#8

I’m not sure. I did those changes too, but I’ve not had any issues with dnsmasq running. Perhaps there is a different issue with dnsmasq.

I realized I didn’t do my edits after the last update and the DHCP script was uncommented. As a result, I found that there are two running copies of dnsmasq:

 3286 nobody    1312 S    /usr/sbin/dnsmasq -C /var/etc/dnsmasq.conf -k -x /var/run/dnsmasq/dnsmasq.pid
 3291 root      1304 S    /usr/sbin/dnsmasq -C /var/etc/dnsmasq.conf -k -x /var/run/dnsmasq/dnsmasq.pid

It appears that /etc/resolver/dhcp_host_domain_ng.py starts dnsmasq as user root, where the regular dnsmasq startup script uses nobody, which is more secure.

Do you save your logs anywhere? That might give you an indication what’s going on. Perhaps the dnsmasq init script, since it should start dnsmasq as nobody, is having trouble reading one of the config files.

For better or worse, due to all the customizations I’ve made, I now have about 10-15 items I check every time there’s an update. I just added the commenting out the DHCP_SCRIPT to the list.

James


#9

After deleting “option dhcpscript ‘/etc/resolver/dhcp_host_domain_ng.py’” and manually starting dnsmasq as root I have also two dnsmasq processes:

3225 nobody 920 S /usr/sbin/dnsmasq -C /var/etc/dnsmasq.conf -k -x /var/run/dnsmasq/dnsmasq.pid
3227 root 912 S /usr/sbin/dnsmasq -C /var/etc/dnsmasq.conf -k -x /var/run/dnsmasq/dnsmasq.pid

I found in /var/log/messages following error:

2017-11-24T17:04:59+01:00 crit dnsmasq[3078]: illegal repeated keyword at line 11 of /var/etc/dnsmasq.conf
2017-11-24T17:04:59+01:00 crit dnsmasq[3078]: FAILED to start up
2017-11-24T17:04:59+01:00 info procd[]: Instance dnsmasq::instance1 s in a crash loop 6 crashes, 0 seconds since last crash

So here is the content of this file, numbered the lines:

1 # auto-generated config file from /etc/config/dhcp
2 conf-file=/etc/dnsmasq.conf
3 dhcp-authoritative
4 domain-needed
5 localise-queries
6 read-ethers
7 bogus-priv
8 expand-hosts
9 enable-tftp
10 local-service
11 dhcp-script=/etc/resolver/dhcp_host_domain_ng.py
12 port=0

So at the end, it’s the same as before.

Hey folks @Turris, what’s wrong with this line?


#10

Right. /etc/init.d/dnsmasq starts dnsmasq as nobody. So, if you started dnsmasq by hand as root, then you’ll have one running as root as well.


#11

Sorry, ‘starting manually’ was mistakable. I’m starting it with ‘/etc/init.d/dnsmasq start’. So it should be the same like on a reboot.