/etc/bind.keys in a chrooted environment
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ürnberg Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: /etc/bind.keys in a chrooted environment
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, and let BIND use its built-in keys. Regards, Anand ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: /etc/bind.keys in a chrooted environment
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" to >> NAMED_CONF_INCLUDE_FILES? > > 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 ;-) Josef -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5 90409 Nürnberg Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: /etc/bind.keys in a chrooted environment
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? ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: /etc/bind.keys in a chrooted environment
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 contain? Are > you serving an alternate signed root zone? I'm not really sure what the partner wants to add, I have the slight feeling that the remark about manually added keys was made by a third person assuming ... 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 that to eg /etc/init.d/named or the systemd service file. But the question now is: does it do any harm? Thanks, Josef -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5 90409 Nürnberg Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: /etc/bind.keys in a chrooted environment
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 that to eg /etc/init.d/named or the systemd service file. But the question now is: does it do any harm? There is no harm in copying the file into the chroot. It will get rid of the warning. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: /etc/bind.keys in a chrooted environment
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 chroot. NAMED_CONF_INCLUDE_FILES mentioned in the OP seems to be a SuSE-ism and I didn't dig into whatever bearing it might have for maintenance of the chroot. -- tale ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: /etc/bind.keys in a chrooted environment
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_FILES? > > Or just ignore the warning, and let BIND use its built-in keys. Yes, I recommend this. Tony. -- f.anthony.n.finchhttp://dotat.at/ Mull of Kintyre to Ardnamurchan Point: Southwest veering west 3 or 4, occasionally 5 at first. Slight or moderate. Occasional rain, fog patches. Moderate or poor, occasionally very poor. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: /etc/bind.keys in a chrooted environment
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 environment? If there would >> be no harm, I could easily add that to eg /etc/init.d/named or the >> systemd service file. But the question now is: does it do any harm? > > There is no harm in copying the file into the chroot. It will get rid of > the warning. Thanks and ... stay healthy! Josef -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5 90409 Nürnberg Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RHEL, Centos, Fedora rpm 9.16.5
-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 LXRlbi1zZy5jb20ACgkQL6j7milTFsFMXACfRQPFj8FFws3T9jMtu8gAyvLbpgsA nAkTIEwuyRmsO1P+EVbuWL3E5nvL =Pvxd -END PGP SIGNATURE- ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: /etc/bind.keys in a chrooted environment
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 domains listed there will be ignored. So, this would already not work. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Debian/Ubuntu: Why was the service renamed from bind9 to named?
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 means that we keep seeing bug reports that need to be diagnosed about bugs we have fixed years ago. That really isn’t a good use of peoples time. Not ours, not the distributions maintainers nor the users time. Is there little wonder that we stop producing bug fixes releases for old version when the distributions don’t use them? Those kinds of bug reports need to be kicked back to the user with a "refer to distro maintainer" But truthfully you are proving my point. The simple fact is that bind will compile WITHOUT using a FreeBSD port. Linux is 10 times worse because they aren't even including the c compiler or development tools anymore. But many "systemadmins" out there think they are Unix admins yet are afraid to compile programs. They will go to the FreeBSD port or the Linux precompiled apt-get stuff. The reason is more and more non-technical people are getting their hands on this stuff. This is a bit like the development of the automobile. When the Model T came out it came with a toolbox and a big book that allowed the owner to completely troubleshoot and fix anything that went wrong with the car. But gradually as more and more people bought cars you had more people who didn't know squat about cars buying them. So Ford stopped shipping the manual and made it an extra cost item. Nowadays Ford and Chevy don't even sell a manual at all anymore. Instead you have to get an alldata subscription to get access to the service manual. And if you stop paying the subscription you have no more manual. But a running shop is always going to be paying a subscription so it's not a problem for them. For the DIYers they can get a 3 day alldatadiy subscription then spend 3 hours printing every page of the manual but maybe 1 out of 10,000 car buyers ever does this. Microsoft ran into this problem and had to split windows into a server and desktop version. Right after that happened "windows admins" who knew the desktop only were fine. But today all the MS server applications have to be controlled via the command line via powershell, plus the server version of the OS is 4 times more expensive and both these things tend to chase away the people who aren't system admin types who are willing to get down and dirty and technical. Linux did this as well although the "server versions" of the distributions are horrendously lacking. FreeBSD really should do this but they don't likely have enough people working on the distro. So they make it so that the non-tech types can use it and expect that the admin types know better. None of these solutions are really solutions. The real solution would be for the users to get more educated. But the majority of people don't really care about an OS they just use it as a platform to run the software that they do care about. Thus creating the means for gigantic DDoS networks since none of them bother patching their OSes. BIND chose the path of servicing the needs of the people who knew what they were doing. Unbound went the other direction and chose the path of servicing the non-technical users. There's more non-techs than educated people so sooner or later paths are going to diverge. It always makes me laugh to read these flame wars from the non-techs who think that just because their simple-and-not-configurable programs work for them on the desktop that they should work on the server and the world should switch to them. Whaah Whaah Whaah the real world is complicated, simplify it for me or I'm gonna have a tantrum. We have one of those dunsels in the White House in the USA right now. The BIND developers should forget about the non-techs and continue servicing the people who know what they are doing and laugh also. Ted ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Debian/Ubuntu: Why was the service renamed from bind9 to named?
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 time). But many "systemadmins" out there think they are Unix admins yet are afraid to compile programs. They will go to the FreeBSD port or the Linux precompiled apt-get stuff. The reason is more and more non-technical people are getting their hands on this stuff. I don't disagree with this but I also think there's more to it than that. For me personally I avoid compiling from source when I can get away with it - not because I can't run make - but simply because binary packages are convenient. Having a package manager take care of updates in the whole system is convenient. Having distribution maintainers that say "okay we are going to go stable, bleeding edge or whatever with the whole project" is useful when they can spend the time looking at the upstream projects, and choose the most fitting software versions and such to suit that goal. And when there's billions of machines running very similar architectures, there is an argument to be made that making every single one of them compile everything from source is rather pointless. Why should every machine in existence be tasked with CPU-intensive compilation workloads when a handful of dedicated compilation servers can do exactly that, and a million times better? -- Met vriendelijke groet / Best regards, Michael De Roover ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Debian/Ubuntu: Why was the service renamed from bind9 to named?
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 affixed with either -dev or -devel (most of the time). But many "systemadmins" out there think they are Unix admins yet are afraid to compile programs. They will go to the FreeBSD port or the Linux precompiled apt-get stuff. The reason is more and more non-technical people are getting their hands on this stuff. I don't disagree with this but I also think there's more to it than that. For me personally I avoid compiling from source when I can get away with it - not because I can't run make - but simply because binary packages are convenient. Having a package manager take care of updates in the whole system is convenient. Having distribution maintainers that say "okay we are going to go stable, bleeding edge or whatever with the whole project" is useful when they can spend the time looking at the upstream projects, and choose the most fitting software versions and such to suit that goal. And when there's billions of machines running very similar architectures, there is an argument to be made that making every single one of them compile everything from source is rather pointless. Why should every machine in existence be tasked with CPU-intensive compilation workloads when a handful of dedicated compilation servers can do exactly that, and a million times better? 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?) You are making an argument that is a desktop argument. That is, the argument goes Those That Know Better Will Do It For You. Also, I have had at least 5 Open Source programs over the years that I found Really Useful to have that the authors decided they wanted to "take commercial" or they had other religious conversions that made them decide to go on a rampage and issue take down notices everywhere they could find their source. One of those for example was when Nasty-Company-Who-Shall-Not-Be-Graced-With-A-Mention decided to start charging for software that created .gif files and the graphics community went on a ballistic rampage jihad and destroyed every scrap of .gif code it could find so as to force users to migrate to .png. I did not wish to migrate to .png so I was very glad that I had saved all the old code, safe from the fires of the religious zealots. Lastly, the way I look at it is when I field a new server, if it cannot recompile it's OS, kernel, make world, and all of it's applications from source, then it's a piece of excrement that I do not want in service. It is also a fact that I have had pre-production servers blow up on "make worlds" In a few cases this was bad ram, in one case the server was returned to the manufacturer under warranty. These are machines that did not display any issues before the OS load. Do not ask me why it was possible to install all the binaries for the OS and have it boot with no problems yet blow chunks/blue screen/abend/take a dive into the toilet/whatever your preferred term for crashing and burning is. I don't generally run FreeBSD or Linux as a desktop OS, BTW so that does affect my view of things. So yes, there is definitely an argument in favor of compiling the stuff at least on a server. Ted ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Debian/Ubuntu: Why was the service renamed from bind9 to named?
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 is started up though, no? Especially with services, you can see those with netstat/ss right away. Additionally, the distribution maintainers are (or at least should be) the ones compiling it. It could be argued that by installing their distribution, there is already a certain level of trust being given to said maintainers. For example I don't trust Manjaro's maintainers, since they screwed up their TLS certificate renewal no less than 3 times. That's complete and utter incompetence on their part. How they didn't already put certbot in a cron job after the first time is beyond me. On the other hand, I have started to get fond of Debian.. though also not entirely. But enough to consider that their packages are probably just fine. I could also verify this by compiling it myself and comparing the result. They publish their downstream source code along with any modifications they made. You are making an argument that is a desktop argument. That is, the argument goes Those That Know Better Will Do It For You. Not quite, rather my goals for the system sufficiently align with those of the distribution I end up going with on this or that system. And on a server I don't like compiling from source for the same reason that I wouldn't install and run a desktop environment on it. I consider it unnecessary cruft. And keeping those packages up-to-date... I forgot to manually update software I built from a git repository more often than I'd like to admit. I also lost count. With my internal BIND servers now running on Alpine (because super lightweight), that blurs the lines a bit. With 9.14.12, they ship an EOL version of BIND. And their stock configuration for it was pretty much unusable anyway. Everything on that was replaced. Compiling from source or sticking with what they provide, perhaps notifying Alpine's maintainers that they should look into it? I don't know. But compiling 9.16 ESV there probably wouldn't be a bad idea. Certainly doable, but not as convenient. Also, I have had at least 5 Open Source programs over the years that I found Really Useful to have that the authors decided they wanted to "take commercial" or they had other religious conversions that made them decide to go on a rampage and issue take down notices everywhere they could find their source. One of those for example was when Nasty-Company-Who-Shall-Not-Be-Graced-With-A-Mention decided to start charging for software that created .gif files and the graphics community went on a ballistic rampage jihad and destroyed every scrap of .gif code it could find so as to force users to migrate to .png. I did not wish to migrate to .png so I was very glad that I had saved all the old code, safe from the fires of the religious zealots. That's an issue of licensing, it is super annoying, and having older source code still available in those cases is indeed really useful. I don't know how relevant this is to this discussion though (granted, can we still pretend to be on-topic anyway?) given that this is more about open source projects merely providing binary packages (with the source available), rather than said project completely denying source code access. Regarding the ballistic rampage... I can't help but think that this is what's happening in BIND right now. Fortunately it was only a few days worth of commits that dealt with.. that totally 100% necessary change of nomenclature. Lastly, the way I look at it is when I field a new server, if it cannot recompile it's OS, kernel, make world, and all of it's applications from source, then it's a piece of excrement that I do not want in service. It is also a fact that I have had pre-production servers blow up on "make worlds" In a few cases this was bad ram, in one case the server was returned to the manufacturer under warranty. These are machines that did not display any issues before the OS load. Do not ask me why it was possible to install all the binaries for the OS and have it boot with no problems yet blow chunks/blue screen/abend/take a dive into the toilet/whatever your preferred term for crashing and burning is. I don't generally run FreeBSD or Linux as a desktop OS, BTW so that does affect my view of things. So yes, there is definitely an argument in favor of compiling the stuff at least on a server. Fair points. And I agree, having the option is absolutely something I wouldn't want to give away for proprietary software either. But in all the software I use (be it on workstations or servers, I run Linux on both) I do have that option. It's just not as convenient and I certainly wouldn't want every distro to turn into a Gentoo for incr
