Ownership of /var/named Changes on Reboot.

[Martin McCormick]

Matthew Seaman writes:
> Furthermore, the default setup *is* for named to run as an unprivileged
> process.  The setup is very carefully designed so that named doesn't
> have write permission on the directory where its configuration files are
> stored, or on directories that contain static zone files, but it does
> have write permission on directories it uses for zone files AXFR'd from
> a master, or zone files maintained using dynamic DNS.
> 
> This used to generate a warning from bind about not having a writable
> current working directory -- which was basically harmless and could be
> ignored.  However recent changes mean bind needs a writable working
> directory, so the latest layouts include /var/named/etc/namedb/working

	That turned out to be the issue. I reset the permissions
to match the way they are when one first installs bind.
Root owns /var/named but bind owns directories that should be
writable so the trick is to set one's named.conf file to
reference writable directories for all the zones, logs and
named.pid. It is now starting automatically on reboot just like
it should.

	While bind owns all the writable subdirectories, they
all still have wheel as their GID. That appears to be okay since
they are all only writable by owner.

	Thanks for explaining this annoying little mystery that
has dogged me at a minor level for years.

	I have been running bind for Oklahoma State University
for close to 18 years and one tends to stick with configurations
that work. It is just time to modernize and at least configure
bind in the recommended way so as to take full advantage of the
clever design.

	It does still give the message that the working
directory is not writable.

Martin McCormick