Hello Team.
We seem to facing the same issue since last week while installing sat 6.11.0. We have tried the solution above but it does not sem to work for us. Could you please help out with what we are missing?
cc @jhutar

Good research, I saw this reported years ago and we could not figure it out. You are on the right track I think, the alias (mapping) is key here. This actually makes "restorecon" to set those contexts, that is the tool which is typically run in postinstall script for each package.

I do not remember what creates the alias tho, can you list RPM files containing "selinux" on both systems? I expect one named "postgresql-selinux". If not, it should be in the base policy.

This is where the policy lives (Rawhide, we do have CentOS 8 Stream branch somewhere):

https://github.com/fedora-selinux/selinux-policy/blob/rawhide/policy/modules/services/postgresql.te
https://github.com/fedora-selinux/selinux-policy/blob/rawhide/policy/modules/services/postgresql.if
https://github.com/fedora-selinux/selinux-policy/blob/rawhide/policy/modules/services/postgresql.fc

It must be defined somewhere in an "SCL" package (post scriplet?) I'd ask SELinux guys.

I think we have a winner here

# rpm -q --scripts rh-postgresql12-runtime-3.4-1.el7.x86_64
postinstall scriptlet (using /bin/sh):
# Simple copy of context from system root to SCL root.
# In case new version needs some additional rules or context definition,
# it needs to be solved in base system.
# semanage does not have -e option in RHEL-5, so we would
# have to have its own policy for collection.
semanage fcontext -a -e / /opt/rh/rh-postgresql12/root >/dev/null 2>&1 || :
semanage fcontext -a -e /etc /etc/opt/rh/rh-postgresql12 >/dev/null 2>&1 || :
semanage fcontext -a -e /var /var/opt/rh/rh-postgresql12 >/dev/null 2>&1 || :

selinuxenabled && load_policy || :
restorecon -R /opt/rh/rh-postgresql12/root >/dev/null 2>&1 || :
restorecon -R /etc/opt/rh/rh-postgresql12 >/dev/null 2>&1 || :
restorecon -R /var/opt/rh/rh-postgresql12 >/dev/null 2>&1 || :

On my machine, the system was fully up-to-date before installing Satellite, on the reproducer machine it was not. During the same yum transaction where rh-postgresql12-runtime was installed, there was also an update to selinux-policy and selinux-policy-targeted. Not saying this is the cause, but it might play some role in this as well as the postinstall which should set up the contexts apparently failed silently.

@Jan: Are you able to hit this reliably? If so, could you try fully upgrading the machine before installing satellite?

If this is the case, the solution for these bugs (postscriplet vs base policy order) can be typically solved by requiring specific selinux-policy version from our foreman-selinux package. We already have such a requirement in our package to workaround other bug so we just need to bump the version:

https://github.com/theforeman/foreman-packaging/blob/rpm/develop/packages/foreman/foreman-selinux/foreman-selinux.spec#L21

It looks like the current version of the SPEC actually requires the version it was installed in the buildroot which is perhaps a good default value but we need to bump this to the required version. Or simply make sure that such version is in the buildroot, this can be done by creating ticket for satellite release engineering.

Yes, fully upgrading machine before installing satellite solves the issue. Thank you!

@Adam: as i wrote during case opening in January 2021 i was not able to reproduce, it was strictly issue on customer's side, so no i am not able to hit this reliability and no i cannot upgrade the machine before installing Satellite because i do not have reproducer, also cannot ask the customer as cases which hit this are closed for very long time now.

Upon review of our valid but aging backlog the Satellite Team has concluded that this Bugzilla does not meet the criteria for a resolution in the near term, and are planning to close in a month. This message may be a repeat of a previous update and the bug is again being considered to be closed. If you have any concerns about this, please contact your Red Hat Account team.  Thank you.

Since this is all SCL related and that implies RHEL7, I'm going to close this as CURRENTRELEASE. It shouldn't affect RHEL8. Our docs also suggest to run yum/dnf update prior to installation which should also resolve the issue.