Date: Mon, 20 Nov 2017 17:14:46 +0200 From: Andriy Gapon <avg@FreeBSD.org> To: =?UTF-8?Q?Dag-Erling_Sm=c3=b8rgrav?= <des@des.no> Cc: freebsd-net@FreeBSD.org Subject: Re: local_unbound, resolvconf, vpn Message-ID: <37f97bc5-5187-2700-5811-a9cf173eeb10@FreeBSD.org> In-Reply-To: <86y3n16mez.fsf@desk.des.no> References: <5689438f-6734-6b57-b700-d70ee2b7578a@FreeBSD.org> <86a7zq8er7.fsf@desk.des.no> <8a098542-9f04-3a41-76f1-e463e3e89c99@FreeBSD.org> <86y3n16mez.fsf@desk.des.no>
next in thread | previous in thread | raw e-mail | index | archive | help
On 20/11/2017 16:43, Dag-Erling Smørgrav wrote:
> Andriy Gapon <avg@FreeBSD.org> writes:
>> Dag-Erling Smørgrav <des@des.no> writes:
>>> Andriy Gapon <avg@FreeBSD.org> writes:
>>>> What and when is going to overwrite my modifications?
>>> service local_unbound setup
>> So, this is not going to happen automatically (after the initial setup) ?
>> I have to manually run that command?
>
> Currently, yes, but we will sometimes recommend that users run it after
> an upgrade or patch, and I may at some point change the rc script to run
> setup every time you start or restart the service.
Okay.
Maybe it would be possible to allow the auto-generated configuration and the
manual customizations to co-exists somehow. Like bracketing the auto-generated
lines with some delimiters. Or providing a base file that would get merged into
the generated file.
It would be inconvenient if I am unable to customize the file.
I think that I mentioned 'private_interfaces' already.
>>>> I think that a nicer solution is to just set name_servers=127.0.0.1:
>>> No, if we let resolvconf overwrite resolv.conf then we lose "options
>>> edns0".
>> There seems to be a small misunderstanding. The point I was trying to
>> make is that resolvconf would NOT overwrite resolv.conf if it's
>> configured the way I suggested.
>
> It will.
You are right. I see what happens here... resolvconf generates a new file that
looks very similar to the original file, but it's still a new file.
I have resolv_conf_options="edns0" in resolvconf.conf, so I don't lose the option.
So, I am not sure which way is better.
On the one hand, having unmodified resolv.conf is safer.
On the other hand, I get the search list updated when I connect to a vpn and
it's also nice.
>>> What it boils down to is that resolvconf is a piece of shit and the
>>> only way to get it to do what we want would be to write a special
>>> backend for the local_unbound case (see /libexec/resolvconf).
>> Well, I do not see why... We already configure resolvconf to not
>> touch resolv.conf. And resolvconf already has a backend for unbound,
>> it is able to manage the local_unbound configuration quite reasonably
>> (from my experience).
>
> Yes, we use that to maintain forward.conf.
>
> But please believe me when I say that I have spent a *lot* of time with
> resolvconf and its various backends and I am neither joking nor
> exaggerating when I call it a piece of shit.
I see.
And thank you for all the work that you have done on unbound and its integration.
>> Alexander Zagrebin already explained what's going on here.
>> local_unbound setup produces this configuration:
>> chroot: /var/unbound
>> directory: /var/unbound
>>
>> And with it unbound apparently tries to chdir to "" after chrooting to
>> /var/unbound. That is, it removes $chroot from $directory and chdir-s
>> to the result. Changing directory to /var/unbound/ makes the
>> complaint go away.
>
> I understand, and it's been fixed upstream:
That's cool!
> Index: util/configparser.y
> ===================================================================
> --- util/configparser.y (revision 3975)
> +++ util/configparser.y (revision 3976)
> @@ -585,9 +585,11 @@
> strncmp(d, cfg_parser->chroot, strlen(
> cfg_parser->chroot)) == 0)
> d += strlen(cfg_parser->chroot);
> - if(chdir(d))
> + if(d[0]) {
> + if(chdir(d))
> log_err("cannot chdir to directory: %s (%s)",
> d, strerror(errno));
> + }
> }
> }
> ;
>
> but I am unable to reproduce the issue on 11.1.
I am on head.
Did you do the import of unbound 1.5.10 before or after 11.1?
It seems that the chdir code was not present in the earlier version that we had.
--
Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?37f97bc5-5187-2700-5811-a9cf173eeb10>