On Sun, 25 Oct 2015 13:58:03 +0100
Sören Tempel <soeren+git@soeren-tempel.net> wrote:
> The file gets outdated from time to time and on package upgrades it> a root.hints.apk-new file is created if the cron was invocate before the> package upgrade.
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?
We may want update the root.hints we ship once in a while though.
-nc
---
Unsubscribe: alpine-aports+unsubscribe@lists.alpinelinux.org
Help: alpine-aports+help@lists.alpinelinux.org
---
On Sun, 25 Oct 2015 13:58:04 +0100
Sören Tempel <soeren+git@soeren-tempel.net> wrote:
> No need to fetch the root.hints file twice since the ftp servers should> never distribute invalid root hints. Also make the ftp host and> destination path configurable using an environment variable.
NACK.
the existing script will not download it twice, it will 'exit 0' on
first successful download, but if the first download will fail for any
reason, then it will try the next ftp server.
It will also make sure it was actually able to complete the download
before installing it for production.
With your simplification, if for some reason wget manage to open the
out file, but fails to complete the download, it may end up replacing
the roots.hints with an empty file. You will not get a second chance to
download (or resolve) anything after that.
(Yeah, i have experience it. not fun to lose dns resolution when things
did not go as expected when cron job was run)
We must never end up without an empty root.hints, regardless of what
problem we might run into.
One thing we might what do to improve the script though, is to also try
download from http, in case ftp is blocked.
-nc
> ---> main/unbound/APKBUILD | 8 ++++----> main/unbound/update-unbound-root-hints | 31 ++++---------------------------> 2 files changed, 8 insertions(+), 31 deletions(-)> > diff --git a/main/unbound/APKBUILD b/main/unbound/APKBUILD> index 3823827..7734f3a 100644> --- a/main/unbound/APKBUILD> +++ b/main/unbound/APKBUILD> @@ -2,7 +2,7 @@> # Maintainer: Natanael Copa <ncopa@alpinelinux.org>> pkgname=unbound> pkgver=1.5.6> -pkgrel=1> +pkgrel=2> pkgdesc="Unbound is a validating, recursive, and caching DNS resolver"> pkgusers="unbound"> pkggroups="unbound"> @@ -93,18 +93,18 @@ migrate() {> md5sums="691a34abd8e9257dd65b70f28326c1f0 unbound-1.5.6.tar.gz> 32fe2914a2723142d3eae9ea556872d3 conf.patch> deb0a18f2250caa53750ee2cecac71e9 swig.patch> -c1c71cd0e7f9630536a2abf2513c675d update-unbound-root-hints> +26461c76ac3295772087e7ad4469dc89 update-unbound-root-hints> 5340681e5ec1a1fd47a0de27f5c03c21 migrate-dnscache-to-unbound> b98eded68339fc605ec7e6cbb50e5aa3 unbound.initd"> sha256sums="ad3823f5895f59da9e408ea273fcf81d8a76914c18864fba256d7f140b83e404 unbound-1.5.6.tar.gz> 48bedb743eda892f82adc8b4ce2e4f5ad216f1ab50d432aef768377edc98165c conf.patch> d131e19129744f7014167d8701cb39c8358269a89b317b8a74dacfd267e1f516 swig.patch> -0db3ca197b62901fab984cb2559925adbf3307ccd1dca3e1dd69cd1642ff0a36 update-unbound-root-hints> +b3616d7e7e022ff8a5e012b3b2ade2266515083e17569a1937a0bde81b75c006 update-unbound-root-hints> 582851b4017044d8642c42c5df09b27494c963e1eebb8be3373b2dbd168d0ac0 migrate-dnscache-to-unbound> d9997000449179dc16f5084bf061453faf09094f843acb1d163757f8000c0cd7 unbound.initd"> sha512sums="2477e3f00b8f5a3a4661ff20b0bc0d1d56c8a65cc6ab9f1308ae86f41c67a998af68d3ac5ba6c9c22a25a251f0410eaf9fee82911bcb3a3e82ffb6383e28dcf7 unbound-1.5.6.tar.gz> 2214882954ed813c564a34cbf433240814f1cc03e62b7aa007d054406d17fa0359514400afe53b9cb0445d25a29ccf9bf27c5974901d30bbfb2bfaf5e755da2b conf.patch> 7d2666363be7156b26fd857459492f6e78fbc24bd6923dd51477e09df938d8c617035e4aa8bf91ffcde384e2dff8225eced14d7aaa7690e3a95b34c5f21eaf7d swig.patch> -0f80b507a8f71b0c00729501d861657ce91a57024cd1963c150d0630c71eccceba370d6e732ff39bb807713672550d87a8c8ecdb9fce6b8b4386c12689603700 update-unbound-root-hints> +ac0f8799026e5024ef5071657ef704bd64922454a9fabe37da524faaea50fe8aa3ff3acfa892d32674bedd97e53c88a483acc5c8dfffd526819015825a635924 update-unbound-root-hints> b26a13c1c88da9611a65705dc59f7233c5e0f6aced0d7d66c18536a969a2de627ca5d4bb55eedd81f2f040fa11bde48eaaeca2850f376e72e7a531678a259131 migrate-dnscache-to-unbound> 540e7a11fa5421e2d103c42d69faf1ba005adcadfac2f65091795a2f00e5b5acd1436b4d2adfe2bb0fdfcbfb44d0967d6bce87620c618549fcd7e32019040f29 unbound.initd"> diff --git a/main/unbound/update-unbound-root-hints b/main/unbound/update-unbound-root-hints> index ee127de..238afc1 100644> --- a/main/unbound/update-unbound-root-hints> +++ b/main/unbound/update-unbound-root-hints> @@ -1,30 +1,7 @@> #!/bin/sh> > -check_format() {> - # check that we have some ipv4 addresses and some '.' hints> - egrep -q '[0-9]+\.[0-9]+\.[0-9]+\.[0-9]' "$1" \> - && egrep -q '^\.[[:space:]]+' "$1"> -}> +: ${UNBOUND_ROOTHINTS:="ftp.internic.net/domain/named.cache"}> +: ${UNBOUND_HINTSDEST:="/etc/unbound/root.hints"}> > -ftphosts="FTP.INTERNIC.NET RS.INTERNIC.NET"> -roothints=domain/named.cache> -unbound_dir=/etc/unbound> -outfile=$unbound_dir/root.hints> -> -if [ "$1" = "--verify" ]; then> - if check_format $outfile; then> - echo "$outfile: ok"> - exit 0> - else> - echo "$outfile: failed"> - exit 1> - fi> -fi> -> -for host in $ftphosts; do> - url=ftp://$host/$roothints> - if wget -q -O ${outfile}.new $url && check_format ${outfile}.new; then> - mv ${outfile}.new $outfile && exit 0> - fi> -done> -exit 1> +wget -q -O "${UNBOUND_HINTSDEST}" "${UNBOUND_ROOTHINTS}"> +exit 0
---
Unsubscribe: alpine-aports+unsubscribe@lists.alpinelinux.org
Help: alpine-aports+help@lists.alpinelinux.org
---
Re: [alpine-aports] [PATCH 4/5] main/unbound: invoke cron on post-install
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?
Totally get your point, but how do you install unbound if you don't know
what servers to ask for the .apk file? 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...
Sören.
---
Unsubscribe: alpine-aports+unsubscribe@lists.alpinelinux.org
Help: alpine-aports+help@lists.alpinelinux.org
---
Re: [alpine-aports] [PATCH 2/5] main/unbound: don't install root.hints by default
On Mon, 26 Oct 2015 16:37:15 +0100
Sören 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?> > Totally get your point, but how do you install unbound if you don't know> what servers to ask for the .apk file?
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
---