websavers
Regular Pleskian
I completed a fresh install of Cent OS 7 on an OpenVZ container and updated it with standard system and Atomic RPMs. I then installed Plesk using the command-line utility and configured all services as I've done dozens of times with Plesk 11.5.
After adding a domain (or migrating one) I couldn't get Bind to start and it was throwing the following errors when running `service named restart`:
At first I thought permissions issue, but the permissions seemed to be OK upon comparing to other Plesk boxes.
It seems that specifying the directory value in /etc/named.conf to simply "/var" fails to function, even though named is supposed to be loading within a chrooted jail with rootdir of /var/named/chroot and therefore /var should refer to /var/named/chroot/var.
When I edited /etc/named.conf and changed the directory line to the following, then ran `service named restart`, bind loaded fine:
This raises the questions:
1. Is CentOS 7 passing in the path before the named process is jailed to the chroot?
2. Is chroot working at all if I have to use an absolute value like that? And if not, then isn't that a security risk for the named process?
3. If #2 is true, then how do I get chroot working again?
The notes at the top of /etc/sysconfig/named seem to indicate that as long as we've got the following specified, then the process is chrooted. If that's true, why does /etc/named.conf require an absolute path that would only work if the process is *not* chrooted?
Also, if you guys already seem to know about this problem, why do none of those threads have a clear-cut solution and why isn't it fixed in the Plesk 12 installer yet? It's been a few months now...
---
UPDATE / SOLUTION
Seemingly with Cent OS 7, when you wish to run bind chrooted, rather than simply reading in a configuration parameter (-t) when you wish to run it chrooted, a completely separate initscript was created called named-chroot. Therefore the command to start named chrooted is: systemctl start named-chroot NOT systemctl start named or service named start.
While I suppose this could allow greater flexibility in choosing to start named with or without chroot enabled, in the end it's more confusing than useful. Firstly, expected behaviour (ie: `service named restart` type control) is destroyed and then even if you wanted the power to change the chroot behaviour simply by switching the systemctl command, you can't that easily because the config file needs to be adjusted to support it!
Therefore I would suggest having the Plesk installer and/or dns repair tool save a copy of the named initscript and symlink it to named-chroot.
After adding a domain (or migrating one) I couldn't get Bind to start and it was throwing the following errors when running `service named restart`:
-- Logs begin at Sun 2015-02-01 06:39:11 EST, end at Sun 2015-02-01 12:39:48 EST. --
Feb 01 12:39:48 named-checkconf[14522]: _default/{DOMAIN1}/IN: file not found
Feb 01 12:39:48 named-checkconf[14522]: zone {DOMAIN2}/IN: loading from master file {DOMAIN2} failed: file not found
Feb 01 12:39:48 named-checkconf[14522]: zone {DOMAIN2}/IN: not loaded due to errors.
Feb 01 12:39:48 named-checkconf[14522]: _default/{DOMAIN2}/IN: file not found
Feb 01 12:39:48 named-checkconf[14522]: zone {IP}.in-addr.arpa/IN: loading from master file {IP}.in-addr.arpa failed: file not found
Feb 01 12:39:48 named-checkconf[14522]: zone {IP}.in-addr.arpa/IN: not loaded due to errors.
Feb 01 12:39:48 named-checkconf[14522]: _default/{IP}.in-addr.arpa/IN: file not found
Feb 01 12:39:48 systemd[1]: named.service: control process exited, code=exited status=1
Feb 01 12:39:48 systemd[1]: Failed to start Berkeley Internet Name Domain (DNS).
-- Subject: Unit named.service has failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit named.service has failed.
--
-- The result is failed.
At first I thought permissions issue, but the permissions seemed to be OK upon comparing to other Plesk boxes.
It seems that specifying the directory value in /etc/named.conf to simply "/var" fails to function, even though named is supposed to be loading within a chrooted jail with rootdir of /var/named/chroot and therefore /var should refer to /var/named/chroot/var.
When I edited /etc/named.conf and changed the directory line to the following, then ran `service named restart`, bind loaded fine:
Code:
directory "/var/named/chroot/var";
This raises the questions:
1. Is CentOS 7 passing in the path before the named process is jailed to the chroot?
2. Is chroot working at all if I have to use an absolute value like that? And if not, then isn't that a security risk for the named process?
3. If #2 is true, then how do I get chroot working again?
The notes at the top of /etc/sysconfig/named seem to indicate that as long as we've got the following specified, then the process is chrooted. If that's true, why does /etc/named.conf require an absolute path that would only work if the process is *not* chrooted?
ROOTDIR="/var/named/chroot"
Also, if you guys already seem to know about this problem, why do none of those threads have a clear-cut solution and why isn't it fixed in the Plesk 12 installer yet? It's been a few months now...
---
UPDATE / SOLUTION
Seemingly with Cent OS 7, when you wish to run bind chrooted, rather than simply reading in a configuration parameter (-t) when you wish to run it chrooted, a completely separate initscript was created called named-chroot. Therefore the command to start named chrooted is: systemctl start named-chroot NOT systemctl start named or service named start.
While I suppose this could allow greater flexibility in choosing to start named with or without chroot enabled, in the end it's more confusing than useful. Firstly, expected behaviour (ie: `service named restart` type control) is destroyed and then even if you wanted the power to change the chroot behaviour simply by switching the systemctl command, you can't that easily because the config file needs to be adjusted to support it!
Therefore I would suggest having the Plesk installer and/or dns repair tool save a copy of the named initscript and symlink it to named-chroot.
Last edited: