Skip to content

Conversation

@peter-boden
Copy link
Member

@peter-boden peter-boden commented Oct 27, 2025

Changes introduced with this PR

This is the improved version of #1072 , which can probably be closed now.
And this also makes #932 obsolete.

  • Auto migrate p12 files that use legacy encryption
  • Introduce an install_root in engine-backup, makes backups portable between dev and production environments (also allows taking backups from production environments that are not installed in the default location)
  • Remove obsolete flag during cert enrollment
  • Fix some faulty checks in backup script

Are you the owner of the code you are sending in, or do you have permission of the owner?

y

@dupondje
Copy link
Member

/ost

@github-actions
Copy link

⏳ Running ost suite 'basic-suite-master' on distro 'el9stream'.

Follow the progress here.

@github-actions
Copy link

😭💔 ost suite 'basic-suite-master' on distro 'el9stream' failed. (details)

@dupondje
Copy link
Member

/ost

@github-actions
Copy link

⏳ Running ost suite 'basic-suite-master' on distro 'el9stream'.

Follow the progress here.

@github-actions
Copy link

😭💔 ost suite 'basic-suite-master' on distro 'el9stream' failed. (details)

First check that the needed db user is configured/present and only then
look at the change_db flags.

Signed-off-by: Peter Boden <[email protected]>
Add the concept of an install root to the engine-backup.
On a regular production system the install root is `/`, but on
development systems this root (i.e. installed from an rpm) can be anything.
This makes it so that taking and restoring backups of development systems
is impossible.

There already was a devmode flag, if this flag is set to 1 then the
INSTALL_ROOT will be equal to `$PREFIX/`, in all other cases the root
will be `/` (like it was before).

Also, use the 'ENGINE_USR' var where a hardcoded path was used.

A backup that you take is now agnostic of the path where
ovirt was/is installed. So you can restore a production backup on a dev
box and vice versa.

Signed-off-by: Peter Boden <[email protected]>
@peter-boden
Copy link
Member Author

/ost

@github-actions
Copy link

⏳ Running ost suite 'basic-suite-master' on distro 'el9stream'.

Follow the progress here.

@github-actions
Copy link

😎💪 ost suite 'basic-suite-master' on distro 'el9stream' finished successfully. (details)

local pki_password="$2"
local timestamp="$3"

log "Found legacy encryption in ${file}, re-encrypting to AES-256"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As we don't force AES-256, perhaps strip that from the output?

dupondje and others added 2 commits October 29, 2025 15:00
When restoring a backup from CentOS 8 onto a CentOS 9 system, the p12 files that were generated are invalid,
because they use a legacy encryption on CentOS 9.

So, upon restore, we try to read the p12 files. When this fails we try to read the
p12 file with the `legacy` flag. If this succeeds, we re-encrypt the p12 file
with a newer encryption algorythm. The old p12 files is backup up.

We log all actions so that the user knows what happened, and can act upon errors.

Signed-off-by: Peter Boden <[email protected]>
The `-aes256` flag is ignored by `openssl pkcs12 export`.
We remove it and fall back to the default, which we assume is secure
enough, and will stay more up-to-date while algorythms evolve.

Signed-off-by: Peter Boden <[email protected]>
@peter-boden peter-boden requested a review from dupondje October 29, 2025 14:02
@dupondje dupondje merged commit 6e58a03 into oVirt:master Oct 29, 2025
3 checks passed
@dupondje dupondje deleted the fix/upgrade_certs branch October 29, 2025 14:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants