Open mzima opened 2 years ago
@mzima we will check it, and if any update will let you know, thanks.
The same problem exists under SLES12SP5.
@mzima How did you change the /etc/pam.d/other file?
@eeagle I changed it manually.
etc/pam.d/other
@mzima I mean how looks your /etc/pam.d/other
-Fix in the File ;-)
@eeagle
You have to remove or comment the "session required pam_warn.so" line:
#%PAM-1.0
auth required pam_warn.so
auth required pam_deny.so
account required pam_warn.so
account required pam_deny.so
password required pam_warn.so
password required pam_deny.so
#session required pam_warn.so
session required pam_deny.so
That's all :)
@eeagle
You have to remove or comment the "session required pam_warn.so" line:
#%PAM-1.0 auth required pam_warn.so auth required pam_deny.so account required pam_warn.so account required pam_deny.so password required pam_warn.so password required pam_deny.so #session required pam_warn.so session required pam_deny.so
That's all :)
Thank you :-)
We are using the omi-1.6.8-1 RPM package on SLES 15.3 and our journald message facility gets flooded with this kind of pam_warn / pam_sm_close_session messages:
2021-12-29T11:16:23.008028+01:00 l9800022 omiserver: pam_warn(omi:session): function=[pam_sm_close_session] flags=0x8000 service=[omi] terminal=[] user=[dummyuser] ruser=[<unknown>] rhost=[<unknown>]
The reason for this message is that session handling currently is not defined in /etc/pam.d/omi:
The session message from omiserver is therefore handeld by /etc/pam.d/other which makes use of pam_warn.so (SLES default):
The pam_sm_close_session use itself was introduced by this commit a couple of years ago:
Can please someone have a look at this issue? Our current workaround is to modify the /etc/pam.d/other file, but our expectation would be that the omi PAM file should take care of session handling.
Cheers, Martin