RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1118849 - Editing named-chroot config files with 'vim' when 'backupcopy' set to 'auto' or 'no' breaks mount-binding of the edited files.
Summary: Editing named-chroot config files with 'vim' when 'backupcopy' set to 'auto' ...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: doc-Networking_Guide
Version: 7.0
Hardware: All
OS: All
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Stephen Wadeley
QA Contact: ecs-bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-07-11 16:59 UTC by Jim N.
Modified: 2019-03-06 02:20 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-09-17 14:30:54 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Jim N. 2014-07-11 16:59:01 UTC 
Description of problem:

When using named-chroot, various configuration and runtime files setup into the named chroot area via a set of 'mount --bind' calls.  This works fine.

However, section "12.2.2. Configuring the named Service" of the Networking Guide states the following in its notes:

---- start of excerpt ----
If you have installed the bind-chroot package, the BIND service will run in the /var/named/chroot environment. In that case, the initialization script will mount the above configuration files using the mount --bind command, so that you can manage the configuration outside this environment. There is no need to copy anything into the /var/named/chroot directory because it is mounted automatically. This simplifies maintenance since you do not need to take any special care of BIND configuration files if it is run in a chroot environment. You can organize everything as you would with BIND not running in a chroot environment.
---- end of excerpt ----

Attempts to test the editability of config files inside and outside the chroot'ed environment with the vim editor revealed that changes made to either set did not appear in the other.  E.g. Changes made to '/etc/named.conf' did not appear in /var/named/chroot/etc/named.conf', and vice-versa.

This was eventually tracked down to (expected and proper) vim behaviour.  By default as shipped with RHEL 7, the vim option "backupcopy" is set to "auto".  In this mode, when vim edits a file the original file is renamed, and changes are written to a new file (inode), essentially breaking the mount-binding.  If the vim option "backupcopy=yes" is instead set, then vim will copy the original file to a backup, and save changes to the original file, preserving the mount-binding.

This will presumably happen with any other editor/method beyond vim should they use a similar "edit-a-copy" approach to backups.

Everything is functioning as intended.  However, a quick note regarding this pitfall and perhaps some suggestions in the documentation would go a long way towards avoiding confusion.


Version-Release number of selected component (if applicable):


How reproducible:

Every time.

Steps to Reproduce:
1. Start BIND via the "named-chroot" service.
2. Make a change to '/etc/named.conf' with vim, with vim's "backupcopy" option set to "auto" as shipped by-default with RHEL 7, or as "no".
3. Observe that change has not propagated to '/var/named/chroot/etc/named.conf'.

Actual results:
Changes made to either the original or chroot'ed file are not propagated to the other.

Expected results:
As both files reference the same inode, changes made to one should appear in both.

Additional info:
Comment 2 Stephen Wadeley 2014-07-14 09:58:41 UTC 
Hello Jim


Thank you for taking the time to raise this bug.
Comment 5 Stephen Wadeley 2014-07-25 15:02:04 UTC 
Proposed change
-------------------------

Important
Editing files which have been mounted in a chroot environment requires using an editor in “edit-a-copy” mode or alternatively creating a backup copy, editing the backup copy, and then overwriting the original file with a copy of the newly edited file. For example, to edit the BIND's configuration file, /etc/named.conf, with Vim while it is running in a chroot environment, issue the following command as root:

~]# vim --backupcopy="yes" /etc/named.conf

-----------------------------------------------
Comment 7 Tomáš Hozza 2014-07-28 09:16:24 UTC 
(In reply to Stephen Wadeley from comment #5)
> Proposed change
> -------------------------
> Important
> Editing files which have been mounted in a chroot environment requires using
> an editor in “edit-a-copy” mode

I think we misunderstood each other. The editor should not be in "edit-a-copy"
mode. It should be "make a copy and edit the original file".

This is exactly what backupcopy=yes does:

Making a copy and overwriting the original file:
	- Takes extra time to copy the file.
	+ When the file has special attributes, is a (hard/symbolic) link or
	  has a resource fork, all this is preserved.
	- When the file is a link the backup will have the name of the link,
	  not of the real file.


> or alternatively creating a backup copy,
> editing the backup copy, and then overwriting the original file with a copy
> of the newly edited file.

No, this won't work. Should be "or alternatively creating a backup copy and editing the original file."

> For example, to edit the BIND's configuration
> file, /etc/named.conf, with Vim while it is running in a chroot environment,
> issue the following command as root:
> 
> ~]# vim --backupcopy="yes" /etc/named.conf

Should be (the above does not work):

~]# vim -c "set backupcopy=yes" /etc/named.conf

> 
> -----------------------------------------------
Comment 9 Stephen Wadeley 2014-07-31 13:28:27 UTC 
Hello Tomas

Thanks for the correction.

So, I propose:

Editing files which have been mounted in a chroot environment requires creating a backup copy and then editing the original file. Alternatively, use an editor with “edit-a-copy” mode disabled. For example, to edit the BIND's configuration file, /etc/named.conf, with Vim while it is running in a chroot environment, issue the following command as root:

~]# vim -c "set backupcopy=yes" /etc/named.conf

-----------------

Please approve or other wise give further feedback.


Thank you
Comment 10 Tomáš Hozza 2014-08-04 08:22:49 UTC 
(In reply to Stephen Wadeley from comment #9)
> Hello Tomas
> 
> Thanks for the correction.
> 
> So, I propose:
> 
> Editing files which have been mounted in a chroot environment requires
> creating a backup copy and then editing the original file. Alternatively,
> use an editor with “edit-a-copy” mode disabled. For example, to edit the
> BIND's configuration file, /etc/named.conf, with Vim while it is running in
> a chroot environment, issue the following command as root:
> 
> ~]# vim -c "set backupcopy=yes" /etc/named.conf
> 
> -----------------
> 
> Please approve or other wise give further feedback.

Looks good.

Thank you!
Comment 15 Stephen Wadeley 2014-09-17 14:30:54 UTC 
Dear All

Fixed in version
Red_Hat_Enterprise_Linux-Networking_Guide-7-web-en-US-0.9-9

See:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Networking_Guide/sec-BIND.html#sec-bind-namedconf


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