Glenn English wrote:
> root@srv:~# ps -ef | grep named
> bind 2098 1 0 May10 ? 00:00:36 /usr/sbin/named -u bind
> root 10498 1 0 May10 ? 00:00:50 /usr/sbin/named -c /etc/bind/named.conf
There are two of them running? That doesn't seem right. The first
one looks okay but the second one does not.
I would be inclined to kill both of them. Then start it up again and
check all over again.
service bind9 stop
ps -ef | grep named
kill 10498
ps -ef | grep named
Make sure none are running. Then start it up again and check.
service bind9 start
Did you by any chance configure bind9 to run in a chroot?
> > If it isn't that then I would suspect selinux has become enabled but
> > not fully configured.
>
> I'm game. How do I find out/configure it?
If you haven't heard of it then it isn't enabled. I wouldn't suggest
enabling it. If you haven't heard of it then I think it is not likely
to be the problem.
> root@srv:~# ps aux | egrep -i selinux
> root 13013 0.0 0.0 7828 900 pts/0 S+ 15:48 0:00 egrep -i selinux
>
> If it's running, it doesn't have a pid. I don't really know what
> SELinux is. I've heard it's a collection of patches to the kernel,
> but that's all I know.
selinux stands for security-enhanced-linux and is a policy layer where
everything is controlled by access control lists. It completely
changes the traditional security system. It isn't a daemon.
> I grepped the /etc/default files for selinux. Nothing.
>
> I grepped the /etc/init.d startup files. I found 'selinux-enabled' in the checkroot.sh file (if selinux-enabled ...). selinux-enabled is a small function in /lib/lsb/init-functions.sh:
>
> selinux_enabled () {
> which selinuxenabled >/dev/null 2>&1 && selinuxenabled
> }
>
> 'which selinuxenabled' says there's no such file here. So does
> 'root@srv:/boot# find / -iname "*selinuxenabled*""
That command is in the selinux-utils package. You don't have it.
Making it unlikely that you would have selinux blocking you. (No need
to install it.)
The next thing I would wonder is if the 'immutable' bit were set on
the file system. Again from my system.
$ lsattr -d /var/cache/bind
---------------- /var/cache/bind
(You can read about it in the 'man chattr' man page.)
> This is happening on Dell, Supermicro, and RaspberryPi boxes, all
> running Wheezy with default, and updated, kernels, FWIW. The lone
> Lenny server doesn't seem to have troubles.
It happens on multiple systems? Oh my that is a problem. I am afraid
I am running out of ideas. If it isn't normal user permissions, isn't
selinux, isn't ext immutable then I don't know what it would be. It
isn't normal. I am running bind9 on similar random architectures and
systems and I have not run into any problems caching files there.
If all else fails I would be inclined to try an experiment. I would
open up the permissions on /var/cache/bind to be drwxrwxrwx and then
start bind9 and see what files it produces there. The owner and group
of the files produced should be a clue. They should be "bind" but if
they were something else that would explain the permission denied
message and be a clue as to the problem.
service bind9 stop
chmod a+rwx /var/cache/bind
service bind9 start
ls -la /var/cache/bind
Bob
Attachment:
signature.asc
Description: Digital signature