Re: From RHEL to CentOS BIND 9
isp...@logicore.net
> to all under /var/named/chroot.
>
> /var/named/data
> /var/named/slave
Do you mean that I should still change the default installation permissions to
give named full rw access to these? I would have thought the installer would
do this by default and that users would not need to get into having to change
permissions and so on. I can't believe I've been at this two days now :).
> I apologize if you receive this twice but lately my mails don't seem to be
> getting to the mailing list and I cannot figure out why.
No big deal, thanks for the help :).
isp...@logicore.net
ownership and permissions? I have named.pid owned by named,
Then,
drwxrwxr-- 2 root named 4096 Jul 19 2005 dev
drwxrwx--- 2 root named 4096 Dec 4 17:47 etc
dr-xr-xr-x 51 root root 0 Dec 3 05:20 proc
drwxrwx--- 5 root named 4096 Dec 4 11:08 var
However, transfers are still failing between servers;
Dec 5 08:08:33 dns named[5760]: dumping master file: tmp-XXXXcbDnhE: open:
permission denied
Dec 5 08:08:33 dns named[5760]: transfer of 'xxx.com/IN' from xx.xx.xx.31#53:
failed while receiving responses: permission denied
Dec 5 08:08:33 dns named[5760]: transfer of 'xxx.com/IN' from xx.xx.xx.31#53:
end of transfer
Thing is, this is happening on both the new server AND the old DNS server
which was working fine until I tried to tar it all up :).
Mike
> It appears that you need to alter the permissions on your directory (as
> defined by the directory option in the global options block in
> named.conf). This directory needs to be writable by the user that named
> is running as.
>
> Josh Baird
>
> -----Original Message-----
> From: bind-use...@isc.org [mailto:bind-use...@isc.org] On
> Behalf Of isp...@logicore.net
> Sent: Tuesday, December 04, 2007 4:43 PM
> To: bind-users
> Subject: Re: From RHEL to CentOS BIND 9
>
> Dec 4 16:40:06 dns named[5760]: dumping master file: tmp-XXXXF3AkzI:
> open:
> permission denied
> Dec 4 16:40:06 dns named[5760]: transfer of 'xxx.com/IN' from
> xx.xx.xx.31#53:
> failed while receiving responses: permission denied
> Dec 4 16:40:06 dns named[5760]: transfer of 'xxx.com/IN' from
> xx.xx.xx.31#53:
> end of transfer
> Dec 4 16:40:09 dns named[5760]: client xx.xx.xx.51#47914: zone transfer
>
> '67.in-addr.arpa/IN' denied
> Dec 4 16:40:14 dns named[5760]: client xx.xx.xx.51#58248: zone transfer
>
> 'xxxx.com/IN' denied
>
> Alright, what have I broken now?
>
> Mike
isp...@logicore.net
as primary/secondary?
isp...@logicore.net
Thanks but I didn't find my solution there which is why I asked here.
Anyhow, I do see yet another off behavior. My named.pid file is running as a
linked file under /var/run/named.pid linked to
/var/named/chroot/var/run/named/named.pid.
However, in /var/run, named will not even start unless I have a directory
called named. Without the directory, named doesn't start. With it, it starts
and it automatically sets up the link.
Stranger still, I can't set the path. In my named.conf, I actually have it set
to /var/run/named/named.pid and it seems to be ignored.
What's going on?
Adam Tkac
> > That being said named has access to only a few directories that it can write
> > to all under /var/named/chroot.
> >
> > /var/named/data
> > /var/named/slave
>
> Do you mean that I should still change the default installation permissions to
> give named full rw access to these? I would have thought the installer would
> do this by default and that users would not need to get into having to change
> permissions and so on. I can't believe I've been at this two days now :).
You should put your slave zones into /var/named/slave directory. Those
directories have correct perms. Also SELinux allows named to write
only there.
Adam
--
Adam Tkac, Red Hat, Inc.
isp...@logicore.net
Dec 5 08:48:34 ns1 named[3909]: transfer of 'xxx.com/IN' from xx.xx.xx.31#53:
failed while receiving responses: REFUSED
isp...@logicore.net
> directories have correct perms. Also SELinux allows named to write
> only there.
Well, I seem to have two slave directories.
One in /var/named/chroot/var/named/slaves and the other /var/named/slaves. So,
move all of my slave files to /var/named/slaves then, non chrooted?
Mike
Adam Tkac
> I'm still missing something here. I've looked at the FAQ, I've checked
> ownership and permissions? I have named.pid owned by named,
>
> Then,
>
> drwxrwxr-- 2 root named 4096 Jul 19 2005 dev
> drwxrwx--- 2 root named 4096 Dec 4 17:47 etc
> dr-xr-xr-x 51 root root 0 Dec 3 05:20 proc
> drwxrwx--- 5 root named 4096 Dec 4 11:08 var
>
> However, transfers are still failing between servers;
>
> Dec 5 08:08:33 dns named[5760]: dumping master file: tmp-XXXXcbDnhE: open:
> permission denied
> Dec 5 08:08:33 dns named[5760]: transfer of 'xxx.com/IN' from xx.xx.xx.31#53:
> failed while receiving responses: permission denied
> Dec 5 08:08:33 dns named[5760]: transfer of 'xxx.com/IN' from xx.xx.xx.31#53:
> end of transfer
>
> Thing is, this is happening on both the new server AND the old DNS server
> which was working fine until I tried to tar it all up :).
>
>
> Mike
- put your slave zone to ${chroot}/var/named/slaves directory. (should have
"drwxrwx--- named named" by default)
- if you have SELinux enabled run "restorecon -R
${chroot}/{dev,etc,var}"
Also good way how setup chroot is use bind-chroot-admin script. You
should only put zones to standard directory and run bind-chroot-admin
--enable and this command will do all needed work
isp...@logicore.net
> directories have correct perms. Also SELinux allows named to write
> only there.
I've moved all of my slave records to /var/named/slaves and am getting the
same error of REFUSED now.
Guess I'm confused as to why this is so complicated. I simply installed the
RPM, one would thing all permissions and paths and all that would be done
automatically.
Mike
Adam Tkac
I'm not sure why you don't use standard distribution scripts and
setup. If you really need this uncommon setup then compile BIND
yourself from source. In other case try:
- $yum install bind
- configure /etc/named.conf
- add zones to /var/named{,slaves}
- run restorecon on all modified files if you're using SELinux
- if you want chroot install bind-chroot package
- run $service named start
This works as expected.
Adam Tkac
Did you setup master server correctly? You should add allow-transfer
option to master zone statement. What log on master says?
isp...@logicore.net
> "drwxrwx--- named named" by default)
Ok, let's see if I can give enough information in case it's something I am
missing.
# ls -la /var/named/
drwxr-x--- 5 root named 4096 Nov 10 09:22 .
drwxr-xr-x 19 root root 4096 Dec 3 16:45 ..
drwxr-x--- 6 root named 4096 Dec 3 20:04 chroot
drwxrwx--- 2 named named 4096 Nov 10 09:22 data
drwxrwx--- 2 named named 4096 Dec 5 08:59 slaves
# ls -la /var/named/chroot/
drwxr-x--- 2 root named 4096 Nov 10 09:22 dev
drwxr-x--- 2 root named 4096 Dec 4 23:43 etc
drwxr-xr-x 2 root root 4096 Dec 3 20:04 proc
drwxr-x--- 5 root named 4096 Mar 13 2003 var
# ls -la /var/named/chroot/var/
drwxr-x--- 5 root named 4096 Mar 13 2003 .
drwxr-x--- 6 root named 4096 Dec 3 20:04 ..
drwxr-x--- 4 root named 4096 Dec 4 15:09 named
drwxr-x--- 4 root named 4096 Dec 3 20:04 run
drwxrwx--- 2 named named 4096 Mar 13 2003 tmp
# ls -la /var/named/chroot/var/named/
-rw-r--r-- 1 root root 1413 Apr 24 2007 0
-rw-r--r-- 1 root root 1583 Oct 19 14:01 xx.xx.xx.in-addr.arpa
-rw-r--r-- 1 root root 230 May 25 2007 xx.in-addr.arpa
drwxrwx--- 2 named named 4096 Aug 25 2004 data
-rw-r--r-- 1 root root 621 Dec 4 14:29 xxx.net
-r--r--r-- 1 root root 405 Aug 15 2006 localhost.rev
-r--r--r-- 1 root root 284 Jun 15 2001 make-localhost
-r--r--r-- 1 root root 0 Apr 30 2006 xxx.com.lock
-rw-r--r-- 1 root root 2516 Dec 4 15:09 named.root
-r--r--r-- 1 root root 0 Apr 30 2006 xxx.com.lock
-r--r--r-- 1 root root 397 Aug 12 2002 PROTO.localhost.rev
-rw-r--r-- 1 root root 698 Apr 24 2007 xxx.com
drwxrwx--- 2 named named 4096 Dec 5 08:59 slaves
The rest of the zones are in the zones directory. I am trying to move from one
DNS server to the other, then this new one will become the primary and then I
will be setting up a secondary.
Should I be making this machine a secondary right off the bat since it's going
to actually be taking over from my old primary?
> - if you have SELinux enabled run "restorecon -R
> ${chroot}/{dev,etc,var}"
SELinux is disabled.
I'm sorry about the confusion but I've become terribly confused over the past
couple days :).
Mike
isp...@logicore.net
> setup. If you really need this uncommon setup then compile BIND
> yourself from source. In other case try:
I'm not sure how I'm ending up with a non standard setup. It's not what I've
been wanting. I have no need for anything special, I just wanted to install a
new replacement primary to take over from my current primary.
> - $yum install bind
> - configure /etc/named.conf
> - add zones to /var/named{,slaves}
> - run restorecon on all modified files if you're using SELinux
> - if you want chroot install bind-chroot package
> - run $service named start
Maybe I should re-install and start from scratch since this seems to be
totally messed up now. Do you feel it might be best to start over before I do
the above?
Mike
Adam Tkac
I think start from scratch will be fastest and easiest way how fix
it (especially when you modified perms etc). It will take
about 5 minutes if you have zone files and named.conf :)
isp...@logicore.net
> it (especially when you modified perms etc). It will take
> about 5 minutes if you have zone files and named.conf :)
I didn't change much for permissions and such but zone files and named.conf
and such have been messed with too much by now. I'll rebuild and try your
suggestion before anything.
Do you have any tips on anything else I should be aware of?
The scenario is that I have a RHEL based primary right now. I am installing a
new CentOS based bind server, both are chrooted. I am replacing the first
machine with the second. I will have to turn off the old machine and change
the new machine IP when I am ready to let it take over.
Once this is working correctly, the second part will be getting a secondary
online. I want to get the first one going before thinking about the secondary
:).
Mike
Baird, Josh
Remove the bind packages that you have already installed and "yum
install bind-chroot"
This will install a chrooted bind in /var/named/chroot/.
Copy the named.conf from your RHEL primary to
/var/named/chroot/etc/named.conf on the new CentOS box.
Copy the zones from your RHEL primary to /var/named/chroot/etc/xxx,
where 'xxx' is the "directory" in global options.
Take the RHEL primary offline, assign it's IP to the CentOS box, and
boom -- you should have a working BIND master. Remember that if you
want to log within a chroot, you will need to start syslogd with the -a
flag (check /etc/sysconfig/syslog, and make the change here).
Thanks,
Josh Baird
-----Original Message-----
From: bind-use...@isc.org [mailto:bind-use...@isc.org] On
Behalf Of isp...@logicore.net
Sent: Wednesday, December 05, 2007 9:39 AM
To: bind-users
Subject: Re: From RHEL to CentOS BIND 9
isp...@logicore.net
I don't know that I've made it more complicated but it certainly got that way.
I'm starting from scratch so it's all clean again.
> Remove the bind packages that you have already installed and "yum
> install bind-chroot"
> This will install a chrooted bind in /var/named/chroot/.
Done. I'm running 9.3.3 on the new server. Note that the RPM did not create a
link in /etc for named.conf but has for rndc.key back to
/var/named/chroot/etc.
> Copy the named.conf from your RHEL primary to
> /var/named/chroot/etc/named.conf on the new CentOS box.
Done.
> Copy the zones from your RHEL primary to /var/named/chroot/etc/xxx,
> where 'xxx' is the "directory" in global options.
There are no zone files in /var/named/chroot/etc;
# ls -la
total 44
drwxrwx--- 2 root named 4096 Dec 5 10:28 .
drwxrwx--- 6 root named 4096 Aug 9 2006 ..
-rw-r--r-- 1 root root 1279 Jun 6 2006 localtime
-rw-r--r-- 1 root named 9352 Dec 5 09:29 named.conf
-rw-r--r-- 1 root named 76 Aug 9 2006 rndc.key
Do you mean in /var/named/chroot/var/named/xx?
There are files in the /var/named/chroot/var/named/ directory and
/var/named/chroot/var/named/slaves directory.
The main zone files are in the slaves directory and a few along with network
files just above that.
# ls -la
total 72
-rw-r--r-- 1 root root 1413 Apr 24 2007 0
-rw-r--r-- 1 root root 1583 Oct 19 14:01 xx.xx.xx.in-addr.arpa
-rw-r--r-- 1 root root 230 May 25 2007 67.in-addr.arpa
-rw-r--r-- 1 root root 1630 Dec 4 15:26 xxx.com
drwxrwx--- 2 named named 4096 Aug 25 2004 data
-rw-r--r-- 1 root root 888 Dec 4 14:50 xxx.net
-r--r--r-- 1 root root 405 Aug 15 2006 localhost.rev
-r--r--r-- 1 root root 284 Jun 15 2001 make-localhost
-r--r--r-- 1 root root 0 Apr 30 2006 xxx.com.lock
-rw-r--r-- 1 root root 2517 Aug 9 2006 named.root
-r--r--r-- 1 root root 0 Apr 30 2006 xxx.com.lock
-r--r--r-- 1 root root 397 Aug 12 2002 PROTO.localhost.rev
-rw-r--r-- 1 root root 698 Apr 24 2007 xxx.com
drwxrwx--- 2 named named 4096 Dec 4 14:17 slaves
Mike
Baird, Josh
and move them to the same location on your CentOS box. If they are in
/var/named/chroot/var/named, fine. Put them where ever your named.conf
is looking for them.
Josh
-----Original Message-----
From: bind-use...@isc.org [mailto:bind-use...@isc.org] On
Behalf Of isp...@logicore.net
Alan Clegg
> Done. I'm running 9.3.3 on the new server. Note that the RPM did not create a
> link in /etc for named.conf but has for rndc.key back to
> /var/named/chroot/etc.
I hate to throw another monkey onto the pile of dead ones that this
thread has already generated, but...
If you are going through all of this to get your nameserver "updated",
why not go ahead and pull in 9.4.2 instead of using code that was
released nearly a year ago tomorrow and has known outstanding issues?
AlanC
Adam Tkac
That code is 9.3.3rc2 with all security patches. In next update source
will be based on regular 9.3.4P1 . Compilation of 9.4.2 directly from
source will be more vulnerable than distribution package.
isp...@logicore.net
On Wed, 5 Dec 2007 10:47:47 -0600, Baird, Josh wrote:
> The point is to take all of the zones from your current RHEL primary,
>
> and move them to the same location on your CentOS box. If they are in
> /var/named/chroot/var/named, fine. Put them where ever your named.conf
> is looking for them.
>
> Josh
>
> -----Original Message-----
> From: bind-use...@isc.org [mailto:bind-use...@isc.org] On
> Behalf Of isp...@logicore.net
> Sent: Wednesday, December 05, 2007 10:32 AM
> To: bind-users
> Subject: RE: From RHEL to CentOS BIND 9
>
>> I think that you are making this way too complicated.
>>
> I don't know that I've made it more complicated but it certainly got
> that way.
> I'm starting from scratch so it's all clean again.
>
>> Remove the bind packages that you have already installed and "yum
>> install bind-chroot"
>> This will install a chrooted bind in /var/named/chroot/.
>>
> Done. I'm running 9.3.3 on the new server. Note that the RPM did not
> create a
> link in /etc for named.conf but has for rndc.key back to
> /var/named/chroot/etc.
>
isp...@logicore.net
> where 'xxx' is the "directory" in global options.
Done.
> Take the RHEL primary offline, assign it's IP to the CentOS box, and
> boom -- you should have a working BIND master. Remember that if you
> want to log within a chroot, you will need to start syslogd with the -a
> flag (check /etc/sysconfig/syslog, and make the change here).
Turned off primary, changed IP on new server, rebooted.
Try to start named;
# /etc/init.d/named start
Starting named:
Error in named configuration:
zone 0.0.127.IN-ADDR.ARPA/IN: loaded serial 2006081501
zone xxx.com/IN: loading master file xxx.com: file not found
_default/xxx.com/IN: file not found
zone xx.in-addr.arpa/IN: loaded serial 2006081501
zone xxxx.net/IN: loaded serial 1192810548
zone xxxxx.com/IN: loaded serial 1194741461
zone xx.xx.xx.in-addr.arpa/IN: loaded serial 2007042428
And, /var/log/messages;
Dec 5 11:53:33 ns1 named: zone 0.0.127.IN-ADDR.ARPA/IN: loaded serial
2006081501
Dec 5 11:53:33 ns1 named: zone xxx.com/IN: loading master file xxx.com: file
not found
Dec 5 11:53:33 ns1 named: _default/xxx.com/IN: file not found
Dec 5 11:53:33 ns1 named: zone xx.in-addr.arpa/IN: loaded serial 2006081501
Dec 5 11:53:33 ns1 named: zone xxxx.net/IN: loaded serial 1192810548
Dec 5 11:53:33 ns1 named: zone xxxxx.com/IN: loaded serial 1194741461
Dec 5 11:53:33 ns1 named: zone xx.xx.xx.in-addr.arpa/IN: loaded serial
2007042428
So here's the rub. This is the exact configuration from the running machine.
So, what's changed and why does it think these files are problems?
Mike
isp...@logicore.net
Dec 5 12:00:50 ns1 kernel: audit(1196877650.794:6): avc: denied { getattr }
for pid=1675 comm="rndc" path="/var/named/chroot/etc/rndc.key" dev=hda1
ino=349192 scontext=system_u:system_r:ndc_t:s0
tcontext=root:object_r:etc_runtime_t:s0 tclass=file
Since I have a completely new install and have copied a working machine over,
you would think this should just run, immediately.
Mike
On Wed, 5 Dec 2007 09:49:25 -0600, Baird, Josh wrote:
> I think that you are making this way too complicated.
>
> Remove the bind packages that you have already installed and "yum
> install bind-chroot"
>
> This will install a chrooted bind in /var/named/chroot/.
>
> Copy the named.conf from your RHEL primary to
> /var/named/chroot/etc/named.conf on the new CentOS box.
>
> Copy the zones from your RHEL primary to /var/named/chroot/etc/xxx,
> where 'xxx' is the "directory" in global options.
>
> Take the RHEL primary offline, assign it's IP to the CentOS box, and
> boom -- you should have a working BIND master. Remember that if you
> want to log within a chroot, you will need to start syslogd with the -a
> flag (check /etc/sysconfig/syslog, and make the change here).
>
> Thanks,
>
> Josh Baird
>
> -----Original Message-----
> From: bind-use...@isc.org [mailto:bind-use...@isc.org] On
> Behalf Of isp...@logicore.net
isp...@logicore.net
> why not go ahead and pull in 9.4.2 instead of using code that was
> released nearly a year ago tomorrow and has known outstanding issues?
I need to keep this as an RPM install because the folks taking it over won't
be able to maintain it beyond yum update.
isp...@logicore.net
>> why not go ahead and pull in 9.4.2 instead of using code that was
>> released nearly a year ago tomorrow and has known outstanding issues?
One of the problems with networking is the assumption that all admins need to
become guru's at everything they touch. The fact is, there are a lot of people
out there who cannot become guru, they need to depend on being able to get
something built, that gives them reasonable security behind firewall's and can
get ongoing updates.
For those people, we need to be able to pull things together, make them work,
give them a fair reasonable means of staying up to date while not forcing them
to become guru's until they can afford to hire someone full time to take on
that task.
My input based on consulting for MANY years.
Mike
isp...@logicore.net
this working using RPM's.
Mike
On Wed, 05 Dec 2007 09:45:07 -0600, Matt Tesauro wrote:
> I've got several CentOS 5 boxen running the source install of BIND.
>
> Here's a quick and dirty recipe of how I made it work for me:
>
> (1) Install the bind-chroot rpm ("yum install bind-chroot") then remove
> it (rpm -e bind bind-chroot). This is a quick way to get the chroot
> environment setup for you without a bunch of mkdir -p's - I'm lazy.
>
> (2) Get the latest source from ISC. Download into a joe user's home
> directory
>
> (3) Untar and then configure bind with the following script:
> # cat bind_configure
> CFLAGS="-O2 -march=i686 -funroll-loops"; export CFLAGS
> ./configure \
> --prefix=/usr/ \
> --sysconfdir=/etc \
> --localstatedir=/var \
> --mandir=/usr/share/man \
> --with-openssl \
> --with-libtool \
> --disable-ipv6 \
> --enable-threads \
> --disable-openssl-version-check
> (You can copy and paste this into vi or the editor of your choice - make
> sure to chmod u+x the script)
>
> (4) Run make as your joe user
>
> (5) su - to root and return to the source directory of BIND then run
> the following commands:
> find / > ~/pre_bind
> make install
> strip /usr/sbin/named
> install -c \
> -m0600 /home/[user]/bind-[version]/bin/rndc/rndc.conf /var/named/chroot/etc/
> chown named.named /var/named/chroot/etc/rndc.conf
> find / > post_bind
> diff pre_bind post_bind > bind_install
> vi bind_install [to remove extra cruft like /proc entries)
> rm pre_bind
> rm post_bind
>
> (6) Configure BIND - if your existing BIND install is sane and working,
> you can use that named.conf as a starting point. Don't forget about
> your friends for getting your setup right:
> /usr/sbin/named-checkzone
> /usr/sbin/named-checkconf
> /usr/sbin/rndc-confgen
>
> (7) I setup TSIG and rndc. Some good info can be had from the BIND
> chapter in this:
> Securing & Optimizing Linux: The Ultimate Solution
> version: 2.0
> author: Gerhard Mourani
> http://www.tldp.org/guides.html
> (most of this is modifications of stuff I learned from that great
> resource)
>
> (8) If/when a new version of BIND comes out, use the list of installed
> files as a means to remove the source installed BIND by vi'ing the file
> doing :1,$s/>/rm -f/ after making sure you _want_ to delete all entries
> in that file. Save it and chmod u+x and execute ./bind_install to
> remove the install. You can use your configure script to get the new
> source configured the same and follow the steps above for the new
> version.
>
> Note: The above assumes you have gcc and the necessary libraries
> installed. BIND's configure is good about telling you what you're
> missing - likely things like openssl-devel and such. I did a minimal
> install and added what I needed. Your install choices may already have
> most/all of the required RPMs.
>
> HTH
>
> -- Matt Tesauro
Kirk Bradel
>> Copy the zones from your RHEL primary to /var/named/chroot/etc/xxx,
>> where 'xxx' is the "directory" in global options.
>
>
>> Take the RHEL primary offline, assign it's IP to the CentOS box, and
>> boom -- you should have a working BIND master. Remember that if you
>> want to log within a chroot, you will need to start syslogd with the -a
>> flag (check /etc/sysconfig/syslog, and make the change here).
>
Mike,
What rpm / rpm's did you install.
Can you please post the contents of named.conf
Can you please post the contents of /etc/sysconfig/named
isp...@logicore.net
all.
> What rpm / rpm's did you install.
bind-9.3.3-10.el5
> Can you please post the contents of named.conf
options {
directory "/var/named";
dump-file "/var/named/data/cache_dump.db";
statistics-file "/var/named/data/named_stats.txt";
pid-file "/var/run/named/named.pid";
recursion no;
forwarders {
127.0.0.1;
};
allow-transfer {
xx.xx.xx.31;
};
};
controls {
inet * port 953 allow {
127.0.0.1;
}
keys {
rndc-key;
};
// Note: the following will be supported in a future release.
/*
host { any; } {
topology {
127.0.0.0/8;
};
};
zone "." {
type hint;
file "named.root";
};
zone "0.0.127.IN-ADDR.ARPA" {
type master;
file "localhost.rev";
};
zone "domain.com" {
type slave;
file "s/domain.com.bak";
masters {
192.168.1.1;
};
};
zone "0.168.192.in-addr.arpa" {
type slave;
file "s/0.168.192.in-addr.arpa.bak";
masters {
192.168.1.1;
};
};
*/
zone "xxx.com" {
type slave;
file "xxx.com";
allow-transfer {
xx.xx.xx.31;
xx.xx.xx.50;
common-allow-transfer;
};
masters {
xx.xx.xx.31;
};
};
zone "67.in-addr.arpa" {
type master;
file "67.in-addr.arpa";
allow-transfer {
common-allow-transfer;
};
};
zone "10.98.67.in-addr.arpa" {
type master;
file "10.98.67.in-addr.arpa";
allow-transfer {
common-allow-transfer;
};
};
acl common-allow-transfer {
none;
};
key rndc-key {
algorithm hmac-md5;
secret "xxxxxxxxxxxxxxxxxxxxxxxx";
};
server xx.xx.xx.31; {
};
> Can you please post the contents of /etc/sysconfig/named
ROOTDIR=/var/named/chroot
Baird, Josh
Per this configuration, all zone files should be placed within
/var/named/chroot/var/named. It is not starting because you are missing
zone files.
I really think an introductory book to BIND will help you immensely.
Josh
-----Original Message-----
From: bind-use...@isc.org [mailto:bind-use...@isc.org] On
Behalf Of isp...@logicore.net
Sent: Wednesday, December 05, 2007 12:48 PM
To: bind-users
Subject: Re: From RHEL to CentOS BIND 9
isp...@logicore.net
move as opposed to a new install, I am getting permissions errors.
Dec 5 13:05:13 ns1 named[1789]: transfer of 'xxx.com/IN' from xx.xx.xx.31#53:
end of transfer
Dec 5 13:05:13 ns1 named[1789]: dumping master file: tmp-k4GxpeeIAO: open:
permission denied
isp...@logicore.net
The FAQ tells that this is a permissions problem and that;
///
If named is invoked as "named -t /chroot/DNS" with the following named.conf
then "/chroot/DNS/var/named/sl" needs to be writable by the user named is
running as.
\\\
So, this is where things get silly and not as simple as a few have said this
should be since I've changed nothing so far other than have done what I need
to do, move the files over, restart as new server, etc.
named is running as user named.
# ls -la /var/named/chroot/var/named/
total 120
drwxr-x--- 4 root named 4096 Dec 4 15:26 .
drwxrwx--- 5 root named 4096 Dec 4 11:08 ..
-rw-r--r-- 1 root root 1413 Apr 24 2007 0
-rw-r--r-- 1 root root 1583 Oct 19 14:01 xx.xx.xx.in-addr.arpa
-rw-r--r-- 1 root root 230 May 25 2007 xx.in-addr.arpa
-rw-r--r-- 1 root root 1630 Dec 4 15:26 xxx.com
drwxrwx--- 2 named named 4096 Aug 25 2004 data
-rw-r--r-- 1 root root 888 Dec 4 14:50 xxx.net
-r--r--r-- 1 root root 405 Aug 15 2006 localhost.rev
-r--r--r-- 1 root root 284 Jun 15 2001 make-localhost
-r--r--r-- 1 root root 0 Apr 30 2006 xxx.com.lock
-rw-r--r-- 1 root root 2517 Aug 9 2006 named.root
-r--r--r-- 1 root root 0 Apr 30 2006 xxx.com.lock
-r--r--r-- 1 root root 397 Aug 12 2002 PROTO.localhost.rev
-rw-r--r-- 1 root root 698 Apr 24 2007 xxx.com
drwxrwx--- 2 named named 4096 Dec 4 14:17 slaves
I'm guessing that these files need to be owner by at least root/named to begin
with?
All files in the slave directory are owned by named.named.
Mike
isp...@logicore.net
> Why are you forwarding to yourself?
As I said, some of the configurations need to be cleaned up. Right now, I'm
just trying to get the server running :).
> Per this configuration, all zone files should be placed within
> /var/named/chroot/var/named. It is not starting because you are missing
> zone files.
They are and have been. There aren't any zone files missing, they are where
they are supposed to be.
Mike
isp...@logicore.net
Dec 5 13:15:06 ns1 kernel: audit(1196882106.031:11): avc: denied { getattr
} for pid=1837 comm="rndc" path="/var/named/chroot/etc/rndc.key" dev=hda1
ino=349192 scontext=system_u:system_r:ndc_t:s0
tcontext=root:object_r:etc_runtime_t:s0 tclass=file
Since I just copied everything over, the keys match in the key file and the
named.conf file. Should I be generating a new key because it's a new server?
Mike
Alan Clegg
> Dec 5 13:15:06 ns1 kernel: audit(1196882106.031:11): avc: denied { getattr
> ino49192 scontext=system_u:system_r:ndc_t:s0
looks like selinux to me.
AlanC
Mark Andrews
> >failed while receiving responses: permission denied
>
> The FAQ tells that this is a permissions problem and that;
>
> ///
> If named is invoked as "named -t /chroot/DNS" with the following named.conf
> then "/chroot/DNS/var/named/sl" needs to be writable by the user named is
> running as.
> \\\
>
> So, this is where things get silly and not as simple as a few have said this
> should be since I've changed nothing so far other than have done what I need
> to do, move the files over, restart as new server, etc.
>
> named is running as user named.
>
> # ls -la /var/named/chroot/var/named/
> total 120
> drwxr-x--- 4 root named 4096 Dec 4 15:26 .
"named" does NOT have write permission on /var/named/chroot/var/named.
> drwxrwx--- 5 root named 4096 Dec 4 11:08 ..
> -rw-r--r-- 1 root root 1413 Apr 24 2007 0
> -rw-r--r-- 1 root root 1583 Oct 19 14:01 xx.xx.xx.in-addr.arpa
> -rw-r--r-- 1 root root 230 May 25 2007 xx.in-addr.arpa
> -rw-r--r-- 1 root root 1630 Dec 4 15:26 xxx.com
> drwxrwx--- 2 named named 4096 Aug 25 2004 data
> -rw-r--r-- 1 root root 888 Dec 4 14:50 xxx.net
> -r--r--r-- 1 root root 405 Aug 15 2006 localhost.rev
> -r--r--r-- 1 root root 284 Jun 15 2001 make-localhost
> -r--r--r-- 1 root root 0 Apr 30 2006 xxx.com.lock
> -rw-r--r-- 1 root root 2517 Aug 9 2006 named.root
> -r--r--r-- 1 root root 0 Apr 30 2006 xxx.com.lock
> -r--r--r-- 1 root root 397 Aug 12 2002 PROTO.localhost.rev
> -rw-r--r-- 1 root root 698 Apr 24 2007 xxx.com
> drwxrwx--- 2 named named 4096 Dec 4 14:17 slaves
>
> I'm guessing that these files need to be owner by at least root/named to begi
> n
> with?
>
> All files in the slave directory are owned by named.named.
>
> Mike
>
>
>
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark_A...@isc.org
isp...@logicore.net
As I said in another message, not everyone wants to become guru of everything
they touch. I've never needed to mess with installing a chrooted server and
won't often have to so learning everything about it is a waste of time.
I just need to get this machine moved over to a new one, learning just enough
to get it running so they can update it and keep maintaining the records as
they always have. They have never had any DNS problems so a nice running dns
server is all that's needed in this case.
I like to use open source as much as possible because I'm sick of seeing
companies using MS because it's 'so easy' to do. We need to help each other
and support each other and keep OS alive!
Mike
isp...@logicore.net
As I said, in the FAQ, they have;
>If named is invoked as "named -t /chroot/DNS" with the following named.conf
>then "/chroot/DNS/var/named/sl" needs to be writable by the user named is
>running as.
Again, it's not me complicating this but the FAQ and other things I've been
reading don't seem to agree in paths and other things. I would have thought
the RPM would have created the s directory if it's needed. Instead, I figured
it was slaves since that one was created.
Also, the FAQ states;
/chroot/DNS/var/named/sl
which is not just s nor is there a DNS directory but the named directory is
there of course.
Are you telling me I need to create an s directory or an sl directory under
named now?
> And in your named.conf:
>
> zone "domain.com" {
> type slave;
> file "s/domain.com.bak";
> masters {
> 192.168.1.1;
> There is no "s" folder in /var/named/chroot/var.
Correct and I've been told to simply copy my files over and not to complicate
anything, which is what I've been doing :).
> The SELINUX error is exactly that, an SELINUX error -- it has nothing to
> do with BIND. If you are receiving permission denied, it is filesystem
> permission errors -- again, nothing to do with BIND.
I've turned it off since then so it's not in the mix.
> It seems to me like you aren't even trying to find answers to your own
> problems, you are relying on the mailing list to setup your NS for you.
> All of these questions and more are covered in the BIND Admin Guide, and
> even better, in DNS & Bind (Oreilly).
Right, that must be it. Figured I'd count on the community so I don't spend a
week at this. You're right, it's so wrong of me. No one is forcing you to help
me you know. I have the BIND book, I have the FAQ, I have the Internet, I have
YOU and still it's not working.
So yeah, I'm counting on the community at this point else I'll have to use a
freaking MS machine.
Mike
isp...@logicore.net
Correct, just getting a little confused here. I turned it off, don't really
need it. Back to trying to figure out why I'm still getting;
//
Dec 5 13:27:53 ns1 named[1789]: dumping master file: tmp-sR5ej2BMG9: open:
permission denied
Dec 5 13:27:53 ns1 named[1789]: transfer of 'xxx.com/IN' from xx.xx.xx.31#53:
failed while receiving responses: permission denied
\\
Mike
Mark Andrews
Tell the SELinux people to leave the DNS alone. SELinux has
caused more support issues that anything else since its
introduction.
Mark
Oden Eriksson
> Why are you forwarding to yourself?
>
> /var/named/chroot/var/named. It is not starting because you are missing
> zone files.
>
he he, or simply use <plug>mandriva linux</plug>, well...
--
Regards // Oden Eriksson
Alan Clegg
the chroot environment, you will see where the permissions are set wrong.
While you bemoan the need to "become an expert", you are missing the
point. All of the problems that you are having are covered in
relatively basic knowledge of BIND and Linux. You are not being asked
to become an expert, just a knowledgeable user.
AlanC
Kirk Bradel
Mike,
According to your notes above, you *didn't* install the bind-chroot package or
else you would have a package like this "bind-chroot.i386".
Your /etc/sysconfig/named file indicates that BIND should be running chroot.
However, none of the entries in the named.conf file point to that chroot
directory structure.
isp...@logicore.net
Yup, correct.
Looks like it was indeed selinux. Turns out that selinux can only be disabled
with a reboot. At least that was the case for me. I disabled it in the
/etc/selinux config file, rebooted and the dns server came up just fine, no
errors.
Mike
Mark Andrews
> > looks like selinux to me.
>
> need it. Back to trying to figure out why I'm still getting;
>
> //
> Dec 5 13:27:53 ns1 named[1789]: dumping master file: tmp-sR5ej2BMG9: open:
> permission denied
> Dec 5 13:27:53 ns1 named[1789]: transfer of 'xxx.com/IN' from xx.xx.xx.31#53
> :
> failed while receiving responses: permission denied
> \\
>
Your BASIC file permissions are WRONG.
The user "named" does not have write permission on
<chrootpath>/var/named. This is the working directory you
told named (directory "/var/named";) to use and it is the
starting point for any relative file name in named.conf.
"xxx.com" is a relative file name as is "tmp-sR5ej2BMG9".
Named opens it temporary files in the directory that it
going to rename the file to ("xxx.com" in this case). This
allows named to atomically replace master files using
"rename(2)".
isp...@logicore.net
so that others will be aware of this.
> Tell the SELinux people to leave the DNS alone. SELinux has
> caused more support issues that anything else since its
> introduction.
Mike
isp...@logicore.net
> point. All of the problems that you are having are covered in
> relatively basic knowledge of BIND and Linux. You are not being asked
> to become an expert, just a knowledgeable user.
You know, not to you personally but...
You're missing the point completely. The idea behind open source is to allow
for choices so that MS for example is not the only choice out there. I love
pushing OS where I can but I don't have time to learn everything I touch
inside out or to become an expert at it all.
I don't care to become an expert at installing the darn thing, I just expected
it to work when I installed it so that I could easily move my records across.
Instead, I keep getting lectures about needing to read more. All the while, I
have suits watching what's going on and I'm making excuses as to why OS can
sometimes be a little problematic but that we'll get it working, don't worry.
The community needs to stop acting like know it all's and just help others,
wether they read or not otherwise, you just keep scaring folks who WILL
eventually spend more time learning about everything they touch once they
start being able to use it regularly.
You can all band together and keep telling me how wrong I am but I have plenty
of skills and simply don't have the time to learn everything I touch to the
enth degree. That's why I count on mailing lists and it's members so that I
can use and keep pushing the OPEN SOURCE that is almost a gift to us all.
Let's not ruin that uh? It gets old the greater than thou attitudes in open
source.
Mike
isp...@logicore.net
SURE that these things work.
I can't count how many times I've been told IM WRONG today alone when the
installer should have done all of these things FOR ME. I should have been
working on my configurations minutes after installing. This is not a ME
problem even if I am not truly well versed in installing a chrooted bind
server. Let's get it right so that we can fix these problems and see MANY more
using OS over being too nervous to use it.
isp...@logicore.net
>> together as primary/secondary?
>>
> Yes, I believe so. those keys are used to authenticate.
What I was wondering is;
I know the keys have to match on the server itself, named.conf and the key
file. I was not sure if they needed to match on the other servers as well,
such as secondary machines. If all machines need to have a matching key, not
just their own named.cond/key file.
Mike
Alan Clegg
>>> Should the rndc keys be the same across DNS servers which are working
>>> together as primary/secondary?
> I know the keys have to match on the server itself, named.conf and the key
> file. I was not sure if they needed to match on the other servers as well,
> such as secondary machines. If all machines need to have a matching key, not
> just their own named.cond/key file.
The keys used for rndc (in the named.conf and rndc.key) should not be
shared between multiple nameservers. If you wish to administer multiple
hosts from a single machine, you should make the keys for each
nameserver available to that machine.
You can do this with either individual key files or an rndc.conf
containing multiple keys/servers.
Alan
Alan Clegg
> Again, maybe the folks who put these RPM's and installers together should make
> SURE that these things work.
Agreed. They should write the code to the consumer's needs.
> I can't count how many times I've been told IM WRONG today alone when the
> installer should have done all of these things FOR ME. I should have been
> working on my configurations minutes after installing. This is not a ME
> problem even if I am not truly well versed in installing a chrooted bind
> server. Let's get it right so that we can fix these problems and see MANY more
> using OS over being too nervous to use it.
The ISC method of:
./configure; make; make install; {create configuration}; {run}
continues to work fine for many people, making few "too nervous to use it".
The need to understand the {create configuration} step and the
configuration's interaction with the {run} step is the complex part that
the creators of the RPMs and other install packages (including the *BSD
ports/packages, etc) are trying to keep their user away from.
You have run into an issue that is really outside the scope of BIND and
more in the scope of, as you noted, your installer package (RPM) that is
externally supported. Aside from Adam who had input earlier in the
thread (and is, I'm sure, still reading), I'm not aware of anyone on the
list that actually creates/supports the RPMs.
To help advance the open source agenda as you mentioned in other posts,
you should contact your operating system vendor and/or RPM supplier and
voice your concerns and provide input regarding the RPMs that you are
having trouble with.
If you are able to put together a good SELinux FAQ, I'll be more than
happy to make sure that it makes it into the ISC FAQ to which you were
pointed earlier.
Have a great afternoon,
AlanC
isp...@logicore.net
> shared between multiple nameservers. If you wish to administer multiple
Got it. That's what I figured since I did have transfers working before all of
this went haywire but could not recall. I'll remember this.
Much appreciated.
At this point, I'm going to uninstall and start over again. It looks like bind
and bind-chroot get installed together and mess things up. It turns out, this
is why I have mixed non and chrooted configurations as someone pointed out.
Hope someone who has anything to do with installers is reading this. I am
happy to reiterate if you'd like more information.
Mike
Alan Clegg
>> The keys used for rndc (in the named.conf and rndc.key) should not be
>> shared between multiple nameservers. If you wish to administer multiple
>
> Got it. That's what I figured since I did have transfers working before all of
> this went haywire but could not recall. I'll remember this.
Keys used for rndc are (well, should be) different from keys used during
transfer -- transfer only uses keys if you have configured TSIG.
AlanC
Baird, Josh
is a dependency of "bind-chroot."
I'm not sure why you are having so many problems.. I have deployed a lot
of bind-chroot'd installations without any problems whatsoever using
"yum install bind-chroot."
Once again, this is not in the scope of this list, so I will call it
quits here.
Josh
-----Original Message-----
From: bind-use...@isc.org [mailto:bind-use...@isc.org] On
Behalf Of isp...@logicore.net
Sent: Wednesday, December 05, 2007 3:18 PM
To: bind-users
Subject: Re: From RHEL to CentOS BIND 9
> The keys used for rndc (in the named.conf and rndc.key) should not be
> shared between multiple nameservers. If you wish to administer
multiple
Got it. That's what I figured since I did have transfers working before
all of
this went haywire but could not recall. I'll remember this.
Much appreciated.
isp...@logicore.net
OS is going to suffer if we don't make it easier to use. That's the bottom
line. I'm sick of finding 100% MS houses and I do all that I can to switch
them over to Linux. I have my hands on more technologies than most people get
to see so don't have the luxury of becoming n expert at everything that I
touch. I do however want to be able to count on the installers to get it right
so that I and my Linux/OS preaching don't end up looking ridiculous while the
MS guy's snicker at my problems.
> ./configure; make; make install; {create configuration}; {run}
> continues to work fine for many people, making few "too nervous to use it".
That was how I did it the first time. I built two machines, got the source,
worked through the deps and got them compiled but because of the SELinux
issue, I was not able to resolve the problem. I decided to go RPM so that the
next person to take over would only have to yum update to stay up to date for
a while and ended up with countless new nightmares.
I can't believe I had to go change permissions on directories after installing
such a mature product???
> You have run into an issue that is really outside the scope of BIND and
> more in the scope of, as you noted, your installer package (RPM) that is
Sort of but not really. I installed bind when I installed the server. I then
did an update and ended up with bind.chroot. I didn't even think about the
fact that the original was not chroot. So I ended up with weird configurations
that showed both non and chroot version configurations.
I'm not sure that this is or is not a bind issue, that should be taken up with
someone else I guess.
> thread (and is, I'm sure, still reading), I'm not aware of anyone on the
> list that actually creates/supports the RPMs.
I know it's not cool to use RPM's but again, it's great for folks who don't
have a lot of time, are trying to sell Linux as the solution so just want
something that'll work without having to become a guru at installing the
service, DNS in this case.
> To help advance the open source agenda as you mentioned in other posts,
> you should contact your operating system vendor and/or RPM supplier and
> voice your concerns and provide input regarding the RPMs that you are
> having trouble with.
Is there anyone in this list who might want to make notes of everything I've
had happen and then contact the right folks?
> If you are able to put together a good SELinux FAQ, I'll be more than
> happy to make sure that it makes it into the ISC FAQ to which you were
> pointed earlier.
Sure, it's short. Leave it OFF for default OS installations :).
I don't know but really, how hard would it have been for named to pop up a
notice that perhaps SELinux was enabled? That seems to be an RPM/packaging
issue.
All I know is that I still have a secondary to get up now. I hope it'll be
straight forward. Someone posted some good notes, I hope it'll go that easy
:).
Mike
isp...@logicore.net
I uninstalled both bind, bind-chroot and bind-utils as well.
I then re-installed bind-chroot and bind-utils, copied my files over, changed
the permissions to named.named and it worked.
I can't tell you why I'm having so many problems but if I am, I'm guessing I
can't be the only one. Makes me wonder how many just plain quit and you never
hear/know about it.
Mike
Mark Andrews
> Again, maybe the folks who put these RPM's and installers together should mak
> e
> SURE that these things work.
When they supply a example named.conf that have slaves zones
files in particular directories and you choose not to follow
the convention you need to know what you are doing.
Note: I'm very hesitant to impose naming conventions on filenames.
e.g.
all slave zones must be in /var/named/slave
SELinux decided that they knew better.
Mark
> I can't count how many times I've been told IM WRONG today alone when the
> installer should have done all of these things FOR ME. I should have been
> working on my configurations minutes after installing. This is not a ME
> problem even if I am not truly well versed in installing a chrooted bind
> server. Let's get it right so that we can fix these problems and see MANY mor
> e
> using OS over being too nervous to use it.
>
> Mike
>
>
> > Your BASIC file permissions are WRONG.
> >
> > The user "named" does not have write permission on
> > <chrootpath>/var/named. This is the working directory you
> > told named (directory "/var/named";) to use and it is the
> > starting point for any relative file name in named.conf.
> > "xxx.com" is a relative file name as is "tmp-sR5ej2BMG9".
> > Named opens it temporary files in the directory that it
> > going to rename the file to ("xxx.com" in this case). This
> > allows named to atomically replace master files using
> > "rename(2)".
> >
> > Mark
>
>
>
>
isp...@logicore.net
> files in particular directories and you choose not to follow
> the convention you need to know what you are doing.
Guess you've not been following along. I asked for help. I was told to
overwrite the install files with the old server's files. I did just that.
Plus, after I tidied up the file a little and removed some things which this
version doesn't seem to like, it came up just fine.
Not sure it is that I didn't know what I was doing other than the fact that
the installer didn't seem to work as expected.
Enough with the blaming uh? It's getting old :).
Mike
isp...@logicore.net
> The last thing we need is MS guy's snickering.
Off topic for just one second... ain't nothing worse than being at a meeting,
telling management that Linux can do the job better, the MS guy's giving you a
hard time.. and stuff not coming together as easily as you say it will when
it's time to show your stuff. Lordy!!! The MS guy's LOVE that.
> You said many emails above that the original RHEL *is* chroot. Now you are
> saying that the original is *not* chroot?
No, I but I need a beer badly so might not be writing what I'm thinking
anymore :). The RHEL version was chroot. The CentOS version was also chroot
*after* a yum update after a new install. Can't tell you why since I didn't
ask for it specifically, I just did yum update and only bind was installer at
that point, not bind-chroot.
> I turn the darn thing off on most of my installs as well. It's unfortunate
> though because the idea behind it is great from a security standpoint. Its
> just too dang hard to understand. 8^)
Sometimes, it's best to have a little less security up front, so that we can
install all that we need, then add the security as we start to tidy up the
system. Get's too complicated when too many things are turned on by default.
> Sounds like you got the primary up. Good Work dude!!!
Ya, looking at my watch, it's beer:30, the secondary will have to wait :).
>Dont get too frustrated with the guys on the list, they are doing their best
>to provide *free* support in their spare time. Trust me, they have pulled my
>arse outa the fire a time or two.
I'm not. I've been around since manual slackware installs. It is however
frustrating to see RTFM over and over again. One guy even accused me of not
wanting to read anything and asking the list first. Jeesus... WHO CARES! If
someone wants to ask the list before reading endless amounts of documentation,
so what? Help them before scaring them into feeling too stupid to try.
I'm just one of those guys who badly wants to see open source and Linux
continue to be what it is and can be. We'd all be calling MS support if it
weren't here.
End Soapbox-Beer time.
isp...@logicore.net
> As for setting up a slave, well, you'll need a similar named.conf as
> on the master (but with a different rndc configuration). Just change
> all the zone types from master to slave, and add a masters line to
Worked perfectly, as you stated, once I got the other things resolved.
Thanks much for the help and input.
Mike