Bug 1613219

re-targeting to 4.3.1 since this BZ has not been proposed as blocker for 4.3.0.
If you think this bug should block 4.3.0 please re-target and set blocker flag.

Note to QE - verification:

engine-setup maintains a set of "uninstall" files in /etc/ovirt-engine/uninstall.d .

It keeps there two kinds of information:

- For files we (re)write completely - we keep file name and hash
- For files we edit in-place - we keep added and removed lines

This was used by engine-cleanup (and ovirt-engine-rename) to check if it's safe to
remove (rewrite) config files.

engine-setup itself did not check them, and also now does not change its logic
based on what it finds there - except for adding some information to the log -
search there for:

    OVESETUP_CORE/uninstallFilesInfo
    OVESETUP_CORE/uninstallLinesInfo

and for:

    The following files were changed outside of engine-setup:

Until 4.2, it used MD5 for the hash algorithm.

Now it uses SHA256.

It does support upgrades from older setups, and correctly handles information
including MD5 hashes. In particular, we do not rewrite existing files, thus
currently you can't eliminate use of MD5 on upgraded systems, unless you manually
update the uninstall files. This means we do not support upgrading from a non-fips-
compliant existing 4.2 setup to a fips-compliant 4.3 setup.

For verification, you should check two things, mainly:

1. That for newly-written files we keep SHA256. This applies both to new setups
(where all files are new) and to ugprades - for that, you can e.g. manually edit
one file after 4.2 setup, then upgrade to 4.3.

2. That the logic for checking changes etc. still works, also if same file was
edited multiple times, both by engine-setup and manually.

Copying from [1] the verification steps I used there, for reference. Feel free
to come up with more complex flows.

Did the following:

Installed master (unpatched) engine

engine-setup

engine-setup --offline again, to see that it didn't update stuff

manually edited /etc/ovirt-engine/engine.conf.d/10-setup-jboss.conf

engine-setup --offline again, to see that it backs up and overwrites that file

Applied current patch

engine-setup --offline - didn't change stuff

manually edited /etc/ovirt-engine/engine.conf.d/10-setup-jboss.conf

engine-setup --offline - it backs up and overwrites that file

engine-setup --offline - didn't change stuff

engine-cleanup - it correctly removed /etc/ovirt-engine/engine.conf.d/10-setup-jboss.conf

I also checked engine-setup logs to see that the code checking the hashes worked as expected. This does not change the logic of deciding whether to overwrite a conf file (that one checks the entire content with the expected content, unrelated to hashes). So the main verification here is in 'engine-cleanup' in the end (and in checking the logs).

[1] https://gerrit.ovirt.org/#/c/96193/

I do not think current bug needs doc text, as it's not enough, in itself, for fips support.
Once we add fips support, we can also briefly mention it.

If interested, see previous comment for details about the changes it introduces.

Clarification for comment 2: At the time, master was identical (mostly) with 4.2. So when I refer to "unpatched master", use 4.2, and "applied current patch" means use 4.3.

*** This bug has been marked as a duplicate of bug 1660378 ***