Fix warning thrown in update script regarding non-portable flag usage in cp

[JessStingray]

Contribution Guidelines

• I've read the contribution guidelines and wholeheartedly agree them

What does this PR include?

Short Description

This is a minor fix to the update script. Currently, "cp: warning: behavior of -n is non-portable and may change in future; use --update=none instead" is thrown when dealing with SSL certificates. This commit replaces -n with the correct flag, removing the warning.

Affected Containers

None; affects only the update script

Did you run tests?

What did you tested?

I commented out the "new version check" part of the script on my install to ensure the change wasn't overwritten, and then ran the update script.

What were the final results? (Awaited, got)

Results were as expected - the warning no longer shows, and certificates were copied/left alone as they should be.

[DerLinkman]

Yes, also read this a few days prior. Did you tested if this is also working on a few other mailcow supported OS?

[JessStingray]

Good call to double check that - seems I had a testing version of Debian, with current stable having an older version.

I've added a new commit that checks the currently available version of cp to make sure it's newer than 9.3, the version that made this change - older systems (e.g. Debian, CentOS etc) will fall back to the -n behaviour while newer systems will use the new flag to avoid warnings.

I've now tested this on Ubuntu 24.04, Debian Bookworm and Sid, and Fedora 40, all of which behave as expected, though I don't have an Alma or Rocky VM available to test with at the moment.

[Habetdin]

If the cp --update=none works both in old and new versions of coreutils, is there any point of making complex code with two branches instead of a single command? There would be no need for additional version_greater_or_equal function in the latter case.

[JessStingray]

--update doesn't allow arguments prior to 9.3, so the new version of the command fails (as in Debian Bookworm):

In these cases the -n flag is still needed, which throws the warning in newer versions, so the check is unfortunately necessary.

[DerLinkman]

Can confirm not working on Alma 8 (supported from us) so this must be fiddled around somehow to make it work.