From pemensik@redhat.com Mon Mar 27 13:07:38 2017 X-Scanned-BY: MIMEDefang 2.79 on 10.5.11.16 Dkim-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 389D114BFF7 MIME-Version: 1.0 In-Reply-To: X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_HI, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,RP_MATCHES_RCVD autolearn=ham autolearn_force=no version=3.4.0 X-RT-Interface: API Dmarc-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 389D114BFF7 References: <317307465.487433.1489162746275.JavaMail.zimbra@redhat.com> <960257277.509834.1489165546786.JavaMail.zimbra@redhat.com> <20170310174641.GB92236@isc.org> <1dee09e0-c1a7-3d7f-0c71-9368e04ae1be@redhat.com> Message-ID: <1bc7ef6b-91dd-6792-d5d0-c31b45a26519@redhat.com> content-type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=pemensik@redhat.com Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) by bugs.isc.org (Postfix) with ESMTP id 218C971B5A8 for ; Mon, 27 Mar 2017 13:07:38 +0000 (UTC) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 147F0349480 for ; Mon, 27 Mar 2017 13:07:36 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 389D114BFF7 for ; Mon, 27 Mar 2017 13:07:35 +0000 (UTC) Received: from menpad.brq.redhat.com (menpad.brq.redhat.com [10.34.4.127]) by smtp.corp.redhat.com (Postfix) with ESMTPS id D342C79590 for ; Mon, 27 Mar 2017 13:07:34 +0000 (UTC) Delivered-To: bind9-review@bugs.isc.org User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 Subject: Re: [ISC-Bugs #44853] [PATCH] NZF files cannot be written to different directory Return-Path: X-Original-To: bind9-review@bugs.isc.org Date: Mon, 27 Mar 2017 15:07:33 +0200 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Mon, 27 Mar 2017 13:07:35 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on mx.pao1.isc.org To: bind9-review@isc.org Content-Transfer-Encoding: 8bit From: "Petr Menšík" RT-Message-ID: Content-Length: 2512 Hi Evan, today I was checking my 9.11 instance with some stuff of dyndb. I noticed write errors of NTA files. I did not notice it before, because I do not use Bind 9.11 much yet. I am sure I would like to be able to change view->nta_file write directory as well. It is less important than nzf files for me right now. I do not like an idea of three options however, all of them with the same value. I think it would make sense to have one common option for all mkeys, nzf/nzd and nta files. With possible override for a specific type if required. It might be useful to have configuration type of "path to existing directory" maybe. It would not be required to copy path test and report and error in case specified directory did not exist. I am looking forward to merge back your changes. I will try to make similar backport to Bind 9.9 which we ship in RHEL. You are right about core dumps. We have coredumps handled by abrt tool in Fedora and RHEL. Without manual configuration, you will not get core dump in working directory in those distributions. Maybe also from derived ones. They are dumped into some system directory, where they are unreadable by ordinary user. That is important feature of packaged services, because it allows easier sending of core dumps (and more information) from our customers. Unfortunately most bugs from BIND are core dumps from memory leak detection, where I am not able to tell the reason for them. But it is good feature anyway. Dne 25.3.2017 v 07:28 Evan Hunt via RT napsal(a): > >> I think there are only dynamic zones with their journal. But they use >> temporary files in the same directory as themselves, aren't they? >> What other problems can it make? I can think only automatic DNSSEC >> resigning. Such zones are updated using dynamic updates anyway, aren't >> they? Selinux will log any access violation. The only problem reported >> by users was .nzf files. If you know any potential problems, I would >> really like to hear them. > > The most significant problem that's hard to correct with careful configuration > of named is that most platforms write core dumps to the working directory by > default, and changing that is usually a system-wide setting rather than something > that can be corrected specifically for named. It makes for difficult > debugging. > > But I do think you're correct that the files named has direct control over can > be configured to write elsewhere (with the exception of NZF and NZDB files, > which your patch addresses). >