Re: Debian/Ubuntu: Why was the service renamed from bind9 to named?

2020-07-22 Thread Michael De Roover
On 7/23/20 7:19 AM, Ted Mittelstaedt wrote: Well for starters there is no way for ME to validate that the compiled software you built for me isn't busy running your Doom network server behind my back.  (do people still even run Doom servers?) People would find out when an unnecessary service i

Re: Debian/Ubuntu: Why was the service renamed from bind9 to named?

2020-07-22 Thread Ted Mittelstaedt
On 7/22/2020 9:59 PM, Michael De Roover wrote: On 7/23/20 6:28 AM, Ted Mittelstaedt wrote: Linux is 10 times worse because they aren't even including the c compiler or development tools anymore. Every distribution I've laid my hands on so far has GCC packages and most development packages a

Re: Debian/Ubuntu: Why was the service renamed from bind9 to named?

2020-07-22 Thread Michael De Roover
On 7/23/20 6:28 AM, Ted Mittelstaedt wrote: Linux is 10 times worse because they aren't even including the c compiler or development tools anymore. Every distribution I've laid my hands on so far has GCC packages and most development packages affixed with either -dev or -devel (most of the ti

Re: Debian/Ubuntu: Why was the service renamed from bind9 to named?

2020-07-22 Thread Ted Mittelstaedt
On 7/20/2020 4:05 PM, Mark Andrews wrote: Distributions also need to look at their own practices. They ask us to supply long term support but do not actually integrate the maintenance releases but instead cherry-pick just the security fixes. Maintenance is not just security fixes. That me

Re: /etc/bind.keys in a chrooted environment

2020-07-22 Thread Evan Hunt
On Wed, Jul 22, 2020 at 03:30:28PM +0200, Josef Moellers wrote: > If /etc/bind.keys contains some additional keys, this will not work ;-) I see the question has already been answered, but I thought it might be worth mentioning that /etc/bind.keys can *only* be used for the root zone; any other dom

RHEL, Centos, Fedora rpm 9.16.5

2020-07-22 Thread Carl Byington via bind-users
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 https://www.five-ten-sg.com/mapper/bind contains links to the source rpms, and build instructions. -BEGIN PGP SIGNATURE- iHMEAREKADMWIQSuFMepaSkjWnTxQ5QvqPuaKVMWwQUCXxiM4BUcY2FybEBmaXZl LXRlbi1zZy5jb20ACgkQL6j7milTFsFMXACfRQPFj8FFws3T9jMtu

Re: /etc/bind.keys in a chrooted environment

2020-07-22 Thread Josef Moellers
On 22.07.20 17:05, Anand Buddhdev wrote: > On 22/07/2020 16:51, Josef Moellers wrote: > >> It turns out that it is mainly the warning the partner is irritade about. >> >> So, let me put the question the other way round: what would happen if we >> *always* copied /etc/bind.keys to the chroot enviro

Re: /etc/bind.keys in a chrooted environment

2020-07-22 Thread Tony Finch
Anand Buddhdev wrote: > On 22/07/2020 15:06, Josef Moellers wrote: > > > named complains about the missing file /etc/bind.keys if run chrooted: > > unable to open '/etc/bind.keys' using built-in keys > > > > What is the preferred way around this? Add "/etc/bind-keys" to > > NAMED_CONF_INCLUDE_FILE

Re: /etc/bind.keys in a chrooted environment

2020-07-22 Thread tale via bind-users
On Wed, Jul 22, 2020 at 11:05 AM Anand Buddhdev wrote: > There is no harm in copying the file into the chroot. It will get rid of > the warning. With the caveat that you have to be sure that if you keep the original copy outside of the chroot, you have to be sure updates get reflected inside the

Re: /etc/bind.keys in a chrooted environment

2020-07-22 Thread Anand Buddhdev
On 22/07/2020 16:51, Josef Moellers wrote: It turns out that it is mainly the warning the partner is irritade about. So, let me put the question the other way round: what would happen if we *always* copied /etc/bind.keys to the chroot environment? If there would be no harm, I could easily add t

Re: /etc/bind.keys in a chrooted environment

2020-07-22 Thread Josef Moellers
On 22.07.20 16:41, Anand Buddhdev wrote: > On 22/07/2020 15:30, Josef Moellers wrote: > >>> Or just ignore the warning, and let BIND use its built-in keys. >> >> If /etc/bind.keys contains some additional keys, this will not work ;-) > > Sure, but what additional keys do you expect this file to c

Re: /etc/bind.keys in a chrooted environment

2020-07-22 Thread Anand Buddhdev
On 22/07/2020 15:30, Josef Moellers wrote: Or just ignore the warning, and let BIND use its built-in keys. If /etc/bind.keys contains some additional keys, this will not work ;-) Sure, but what additional keys do you expect this file to contain? Are you serving an alternate signed root zone

Re: /etc/bind.keys in a chrooted environment

2020-07-22 Thread Josef Moellers
On 22.07.20 15:28, Anand Buddhdev wrote: > On 22/07/2020 15:06, Josef Moellers wrote: > > Hi Josef, > >> named complains about the missing file /etc/bind.keys if run chrooted: >> unable to open '/etc/bind.keys' using built-in keys >> >> What is the preferred way around this? Add "/etc/bind-keys"

Re: /etc/bind.keys in a chrooted environment

2020-07-22 Thread Anand Buddhdev
On 22/07/2020 15:06, Josef Moellers wrote: Hi Josef, named complains about the missing file /etc/bind.keys if run chrooted: unable to open '/etc/bind.keys' using built-in keys What is the preferred way around this? Add "/etc/bind-keys" to NAMED_CONF_INCLUDE_FILES? Or just ignore the warning,

/etc/bind.keys in a chrooted environment

2020-07-22 Thread Josef Moellers
Hi, named complains about the missing file /etc/bind.keys if run chrooted: unable to open '/etc/bind.keys' using built-in keys What is the preferred way around this? Add "/etc/bind-keys" to NAMED_CONF_INCLUDE_FILES? Thanks, Josef -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5 90409 Nürn