Bug 480156

Summary:	zonefile gets deleted when too many symlinks are used
Product:	Red Hat Enterprise Linux 5	Reporter:	Jens Kuehnel <redhat-bugzilla>
Component:	bind	Assignee:	Adam Tkac <atkac>
Status:	CLOSED NOTABUG	QA Contact:	BaseOS QE <qe-baseos-auto>
Severity:	high	Docs Contact:
Priority:	low
Version:	5.2	CC:	bugzilla-redhat, ovasik, ralph, rvokal, urcentral
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:	2009-07-16 13:36:33 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Jens Kuehnel 2009-01-15 13:39:13 UTC

Description of problem:
For convenience I added a symlink from /var/named/data to /var/named/chroot/var/named/data.
When using symlinks inside /var/named/chroot/var/named/data the targetfile will be delete when updating the bind package.

Version-Release number of selected component (if applicable):
Happened earlier. Tested with update from
bind-9.3.4-6.P1.el5.x86_64
bind-utils-9.3.4-6.P1.el5.x86_64
bind-chroot-9.3.4-6.P1.el5.x86_64
caching-nameserver-9.3.4-6.P1.el5.x86_64
to
bind-9.3.4-6.0.3.P1.el5_2.x86_64
bind-utils-9.3.4-6.0.3.P1.el5_2.x86_64
bind-chroot-9.3.4-6.0.3.P1.el5_2.x86_64
caching-nameserver-9.3.4-6.0.3.P1.el5_2.x86_64

How reproducible:
Happened twice by accident on my homeserver, and was reproduced on a test system. I guess thats count a YES.

Steps to Reproduce:
1. Install older version of bind packages.
2. create symlinks with "cd /var/named ; rmdir data ; ln -s chroot/var/named/data"
3. create two zones (zonea and zoneb) in named.conf.
4. create zonefile for zonea.file and one symlink from zoneb.file to zonea.file.
5. update to new bind version
6. restart named

Actual results:
zonefile for zonea is replaced with a symlink to /var/named/chroot//var/named/data/zonea.file
Hope you have a backup or access to the slaveserver.

Expected results:
zonefile should be there.

Additional info:
At the moment I delete the symlink from /var/named/data to /var/named/chroot/var/named/data. That fixed the bug. But I'm pretty sure I'm not alone who want's to create the shortcut.

Comment 4 Adam Tkac 2009-07-16 12:12:02 UTC

/var/named/data directory is not intended for zone files, it should be used for named runtime data only. You should not replace it by symlink because it is part of "standard" Red Hat BIND configuration layout.

If you would like to create a zone file which is writable (I think this is main reason why you would like to put a zone file to the "data" subdirectory) then you have two cases:

1. put secondary zone to the "slaves" subdirectory
2. put DDNS zone to the "/var/named" directory and check named(8) manual page, section called "Red Hat SELinux BIND Security Profile" how to make /var/named writable by named process.

Could I ask you why would you like to create a zoneb as a symlink to zonea file, please? If you would like to share one file for multiple zones you could simply specify same "file ...;" directive for multiple zones in named.conf.

I don't think this is a bug.

Comment 6 Ludek Smid 2009-07-16 13:02:34 UTC

Approved de-commit of the patch from RHEL 5.4.

Contact Global Support Services for escalation of your request if needed.

Comment 8 Jens Kuehnel 2009-07-30 08:07:59 UTC

Hi,

I used 1 masterzonefile, and have my other zonefiles as sysmlink to my master. That way it's easier for me if I have to make changes to all zones. If I need to make changes to only one zone I delete the symlink and replaces it with a copy.

I changed my setup already, but an rpm upgrade that deletes files, seems wrong to me.

CU
Jens Kühnel

Comment 9 Adam Tkac 2009-08-14 08:39:13 UTC

*** Bug 517279 has been marked as a duplicate of this bug. ***

Comment 10 Joni 2009-08-14 10:44:10 UTC

An update should never overwrite customer data, or leave circular symlinks in my humble opinion. Reopening the duplicate.