named

[hamba]

Hi

I am having trouble with the default bind on my server, its telling me that the working dir is not writeable but I can't see where the problem is coming from, I've even compared the dirs to our secondary dns server and all of them looks the same and bind is working perfectly or I haven't noticed any strange dns problems because of this.

I see this error every time I restart named
Mar 17 19:23:22 server01 named[66256]: starting BIND 9.4.3-P1 -4 -t /var/named -u bind
Mar 17 19:23:22 server01 named[66256]: command channel listening on 127.0.0.1#953
Mar 17 19:23:22 server01 named[66256]: the working directory is not writable
Mar 17 19:23:22 server01 named[66256]: running

Can anyone please point me in the right direction on where the problem is coming from.

Thanks
hamba

[DutchDaemon]

http://forums.freebsd.org/showthread.php?t=1920

[hamba]

Hi

Thanks for that link, I missed that the last time I did a search :S

What they are talking about over there is about moving bind into a jail, in my case its all default and the named.conf is also just as default.

options {
// Relative to the chroot directory, if any
directory "/etc/namedb";
pid-file "/var/run/named/pid";
dump-file "/var/dump/named_dump.db";
statistics-file "/var/stats/named.stats";
....

I haven't changed anything that I know of that should affect bind in this way.

[DutchDaemon]

Well, all I can say that I never get that error, and I simply chown'ed everything under /var/named, including /var/named itself, to bind:bind. I'm running BIND 9.6 from ports, replacing the base system BIND.

This is the directory layout:


[ /var]# find named/ -type d | xargs ls -ld
drwxr-xr-x 5 bind bind 512 May 2 2008 named/
dr-xr-xr-x 2 bind bind 512 Feb 24 2008 named/dev
drwxr-xr-x 3 bind bind 512 May 2 2008 named/etc
drwxr-xr-x 6 bind bind 512 Mar 17 22:16 named/etc/namedb
drwxr-xr-x 2 bind bind 512 Feb 24 2008 named/etc/namedb/dynamic
drwxr-xr-x 2 bind bind 512 Mar 17 00:00 named/etc/namedb/log
drwxr-xr-x 2 bind bind 512 May 2 2008 named/etc/namedb/master
drwxr-xr-x 2 bind bind 512 Feb 24 2008 named/etc/namedb/slave
drwxr-xr-x 6 bind bind 512 May 2 2008 named/var
drwxr-xr-x 2 bind bind 512 Feb 24 2008 named/var/dump
drwxr-xr-x 2 bind bind 512 Feb 24 2008 named/var/log
drwxr-xr-x 3 bind bind 512 May 2 2008 named/var/run
drwxr-xr-x 2 bind bind 512 Feb 24 2008 named/var/run/named
drwxr-xr-x 2 bind bind 512 Feb 24 2008 named/var/stats


ymmv

[trev]

Here's the bind source code for that error...


/*
* Check that the working directory is writable.
*/
if (access(".", W_OK) != 0) {
isc_log_write(ns_g_lctx, NS_LOGCATEGORY_GENERAL,
NS_LOGMODULE_SERVER, ISC_LOG_ERROR,
"the working directory is not writable");
}


So the working directory really is not writable :)

[SirDice]

I have bind from the base running, nothing special. Here's my directory layout:
dice@maelcum:/etc>find /etc/namedb/ -type d | xargs ls -ld
drwxr-xr-x 5 root wheel 512 Feb 10 18:15 /etc/namedb/
drwxr-xr-x 2 bind wheel 512 Mar 18 09:28 /etc/namedb/dynamic
drwxr-xr-x 2 root wheel 512 Apr 14 2008 /etc/namedb/master
drwxr-xr-x 2 bind wheel 512 Oct 25 2007 /etc/namedb/slave
dice@maelcum:/etc>find /var/named/ -type d | xargs ls -ld
drwxr-xr-x 5 root wheel 512 Dec 16 2007 /var/named/
dr-xr-xr-x 4 root wheel 512 Feb 10 18:19 /var/named/dev
drwxr-xr-x 3 root wheel 512 Dec 16 2007 /var/named/etc
drwxr-xr-x 5 root wheel 512 Feb 10 18:15 /var/named/etc/namedb
drwxr-xr-x 2 bind wheel 512 Mar 18 09:28 /var/named/etc/namedb/dynamic
drwxr-xr-x 2 root wheel 512 Apr 14 2008 /var/named/etc/namedb/master
drwxr-xr-x 2 bind wheel 512 Oct 25 2007 /var/named/etc/namedb/slave
drwxr-xr-x 6 root wheel 512 Dec 16 2007 /var/named/var
drwxr-xr-x 2 bind wheel 512 Oct 25 2007 /var/named/var/dump
drwxr-xr-x 2 bind wheel 512 Mar 17 08:08 /var/named/var/log
drwxr-xr-x 3 bind wheel 512 Mar 5 22:21 /var/named/var/run
drwxr-xr-x 2 bind wheel 512 Feb 10 18:19 /var/named/var/run/named
drwxr-xr-x 2 bind wheel 512 Oct 25 2007 /var/named/var/stats

As you can see not everything is writable by bind. Only the directories it really needs to write in when running.

[hamba]

Hi

I had a look and all my dirs looks fine here is the output
# find /etc/namedb/ -type d | xargs ls -ld
drwxr-xr-x 5 root wheel 512 Mar 17 20:41 /etc/namedb/
drwxr-xr-x 2 bind wheel 512 Jul 14 2008 /etc/namedb/dynamic
drwxr-xr-x 2 root wheel 512 Mar 13 11:59 /etc/namedb/master
drwxr-xr-x 2 bind wheel 512 Jul 14 2008 /etc/namedb/slave
# find /var/named/ -type d | xargs ls -ld
drwxr-xr-x 5 root wheel 512 Jul 28 2008 /var/named/
dr-xr-xr-x 4 root wheel 512 Mar 18 09:44 /var/named/dev
drwxr-xr-x 3 root wheel 512 Aug 1 2008 /var/named/etc
drwxr-xr-x 5 root wheel 512 Mar 17 20:41 /var/named/etc/namedb
drwxr-xr-x 2 bind wheel 512 Jul 14 2008 /var/named/etc/namedb/dynamic
drwxr-xr-x 2 root wheel 512 Mar 13 11:59 /var/named/etc/namedb/master
drwxr-xr-x 2 bind wheel 512 Jul 14 2008 /var/named/etc/namedb/slave
drwxr-xr-x 6 root wheel 512 Jul 28 2008 /var/named/var
drwxr-xr-x 2 bind wheel 512 Jul 14 2008 /var/named/var/dump
drwxr-xr-x 2 bind wheel 512 Jul 14 2008 /var/named/var/log
drwxr-xr-x 3 bind wheel 512 Mar 18 09:44 /var/named/var/run
drwxr-xr-x 2 bind wheel 512 Mar 18 09:44 /var/named/var/run/named
drwxr-xr-x 2 bind wheel 512 Jul 14 2008 /var/named/var/stats

I can't see any differences that would cause this error message

[bobveznat]

/var/named/etc/namedb needs to be writable for that error message to go away.

I was getting this warning as well but just kept ignoring it. After chowning that directory to bind:bind the error has gone away. I think this is your problem as well.

# chown -R bind:bind /var/named/etc/namedb

[hamba]

Thanks for the reply but I don't think that is the answer because after doing that and restarting named I get the following

# /etc/rc.d/named restart
Stopping named.
Waiting for PIDS: 67273.
etc/namedb changed
user expected 0 found 53 modified
gid expected 0 found 53 modified
etc/namedb/dynamic changed
gid expected 0 found 53 modified
etc/namedb/master changed
user expected 0 found 53 modified
gid expected 0 found 53 modified
etc/namedb/slave changed
gid expected 0 found 53 modified
Starting named.

and then everything is back to the way it was and I'm stuck with this error again

[SirDice]

I just re-checked my bind. I also get that message, everything works as it should though.

[DutchDaemon]

My bind is blissfully silent, even though everything is bind:bind.


# /etc/rc.d/named restart
Stopping named.
Waiting for PIDS: 96857.
Starting named.



Mar 24 14:09:54 hail named[96857]: 24-Mar-2009 14:09:54.770 stopping command channel on 127.0.0.1#953
Mar 24 14:09:54 hail named[96857]: 24-Mar-2009 14:09:54.770 stopping command channel on ::1#953
Mar 24 14:09:54 hail named[96857]: 24-Mar-2009 14:09:54.814 exiting
Mar 24 14:09:56 hail named[12778]: starting BIND 9.6.0-P1 -u bind
Mar 24 14:09:56 hail named[12778]: built with '--localstatedir=/var' '--disable-linux-caps' '--with-randomdev=/dev/random' '--with-openssl=/usr/local' '--with-libxml2=/usr/local' '--without-idn' '--enable-ipv6' '--enable-threads' '--sysconfdir=/etc/namedb' '--prefix=/usr' '--mandir=/usr/share/man' '--infodir=/usr/share/info/' '--build=i386-portbld-freebsd7.1' 'build_alias=i386-portbld-freebsd7.1' 'CC=cc' 'CFLAGS=-O2 -fno-strict-aliasing -pipe' 'LDFLAGS= -rpath=/usr/local/lib' 'CXX=c++' 'CXXFLAGS=-O2 -fno-strict-aliasing -pipe'
Mar 24 14:09:56 hail named[12778]: command channel listening on 127.0.0.1#953
Mar 24 14:09:56 hail named[12778]: command channel listening on ::1#953
Mar 24 14:09:57 hail named[12778]: 24-Mar-2009 14:09:57.056 running


Mind:
starting BIND 9.6.0-P1 -u bind

rc.conf settings:


named_enable="YES"
named_program="/usr/sbin/named"
named_flags="-u bind"
named_pidfile="/etc/namedb/named.pid"
named_chrootdir=""
named_chroot_autoupdate="NO"
named_symlink_enable="NO"

[hamba]

Well I guess one solution would be to go to the ports version and forget about the default bind but it would be nice to know what is the cause of this problem.

[bobveznat]

etc/namedb changed
user expected 0 found 53 modified
gid expected 0 found 53 modified


Those messages almost seem to be saying that it knows, somehow, some way what the uid/gid used to be and it knows that they've changed.

If I were you I'd be tempted to blow away (or mv aside) /var/named/*, set the permissions correctly, and then start bind. This is just a wild guess though. Take it with a grain of salt :)

[trev]

Well I guess one solution would be to go to the ports version and forget about the default bind but it would be nice to know what is the cause of this problem.

Is it resolved if you (as root):


# cd /var/named/
# chown bind:wheel .
# chown -R bind:wheel *
# chmod -R g+w *
# chmod -R g+r *

[hamba]

nope,

This time around it picked up on the chmod as well and changed them back to 0755
Even by comparing named dirs to a system that doesn't use bind they all look the same.

[trev]

This time around it picked up on the chmod as well and changed them back to 0755


Your machine is possessed! Are you sure this is a default install?

I'm running BIND 9.4.2-P2 on FreeBSD 7.1-STABLE #17: Tue Feb 17 20:07:52 EST 2009 amd64 and I do not get any of the behaviour you are reporting, let alone the system "knowing" when file permissions have changed and then changing them back by itself. There's something else going on here.

[hamba]

maybe it is maybe it isn't
I'm running FreeBSD 7.1-STABLE #0: Tue Mar 17 16:31:18 GMT 2009 GENERIC amd64
Also there is an mtree thingy in /etc/mtree for bind
# cat /etc/mtree/BIND.chroot.dist
# $FreeBSD: src/etc/mtree/BIND.chroot.dist,v 1.6 2004/11/04 05:24:29 gshapiro Exp $
#
# Please see the file src/etc/mtree/README before making changes to this file.
#

/set type=dir uname=root gname=wheel mode=0755
.
dev mode=0555
..
etc
namedb
dynamic uname=bind
..
master
..
slave uname=bind
..
..
..
/set type=dir uname=bind gname=wheel mode=0755
var uname=root
dump
..
log
..
run
named
..
..
stats
..
..
..

This is what I believe is chmod/chown the dirs back to defaults.

[SirDice]

Your machine is possessed! Are you sure this is a default install?
Not really, it's just what bind does.

Hamba: It's actually a warning not an error. You can safely ignore it. Bind will work nonetheless.

As far as I've been able to work it out it's a small bug in named. It checks for access at the wrong moment.

http://www.archivum.info/bind-users@isc.org/2008-07/msg00340.html

[tiko]

I received the same warning message using the version of Bind included with 7.1-RELEASE and 7.2-STABLE; after installing the port from dns/bind96 the error cleared itself up with no changes on my part.