Bug 480156 - zonefile gets deleted when too many symlinks are used
zonefile gets deleted when too many symlinks are used
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: bind (Show other bugs)
5.2
All Linux
low Severity high
: rc
: ---
Assigned To: Adam Tkac
BaseOS QE
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-01-15 08:39 EST by Jens Kuehnel
Modified: 2013-04-30 19:42 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-07-16 09:36:33 EDT
Type: ---
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 Jens Kuehnel 2009-01-15 08:39:13 EST
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 08:12:02 EDT
/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 09:02:34 EDT
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 04:07:59 EDT
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 04:39:13 EDT
*** Bug 517279 has been marked as a duplicate of this bug. ***
Comment 10 Joni 2009-08-14 06:44:10 EDT
An update should never overwrite customer data, or leave circular symlinks in my humble opinion. Reopening the duplicate.

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