Current F43 freeipa-client scriptlets fail on some infra hosts:

[ 69/246] Upgrading sssd-common-0:2.12.0-1.fc43.aarch64 100% | 20.6 MiB/s | 6.3 MiB | 00m00s>>> Running %triggerin scriptlet: freeipa-client-0:4.13.0-2.fc43.aarch64

Non-critical error in %triggerin scriptlet: freeipa-client-0:4.13.0-2.fc43.aarch64
Scriptlet output:
sed: can't read /etc/ssh/ssh_config.d/04-ipa.conf: No such file or directory
sed: can't read /etc/ssh/ssh_config.d/04-ipa.conf: No such file or directory

[RPM] %triggerin(freeipa-client-4.13.0-2.fc43.aarch64) scriptlet failed, exit status 2 ...>>> Finished %post scriptlet: freeipa-client-0:4.13.1-1.fc43.aarch64
Scriptlet output:
sed: can't read /etc/ssh/ssh_config.d/04-ipa.conf: No such file or directory
sed: can't read /etc/ssh/ssh_config.d/04-ipa.conf: No such file or directory

Running %triggerin scriptlet: freeipa-client-0:4.13.1-1.fc43.aarch64
Non-critical error in %triggerin scriptlet: freeipa-client-0:4.13.1-1.fc43.aarch64
Scriptlet output:
sed: can't read /etc/ssh/ssh_config.d/04-ipa.conf: No such file or directory
sed: can't read /etc/ssh/ssh_config.d/04-ipa.conf: No such file or directory

[RPM] %triggerin(freeipa-client-4.13.1-1.fc43.aarch64) scriptlet failed, exit status 2

This is against the package policy:
https://docs.fedoraproject.org/en-US/packaging-guidelines/Scriptlets/#_syntax

All scriptlets MUST exit with the zero exit status. Because RPM in its default configuration does not execute shell scriptlets with the -e argument to the shell, excluding explicit exit calls (frowned upon with a non-zero argument!), the exit status of the last command in a scriptlet determines its exit status. Most commands in the snippets in this document have a "|| :" appended to them, which is a generic trick to force the zero exit status for those commands whether they worked or not. Usually the most important bit is to apply this to the last command executed in a scriptlet, or to add a separate command such as plain ":" or "exit 0" as the last one in a scriptlet. Note that depending on the case, other error checking/prevention measures may be more appropriate.

The failures in this case don't cause the tranasction to fail immediately (fortunately), but they do cause its overall exit code to be non-zero, which means ansible shows the step as failed.

Originally reported here: https://bugzilla.redhat.com/show_bug.cgi?id=2439482