Bug 1034219

+++ This bug was initially created as a clone of Bug #1031557 +++

Description of problem:

If engine-setup changed /etc/exports (to add an iso domain), engine-cleanup will remove it.

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


How reproducible:
Always

Steps to Reproduce:
1. Make sure you do not have /etc/exports.d and do have /etc/exports
2. engine-setup
3. engine-cleanup

Actual results:

/etc/exports is removed

Expected results:

/etc/exports should not be removed. Ideally it should probably have the same content it had before engine-setup.

Additional info:

On recent fedora, there is /etc/exports.d, and engine-setup adds a file there, and cleanup removes it. Still, if /etc/exports.d is removed and /etc/exports is used instead, the bug applies. el6 does not support /etc/exports.d so it always applies there.

--- Additional comment from Sandro Bonazzola on 2013-11-19 09:46:18 IST ---

patch merged on upstream master and 3.3 branches

--- Additional comment from Yedidyah Bar David on 2013-11-25 12:17:20 IST ---

After discussing this with Sefi who failed to reproduce, I think the bug actually affects only fedora, or, for that matter, systems with /etc/exports.d .

I think (but did not try to reproduce) that a scenario that can reproduce is:

1.
Do not have /etc/exports.d
Do not have /var/lib/exports/iso*
engine-setup, configure iso domain
engine-cleanup
rm -rf /var/lib/exports/iso (if not deleted by cleanup)

This leaves /etc/exports with /var/lib/exports/iso

2.
mkdir /etc/exports.d
engine-setup

This deletes /var/lib/exports/iso from /etc/exports and adds it to a file under /etc/exports.d .

This is done in the function _delete_path, which prior to http://gerrit.ovirt.org/20715 did not mark the file to be unremovable.

3.
engine-cleanup

This will delete /etc/exports.

It might have happened to me with a somewhat less complex scenario, involving a 3.2 setup (which edited /etc/exports) and upgrade to 3.3 or something like that.
I did not manage to find clear backups that show how it happened, although I am definitely certain it did happen :-)

In any case, it's quite unlikely to happen on a clean el6 machine, and also not very likely on fedora.

Still, the fix is trivial - it literally just marks the file unremovable, so that engine-cleanup will not delete the file, in a certain flow that otherwise could have deleted it - and I think we can leave it in even if reproduction is complex.