+++ 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.
Cloned to ovirt for testing on fedora.
Verified on Fedora 19 ovirt-engine-3.3.1-2.fc19.noarch