[LEDE-DEV] [PATCH] dnsmasq: write resolv.conf also when noresolv = 1

Eric Luehrsen ericluehrsen at hotmail.com
Mon Jun 5 20:44:57 PDT 2017


On 06/05/2017 06:48 AM, Paul Oranje wrote
 >The current guard (resolvsym) is now determined with:
 >     if [ ! -x /usr/sbin/dnsmasq -o ! -x /etc/init.d/dnsmasq ] ; then
 >         resolvsym=1
 >     else
 >         /etc/init.d/dnsmasq enabled || resolvsym=1
 >     fi
 >
 > This assumes that dnsmasq when enabled, in whatever way, will handle 
/tmp/resolv.conf.
 > A correct solution would be to handle /tmp/resolv.conf in the unbound 
init script whenever unbound will listen on 127.0.0.1#53. Then 
/tmp/resolv.conf is handled whenever either dnsmasq or unbound listens 
on 127.0.0.1#53.
 > Agree ?
 >
 > The unbound init routines **should** handle /tmp/resolv in this case, 
but currently do not (when dnsmasq is the dhcp_link).
 > Proposed code:
 >
 >     unbound_ismain() # true=0, false=1.
 >     {
 >         if [ "$UNBOUND_D_DHCP_LINK" = "none" ] \
 >         && /etc/init.d/dnsmasq enabled && [ -x /usr/sbin/dnsmasq -a 
-x /etc/init.d/dnsmasq ] ; then
 >             return 1
 >         fi
 >
 >         # unbound is designated to listen on 127.0.0.1#53.
 >         return 0
 >     }
 >

The Unbound scripts load all the configuration into script global 
variables first. It should make this kind of thing much easier than 
that. If Unbound owns #53 and dnsmasq doesn't (by UCI), then it can 
manage resolv.conf. After determining if dnsmasq is even active (keep 
current if-else), then make sure there is no UCI conflict (if resolvsym 
and owns #53). If someone is just beginning to reconfigure UCI after an 
install, then Unbound needs to defer to the default while in conflict. 
Something like that I think might work, and not foul a system during a 
package load and configure.





More information about the Lede-dev mailing list