Re: BIND9 dump file
Gerard Samuel wrote: Im getting a bunch of these in the logs - Nov 10 10:30:48 gatekeeper named[312]: dumping master file: master/tmp-SLtSQEmBBK: open: permission denied So I figured a filesystem permissions problem. I chowned Thanks for any info that you may provide... Im confused. I've read the named and rc.conf man pages, and didn't find out why named is behaving as it is. I don't know if this will help or is related. I had a problem with named not creating the pid-file with a permision denied error (see other thread). I eventually solved it by creating a new chroot-dir and setting permissions on that. It still remains a mystery to me why I ever got that problem or why this worked. Cheers, Erik -- Ph: +34.666334818 web: www.locolomo.org S/MIME Certificate: http://www.locolomo.org/crt/2004071206.crt Subject ID: A9:76:7A:ED:06:95:2B:8D:48:97:CE:F2:3F:42:C8:F2:22:DE:4C:B9 Fingerprint: 4A:E8:63:38:46:F6:9A:5D:B4:DC:29:41:3F:62:D3:0A:73:25:67:C2 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Maybe a bug in 5.3 [Was: Re: BIND9 dump file]
Erik Norgaard wrote:
Gerard Samuel wrote:
Im getting a bunch of these in the logs -
Nov 10 10:30:48 gatekeeper named[312]: dumping master file:
master/tmp-SLtSQEmBBK: open: permission denied
So I figured a filesystem permissions problem. I chowned
Thanks for any info that you may provide...
Im confused. I've read the named and rc.conf man pages, and didn't find
out
why named is behaving as it is.
I don't know if this will help or is related. I had a problem with named
not creating the pid-file with a permision denied error (see other thread).
I eventually solved it by creating a new chroot-dir and setting
permissions on that. It still remains a mystery to me why I ever got
that problem or why this worked.
I dont think recreating the chroot will fix it.
According to the docs, the chroot process is automatic in 5.3.
And since, I have no idea where these *automatic* instructions live,
I dont think moving/recreating the chroot will fix it.
I believe the problem lies within the *automatic* instructions.
Even in the docs for DNS in the handbook states that -
*
Create all directories that named expects to see:
# cd /etc/namedb
# mkdir -p bin dev etc var/tmp var/run master slave
# chown bind:bind slave var/*
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/network-dns.html#CHOWN-SLAVE
named only needs write access to these directories, so that is
all we give it.
Im not sure why the author assumes that named shouldn't write to the
master directory.
In my case, DHCP can only update master zones (DHCP updates DNS within
the LAN),
not slave zones, so master should be writeable by named.
What Im going to try is this.
Since the slave directory never seems to change permissions, I'll move the
LAN's zone files to the slave directory instead of the master directory.
And change named.conf -
zone trini0.org {
type master;
file slave/trini0.org;
allow-update { key DHCP_UPDATER; };
};
zone 0.168.192.in-addr.arpa {
type master;
file slave/trini0.org.rev;
allow-update { key DHCP_UPDATER; };
};
Kind of a contradiction if you're a stickler on the naming convention.
Hopefully if this *automatic* process doesn't recreate the directories
at boot time,
this should work out.
I'll try this, and report any findings.
Thanks for replying.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Maybe a bug in 5.3 [Was: Re: BIND9 dump file]
Gerard Samuel wrote:
Erik Norgaard wrote:
Gerard Samuel wrote:
Im getting a bunch of these in the logs -
Nov 10 10:30:48 gatekeeper named[312]: dumping master file:
master/tmp-SLtSQEmBBK: open: permission denied
So I figured a filesystem permissions problem. I chowned
Thanks for any info that you may provide...
Im confused. I've read the named and rc.conf man pages, and didn't
find
out
why named is behaving as it is.
I don't know if this will help or is related. I had a problem with named
not creating the pid-file with a permision denied error (see other
thread).
I eventually solved it by creating a new chroot-dir and setting
permissions on that. It still remains a mystery to me why I ever got
that problem or why this worked.
I dont think recreating the chroot will fix it.
According to the docs, the chroot process is automatic in 5.3.
And since, I have no idea where these *automatic* instructions live,
I dont think moving/recreating the chroot will fix it.
I believe the problem lies within the *automatic* instructions.
Even in the docs for DNS in the handbook states that -
*
Create all directories that named expects to see:
# cd /etc/namedb
# mkdir -p bin dev etc var/tmp var/run master slave
# chown bind:bind slave var/*
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/network-dns.html#CHOWN-SLAVE
named only needs write access to these directories, so that is
all we give it.
Im not sure why the author assumes that named shouldn't write to the
master directory.
In my case, DHCP can only update master zones (DHCP updates DNS within
the LAN),
not slave zones, so master should be writeable by named.
What Im going to try is this.
Since the slave directory never seems to change permissions, I'll move
the
LAN's zone files to the slave directory instead of the master directory.
And change named.conf -
zone trini0.org {
type master;
file slave/trini0.org;
allow-update { key DHCP_UPDATER; };
};
zone 0.168.192.in-addr.arpa {
type master;
file slave/trini0.org.rev;
allow-update { key DHCP_UPDATER; };
};
Kind of a contradiction if you're a stickler on the naming convention.
Hopefully if this *automatic* process doesn't recreate the directories
at boot time,
this should work out.
I'll try this, and report any findings.
Well its been over 2 hours, and its not reporting any problems in the logs.
So Im going to leave it as it is.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
BIND9 dump file
Im getting a bunch of these in the logs -
Nov 10 10:30:48 gatekeeper named[312]: dumping master file:
master/tmp-SLtSQEmBBK: open: permission denied
So I figured a filesystem permissions problem. I chowned
/var/named/etc/namedb/master to bind:wheel.
But when the box gets rebooted, the directory goes back to root:wheel.
Im currently using BIND9 only for the LAN (cacheing dns).
Thanks for any info that you may provide...
/etc/rc.conf
--
named_enable=YES
named_chrootdir=/var/named
/var/named/etc/namedb/named.conf
--
options {
directory /etc/namedb;
pid-file/var/run/named/pid;
dump-file /var/dump/named_dump.db;
statistics-file /var/stats/named.stats;
forward only;
forwarders {
w.x.y.z; a.b.c.d;
};
};
key DHCP_UPDATER {
algorithm HMAC-MD5.SIG-ALG.REG.INT;
secret my_key_here;
};
zone . {
type hint;
file named.root;
};
zone 0.0.127.IN-ADDR.ARPA {
type master;
file master/localhost.rev;
};
zone trini0.org {
type master;
file master/trini0.org;
allow-update { key DHCP_UPDATER; };
};
zone 0.168.192.in-addr.arpa {
type master;
file master/trini0.org.rev;
allow-update { key DHCP_UPDATER; };
};
// RFC 3152
zone
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA {
type master;
file master/localhost-v6.rev;
};
// RFC 1886 -- deprecated
zone
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.INT {
type master;
file master/localhost-v6.rev;
};
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: BIND9 dump file
Gerard Samuel wrote:
Im getting a bunch of these in the logs -
Nov 10 10:30:48 gatekeeper named[312]: dumping master file:
master/tmp-SLtSQEmBBK: open: permission denied
So I figured a filesystem permissions problem. I chowned
/var/named/etc/namedb/master to bind:wheel.
But when the box gets rebooted, the directory goes back to root:wheel.
Im currently using BIND9 only for the LAN (cacheing dns).
Thanks for any info that you may provide...
Im confused. I've read the named and rc.conf man pages, and didn't find out
why named is behaving as it is.
I've tried adding -
named_chroot_autoupdate=NO
to /etc/rc.conf, but its still generating those logs.
/etc/rc.conf
--
named_enable=YES
named_chrootdir=/var/named
/var/named/etc/namedb/named.conf
--
options {
directory /etc/namedb;
pid-file/var/run/named/pid;
dump-file /var/dump/named_dump.db;
statistics-file /var/stats/named.stats;
forward only;
forwarders {
w.x.y.z; a.b.c.d;
};
};
key DHCP_UPDATER {
algorithm HMAC-MD5.SIG-ALG.REG.INT;
secret my_key_here;
};
zone . {
type hint;
file named.root;
};
zone 0.0.127.IN-ADDR.ARPA {
type master;
file master/localhost.rev;
};
zone trini0.org {
type master;
file master/trini0.org;
allow-update { key DHCP_UPDATER; };
};
zone 0.168.192.in-addr.arpa {
type master;
file master/trini0.org.rev;
allow-update { key DHCP_UPDATER; };
};
// RFC 3152
zone
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA
{
type master;
file master/localhost-v6.rev;
};
// RFC 1886 -- deprecated
zone
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.INT
{
type master;
file master/localhost-v6.rev;
};
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
