Red Hat Bugzilla – Bug 1271315
bind/named service file targets /etc/named.conf always, instead of targeting modified name for config
Last modified: 2017-08-01 16:40:58 EDT
Description of problem:
When using a different config file name for /etc/named.conf, and with /etc/sysconfig/named including the "-c /etc/named9.conf" so named knows of the custom file. The service is unable to start due to the following in /usr/lib/systemd/system/named.service:
ExecStartPre=/usr/sbin/named-checkconf -z /etc/named.conf
ExecStart=/usr/sbin/named -u named $OPTIONS
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. mv /etc/named.conf /etc/named9.conf
2. echo 'OPTIONS="-c /etc/named9.conf"' >> /etc/sysconfig/named
3. systemctl start named
4. named starts with /etc/named9.conf
4. systemctl status named
> rhel7_0 named-checkconf[###]: open: /etc/named.conf: file not found
5. Service fails to start
4. named-checkconf reads /etc/sysconfig/named, verifies custom file name
5. service starts
*Creating a soft link "ln -s /etc/named9.conf /etc/named.conf will resolve this issue
*Modifying /usr/lib/systemd/system/named.service so that the "ExecStartPre" line points to the correct file.
This is expected behavior.
If customer wants to change the name of the configuration file, they should copy the service file to /etc/systemd/system and modify the service file there. This means defining the '-c' option in ExecStart and also changing the ExecStartPre section. This is the only valid approach when they need such change.
To be honest, /etc/sysconfig/named stayed in RHEL mostly for historical reasons. The fact that you can change the configuration path is more of a side effect, than an intended behavior.
The check of the configuration before starting named is a distribution thing and is Red Hat specific. named-checkconf is part of the upstream project and therefore modifying it to read /etc/sysconfig/named is not an option, because upstream would never accept such change.
From my point of view there is not much to fix, except maybe to provide better documentation. Although the fact that if administrator needs to modify the the service file, they should do it in one of the supported ways. This is covered by System Administrators Guide . Changing the location of the configuration is one of such changes.
Please communicate these facts to the customer. I'll leave the bug opened until the issue is resolved/communicated with the customer.
I'm lowering the severity, since there is an easy workaround (which is in fact the right way to address such problem).
Note: 7.2 update will include fix for #1236475 which will allow one to disable the named-checkconf check. However I believe this is not what the customer wants.
I understand and have conveyed that message to the customer.
Perhaps we need to add a warning to /etc/sysconfig/named. Or remove the "-c" as a valid option since it prevents the service from running.
There is already one for "ROOTDIR" since you can't use that option, it has its own syntax.
Possibly something along the lines of:
"Using the -c option to specify a different configuration file is not supported"
*This is the intended method of using this file. But using it with the "-c" option, does not allow the service to start.
-Create a softlink (ln -s /etc/customnamed.conf /etc/named.conf) needs to be created so /etc/named.conf is still there.
-Modify the service file to account for the custom named.conf, per the instructions below:
Just a small comment, that the customer can easily use also systemd drop-in in a similar way as described in Bug #1278082 comment #13. I think this is the cleanest solution.
Created attachment 1267015 [details]
example systemd service extension
Example configuration extension for named systemd services. Place it into /etc/systemd/system/$SVC.service.d/custom-config.conf.
$SVC can be one of: named named-pkcs11 named-sdb named-chroot
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.