Bug 1271315 - bind/named service file targets /etc/named.conf always, instead of targeting modified name for config
bind/named service file targets /etc/named.conf always, instead of targeting ...
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: bind (Show other bugs)
7.1
x86_64 Linux
medium Severity medium
: rc
: ---
Assigned To: Petr Menšík
Petr Sklenar
: Documentation, FastFix
Depends On:
Blocks: 1298243 1400961
  Show dependency treegraph
 
Reported: 2015-10-13 11:33 EDT by jcastran
Modified: 2017-08-01 16:40 EDT (History)
3 users (show)

See Also:
Fixed In Version: bind-9.9.4-46.el7
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-08-01 16:40:58 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
example systemd service extension (454 bytes, text/plain)
2017-03-28 11:38 EDT, Petr Menšík
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2017:1767 normal SHIPPED_LIVE bind bug fix update 2017-08-01 14:30:50 EDT

  None (edit)
Description jcastran 2015-10-13 11:33:18 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):
bind-9.9.4-18.el7_1.3.x86_64
bind-chroot-9.9.4-18.el7_1.3.x86_64
bind-libs-9.9.4-18.el7_1.3.x86_64
bind-libs-lite-9.9.4-18.el7_1.3.x86_64
bind-utils-9.9.4-18.el7_1.3.x86_64
bind-0.2.0-26.el7.x86_64
bind-license-9.9.4-18.el7_1.3.noarch


How reproducible:
Every time

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

Actual results:
4. systemctl status named
   > rhel7_0 named-checkconf[###]: open: /etc/named.conf: file not found
5. Service fails to start


Expected results:
4. named-checkconf reads /etc/sysconfig/named, verifies custom file name
5. service starts

Additional info:
*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.
Comment 2 Tomáš Hozza 2015-10-14 05:14:52 EDT
Hello

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 [1]. Changing the location of the configuration is one of such changes.

[1] https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7-Beta/html/System_Administrators_Guide/sect-Managing_Services_with_systemd-Unit_Files.html#sect-Managing_Services_with_systemd-Unit_File_Modify

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.
Comment 3 jcastran 2015-10-14 10:59:28 EDT
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. 

Resolutions:

-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:

[1] https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7-Beta/html/System_Administrators_Guide/sect-Managing_Services_with_systemd-Unit_Files.html#sect-Managing_Services_with_systemd-Unit_File_Modify
Comment 6 Tomáš Hozza 2016-01-06 03:44:43 EST
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.
Comment 10 Petr Menšík 2017-03-28 11:38 EDT
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
Comment 14 errata-xmlrpc 2017-08-01 16:40:58 EDT
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.

https://access.redhat.com/errata/RHBA-2017:1767

Note You need to log in before you can comment on or make changes to this bug.