From owner-freebsd-net@freebsd.org Mon Nov 20 15:14:51 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 90542DEE2CC for ; Mon, 20 Nov 2017 15:14:51 +0000 (UTC) (envelope-from agapon@gmail.com) Received: from mail-lf0-f44.google.com (mail-lf0-f44.google.com [209.85.215.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 204781DF3 for ; Mon, 20 Nov 2017 15:14:50 +0000 (UTC) (envelope-from agapon@gmail.com) Received: by mail-lf0-f44.google.com with SMTP id f134so10475537lfg.8 for ; Mon, 20 Nov 2017 07:14:50 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=8Kd46Cj/7l8rq4j0UgVmz4cMkDkEua8RAu8COVVGpcs=; b=cGucS0F9UO/f/LilYBGoh+MimKLX76WHF7wUZ1Q7llM1fRdKym5LYvaKz9iJx8CdfD ii+f4lZPUQZD5BC6sxfZsqNnktUIr04OJl4dAqOermPaW9tK4vq8uMG6GJvpIoOc/K0J RHqQh3M3R1LJp667agHhi9eqRel57V6MrFWxW1Ye3KjNfG4Naqo6lTuMML/e/2OmzgWM oA+WqZTMa5TYM/5njxoZiX43DHg7/oUlFFH0rQfQs8XAvn5UJ1rN/ZzXdYx2gvbHASun cQvC/20haFZT+dJakoyakFnQ7UeHQDpEESziy6BXeFZjBPzEerDDepd7UB0ZbFxP9TyT gMlQ== X-Gm-Message-State: AJaThX4qwEFth9dTvWRZ2XAVHwrt/4QfE5BYfqdYqrjfuuwfhxhnxMDf /7iZw55gSrbxeozkzkRktYI9+Ygl X-Google-Smtp-Source: AGs4zMbbHUlS6KDhZd4MflQSqaQ9wt+pghGeTVOtBGEi7rYv3YkpoGolvwruHeCFeKSHSNiVLkiAgQ== X-Received: by 10.46.77.26 with SMTP id a26mr5219952ljb.155.1511190888295; Mon, 20 Nov 2017 07:14:48 -0800 (PST) Received: from [192.168.0.88] (east.meadow.volia.net. [93.72.151.96]) by smtp.googlemail.com with ESMTPSA id a69sm1450358ljf.54.2017.11.20.07.14.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Nov 2017 07:14:47 -0800 (PST) Subject: Re: local_unbound, resolvconf, vpn To: =?UTF-8?Q?Dag-Erling_Sm=c3=b8rgrav?= Cc: freebsd-net@FreeBSD.org 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> From: Andriy Gapon Message-ID: <37f97bc5-5187-2700-5811-a9cf173eeb10@FreeBSD.org> Date: Mon, 20 Nov 2017 17:14:46 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <86y3n16mez.fsf@desk.des.no> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Nov 2017 15:14:51 -0000 On 20/11/2017 16:43, Dag-Erling Smørgrav wrote: > Andriy Gapon writes: >> Dag-Erling Smørgrav writes: >>> Andriy Gapon 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