Feature request: Separate the idea of "working directory" from "configuration directory"

Chris Buxton cbuxton at menandmice.com
Thu Aug 21 00:35:34 UTC 2008


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

We're really just talking about the default path for output files. The  
rest of any directory structure rooted at the point indicated by  
"directory" does not need to be changed. Therefore, I would suggest  
something like this:

options {
	directory "/var/named";
	output-directory "named.out";
};

In other words, for all output files that have a default path, set the  
default path to the containing directory to equal the value of "output- 
directory", which should itself default to the value of "directory". I  
see this affecting the following output files:

- - core dump
- - database dump
- - the default debug log file
- - named.stats

In other words, this wouldn't affect anything other than files that,  
by default, are normally written to the working directory itself. It  
would not affect any path explicitly specified anywhere in named.conf.

Chris Buxton
Professional Services
Men & Mice

On Aug 19, 2008, at 3:11 PM, JINMEI Tatuya / 神明達哉 wrote:

> At Mon, 04 Aug 2008 16:12:47 -0700,
> Doug Barton <dougb at dougbarton.us> wrote:
>
>> By default in FreeBSD the directory option is set to /etc/namedb (the
>> traditional name in *BSD), and that directory is set to 755  
>> root:wheel
>> which means that named cannot write to it after it drops privileges.
>> This is intentional, and just about all the "useful" stuff that named
>> would normally write to this directory has another home with
>> appropriate permissions.
>
> [snip]
>
>> So I'm proposing the idea of a new working-directory option for
>> named.conf. Is there interest in this idea?
>
> In my understanding, the most important reason for requiring the
> working directory writeable is to let named dump a core when it
> crashes.  If a new option provides a clean way to achieve this goal
> while storing "static" configuration files under read-only
> directories, I think it makes sense.
>
> ---
> JINMEI, Tatuya
> Internet Systems Consortium, Inc.
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkisuFYACgkQ0p/8Jp6Boi0WuwCePeEIVk2wlUFOqgj/ny+besTF
2+YAoIS23EbhAd3giRnEB1l+HOKdfDxB
=uqRL
-----END PGP SIGNATURE-----


More information about the bind-users mailing list