Post-installation script fails on RHEL 6,7,8,9 when there are readonly variables in /etc/profile

[wouterhummelink]

On our hardened instances of RHEL the postinstallation script embedded in scx fails, which causes the SSL certs to not be properly generated, or even existing certificates being removed during upgrades.

  Running scriptlet: scx-1.7.0-0.x86_64                                                                                                                                                                                                                                           2/4 
/etc/profile.d/bash_timeout.sh: line 1: TMOUT: readonly variable
warning: %post(scx-1.7.0-0.x86_64) scriptlet failed, exit status 1
Error in POSTIN scriptlet in rpm package scx

We work around it for upgrades by removing the file /etc/opt/omi/ssl/.omi_cert_marker that the scx script is looking for.
Removing the readonly TMOUT is not an option as it is required by our security policy.

I've observed this behavior on all supported versions of RHEL. I've verified the script exits at sourcing /etc/profile by extracting it and running the script manually using sh -x

[JumpingYang001]

thanks for reporting it!

[luke2261git]

I've seen this issue before as well. I found that this line 'set autologut 15' also appears to cause issues.

One server had these lines:

cat /etc/profile.d/tmout.sh

TMOUT=900
export TMOUT
readonly TMOUT
set autologout 15

The symptom was the variable autologout was somehow replacing 'start, stop, status' in the failing script with 'autologout' .

script start|stop|status

became

script autologout | autologout | autologout

Commenting out 'set autologout' and 'readonly TMOUT' resolved the issue. Strange indeed.

[blakedrumm]

Yes, I have also noticed this issue with multiple customers. Anything that has "set" meaning that it is setting a custom variable in the profile, which causes the installation to fail.

[JumpingYang001]

the issue due to installation calls . /etc/profile to get environment variables.
#164 also due to the calling script failed.