[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