BIND named not starting in chroot

opensuse v13.1
BIND 9.9.4-rpz2.13269.14-P2

I just upgraded a server from 12.3 to 13.1. It would have been a mostly smooth upgrade had <named> started as it should have. It no longer starts in a chroot. I am currently running it simply as root.

/usr/sbin/named -t /var/lib/named -u named

The error messages regarding its failure to start are: “Failed to start.”

I tried the “-g” option. No further info regarding the failure. There was this:

140585420077056:error:0200100D:system library:fopen:Permission denied:bss_file.c:173:fopen('/etc/ssl/openssl.cnf','rb')
140585420077056:error:2006D002:BIO routines:BIO_new_file:system lib:bss_file.c:178:
140585420077056:error:0E078002:configuration file routines:DEF_LOAD:system lib:conf_def.c:199:

There is no issue with </var/lib/named/etc/ssl/openssl.cnf>. It has the same permissions, owner, group, size, date, blah-blah-blah, as /etc/ssl/openssl.cnf, which can be opened when starting native. The other error messages mean nothing to me given the lack of useful detail.

I could try the “-d” option. Only I do not know what the range of <debug-level> is. 0 - 5? -100 to +1000?

Any ideas what is wrong?

I doubt the problem as you described has anything to do with networking.
This should probably have been posted in either Applications or Virtualization forums, maybe Install.

Without a full description of what is in chroot, it’s impossible to guess what is the issue… ie when doing a chroot, you can specify any mount points and also possibly share mount points with the Host. So, whatever your mix is probably relevant to whatever is your problem.

One alternative to creating a whole different copy of /etc/* is to do a bind mount.

You might also try to determine if the files’ permissions or the security context accessing the files might be the issue by removing the existing chrooted copies and create new.

Also, chroot is very well known to have a number of security issues with a minimal implementation, so additional steps are generally recommended to tighten up security. If you have done any of these, they can also be relevant.

You should know that with the implementation of systemd, we now have an alternative to the basic chroot which automatically tightens up security/isolation without additional configurations by the use of namespaces which is called systemd-nspawn. Take a look at it, it’s very simple to invoke. You might even be able to invoke without changing your existing file structure.


On 6/2/2014 1:26 AM, jimoe666 wrote:
> /usr/sbin/named -t /var/lib/named -u named
> The error messages regarding its failure to start are: “Failed to
> start.”
> Any ideas what is wrong?

apparmor ???

“We’re all in this together, I’m pulling for you” Red Green