Bug 1305519 - Named service does not conflict with named-chroot service
Named service does not conflict with named-chroot service
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: bind (Show other bugs)
7.2
All Linux
low Severity low
: rc
: ---
Assigned To: Tomáš Hozza
qe-baseos-daemons
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2016-02-08 08:37 EST by MarkS
Modified: 2016-02-09 06:02 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-02-09 04:51:28 EST
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)

  None (edit)
Description MarkS 2016-02-08 08:37:38 EST
Description of problem:
I can start named and named-chroot at the same time without conflict even though they clearly conflict as they utilise the same files (errors in logs relating to malformed transaction because serials didn't match).

Version-Release number of selected component (if applicable):
bind.x86_64                         32:9.9.4-29.el7_2.1
bind-chroot.x86_64                  32:9.9.4-29.el7_2.1


How reproducible:
Every time


Steps to Reproduce:
1. systemctl start named-chroot
2. systemctl start named


Actual results:
Two named daemons running in conflict with one another.


Expected results:
For the second named to start to known itself to be in conflict with the first.


Additional info:
I think simply adding "Conflicts=named.service" would be appropriate to add to the service definition.
Comment 2 Tomáš Hozza 2016-02-09 04:51:28 EST
The thing is that you could have the chrooted instance running with different configuration and actually on different address and/or port.

I agree that in the default configuration, when you just install both packages, you are able to start both variants of BIND and one of them (the second) will fail.

However one can have a different configuration file in the /var/named/chroot/etc/ and in that case, it is used. I know that couple of users are actually doing this. I'm not sure how many people run two instances of BIND on the same system (one in chroot, the other outside of it), however adding the conflict into the service file would just introduce artificial constrains for some of the users.

I'm closing this as WONTFIX as I don't think we should add artificial constrains that would prohibit potentially valid use cases.
Comment 3 MarkS 2016-02-09 05:24:37 EST
Sorry to poke a closed bug but I do not believe it is true that you can have different configurations.

On the system that I have (RHEL7) I can see that the directories have been "mount --bind".

e.g.
/dev/mapper/VolGroup00-lv_root on /var/named/chroot/etc/localtime
/dev/mapper/VolGroup00-lv_root on /var/named/chroot/etc/named
/dev/mapper/VolGroup00-lv_root on /var/named/chroot/etc/named.root.key
/dev/mapper/VolGroup00-lv_root on /var/named/chroot/etc/named.conf
/dev/mapper/VolGroup00-lv_root on /var/named/chroot/etc/named.rfc1912.zones
/dev/mapper/VolGroup00-lv_root on /var/named/chroot/etc/rndc.key
/dev/mapper/VolGroup00-lv_root on /var/named/chroot/usr/lib64/bind
/dev/mapper/VolGroup00-lv_root on /var/named/chroot/etc/named.iscdlv.key
tmpfs on /var/named/chroot/run/named type tmpfs
/dev/mapper/VolGroup00-lv_root on /var/named/chroot/var/named

Thanks
Mark
Comment 4 MarkS 2016-02-09 05:29:17 EST
Found that the "mount --bind" is documented:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Networking_Guide/sec-BIND.html

But I also note it has some check to determine if the directories are empty before using "mount --bind" which I was unaware of.

Quoting
"The following directories are automatically mounted into the /var/named/chroot/ directory if the corresponding mount point directories underneath /var/named/chroot/ are empty"

Not sure if there is any successful logic that can be wrapped on that, or indeed if there should be any at all.
Comment 5 Tomáš Hozza 2016-02-09 06:02:34 EST
So the bottom line as you've already found out is, that you can have a completely different configuration, in case you placed all the directories and files into the /var/named/chroot/ directory.

In case some of the important files/directories are not present in /var/named/chroot/, then these are bind-mounted which would result in some of the configuration and directories being shared between the instances of BIND (which may be a problem, but not necessarily).

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