From owner-freebsd-net@freebsd.org Mon Nov 20 13:23:25 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 6EDA4DEB998 for ; Mon, 20 Nov 2017 13:23:25 +0000 (UTC) (envelope-from agapon@gmail.com) Received: from mail-lf0-f53.google.com (mail-lf0-f53.google.com [209.85.215.53]) (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 EE6C37DDF4 for ; Mon, 20 Nov 2017 13:23:24 +0000 (UTC) (envelope-from agapon@gmail.com) Received: by mail-lf0-f53.google.com with SMTP id g35so10028882lfi.13 for ; Mon, 20 Nov 2017 05:23:24 -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=W5FnknpM2Kic2uU68MwAIgcxgQ7C2E+arjPeqJDvOBA=; b=VQ0Ttsv9EGhFwYweH1aLlGNg+iw4iqnyPtuZYeRgu3K2pIqZm9GY3tFyUKlxL7+Wm+ /iqWdH536dK2SUomhKMBsV3sKLot2khjnQ8lmOF9U34BEa7t4R9rC7SB1/WMHt3O1lGX by9o0eyfWXyeceYKux1Wf9woIaTJrMJLCOZw3GVFdEpZ8WRtfYClA58TYGZAJmbunK5r 0+9OuObqzq1lTEQPuY/0A+4aB4DRUJswRyIFX+bTF/zUXx+rL69lZ8KHLEb8TyuMHbWD /0giKijbLwkJD9zJr7QmpGpihX3bJ+X/leeBX+MiZdfS6j6cE0h7+GmS6FTTe1Y8KNe6 1tKw== X-Gm-Message-State: AJaThX5a2RDZJYoShjEx3iS7lPvft7M3YLsxjGra1ufjEHZQNNHEffRu hvdPEXinMhjwUtN1P+Sxr0rMUEkK X-Google-Smtp-Source: AGs4zMa4Pb1NkKgWJcsVUS9prAkM3KO5TtQ4QI7RUHfwi7mlN2ScTVZ92jEGq5ij9MQp5psw7Nv2FQ== X-Received: by 10.46.27.24 with SMTP id b24mr4352629ljb.54.1511184196932; Mon, 20 Nov 2017 05:23:16 -0800 (PST) Received: from [192.168.0.88] (east.meadow.volia.net. [93.72.151.96]) by smtp.googlemail.com with ESMTPSA id 39sm2601021ljb.49.2017.11.20.05.23.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Nov 2017 05:23:16 -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> From: Andriy Gapon Message-ID: <8a098542-9f04-3a41-76f1-e463e3e89c99@FreeBSD.org> Date: Mon, 20 Nov 2017 15:23:14 +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: <86a7zq8er7.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 13:23:25 -0000 On 13/11/2017 15:55, Dag-Erling Smørgrav wrote: > Andriy Gapon writes: >> First, there is now an automatically generated /etc/resolvconf.conf. >> It has the following comment: >> # This file was generated by local-unbound-setup. >> # Modifications will be overwritten. >> Is that comment really true? >> 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? If yes, then this is much less scary then the unconditional warning in the file. >> Next. The auto-generated resolvconf.conf has this trick to prevent modifications >> of resolv.conf: resolv_conf="/dev/null" >> The trick works but it causes some small noise when resolvconf is run, like >> cannot copy /dev/null to /dev/null.bak. >> 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. The details are in my original email. I never tried to suggest that we should let resolvconf overwrite resolv.conf. > 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). >> unbound: [7457:0] error: cannot chdir to directory: (No such file or directory) > > This error is emitted by the configuration parser when it encounters the > "directory" directive in the "server" section and fails to chdir to the > specified directory, but there should be a name there. Can you do: > > # service local_unbound stop > # mv /var/unbound /var/unbound.orig > # mtree -deU -f /etc/mtree/BSD.var.dist > # service local_unbound setup > # diff -ru /var/unbound.orig /var/unbound > > and tell me if there are any differences? 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. -- Andriy Gapon