Bug 1305519

Summary:	Named service does not conflict with named-chroot service
Product:	Red Hat Enterprise Linux 7	Reporter:	MarkS <mark>
Component:	bind	Assignee:	Tomáš Hozza <thozza>
Status:	CLOSED WONTFIX	QA Contact:	qe-baseos-daemons
Severity:	low	Docs Contact:
Priority:	low
Version:	7.2
Target Milestone:	rc
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-02-09 09:51:28 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description MarkS 2016-02-08 13:37:38 UTC

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 09:51:28 UTC

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 10:24:37 UTC

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 10:29:17 UTC

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 11:02:34 UTC

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).