Date: Mon, 26 Oct 2015 20:54:45 +0100
From: Natanael Copa <ncopa@alpinelinux.org>
To: =?UTF-8?B?U8O2cmVu?= Tempel <soeren@soeren-tempel.net>
Cc: alpine-aports@lists.alpinelinux.org
Subject: Re: [alpine-aports] [PATCH 2/5] main/unbound: don't install
 root.hints by default
Message-ID: <20151026205445.0fa43584@ncopa-laptop>
In-Reply-To: <20151026153715.GA4661@calcium.lan>
References: <1445777886-24422-1-git-send-email-soeren+git@soeren-tempel.net>
	<1445777886-24422-2-git-send-email-soeren+git@soeren-tempel.net>
	<20151026094554.6423236b@ncopa-desktop.alpinelinux.org>
	<20151026153715.GA4661@calcium.lan>
Precedence: list
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Mon, 26 Oct 2015 16:37:15 +0100
S=C3=B6ren Tempel <soeren@soeren-tempel.net> wrote:

> On 26.10.15, Natanael Copa wrote:
> > I am sceptic to this. If your only resolver is unbound, how can you
> > then download the root.hints if you don't know what root servers to ask?
>=20
> Totally get your point, but how do you install unbound if you don't know
> what servers to ask for the .apk file?=20

You use the unbound package shipped on the iso.

> Nonetheless I believe that it
> would be ok to ship the the root.hints file with the package but we
> don't need ship both the cron and the root.hints file since this will
> create .apk-new files for the file on package upgrade.I think we should
> decide on one of those options for shipping the file...

What is the problem with .apk-new?

I have already explained the problem with excluding it from .apk, so
that is not an option.

The problem with excluding the cron is that the root.hints will not be
kept up-to-date, and we end up need update the unbound apk every time
there is a change in the DNS root hints. We will then need to set up
some script that monitors changes in root dns list and notifies us so
we can update the package each time. The end users will have to
download the entire package each time that happens, even if the
majority of the update (the binary itself) in unmodified.

Now, we have another option, we could move the root.hints to some place
under /var (where it belongs technically), but then will diskless users
need to make sure that this is included in the 'lbu commit'. They would
also need to edit their config to point to new location. (running
update-conf will compare the .apk-new with exisitng config and give
some help in merge in config changes like this) Now, I have 100+ boxes
running that depends on unbound for proper DNS resolution.

Can you please explain for me what the problem with .apk-new is that
would justify the extra work for me to update the config for 100+
boxes, and justify that I break DNS resolution for one of those
boxes. I would pretty much prefer to spend time on getting v3.3 out, or
to try catch up on the long backlog of pending security fixes for the
stable branches.

I suspect the "problem" with .apk-new is small in comparison.

Besides, you can run update-conf and get a nice diff of .apk-new
changes and an interactive option to use/edit/purge the .apk-new.

-nc


---
Unsubscribe:  alpine-aports+unsubscribe@lists.alpinelinux.org
Help:         alpine-aports+help@lists.alpinelinux.org
---