su – <somenameofsomeuser>
this can be bypassed by modifying the su part of the pam stack
add a new su-session file
cp /etc/pam.d/common-session /etc/pam.d/su-session
common-session normally looks like
session required pam_limits.so
session required pam_unix.so try_first_pass
session optional pam_umask.so
session optional pam_systemd.so
session optional pam_gnome_keyring.so auto_start only_if=gdm,gdm-password,lxdm,lightdm
session optional pam_env.so
add a line in the su-session with
session [success=1 new_authtok_reqd=ok default=ignore] pam_listfile.so item=user sense=allow file=/etc/SAPUsers
making it into
session required pam_limits.so
session required pam_unix.so try_first_pass
session optional pam_umask.so
session [success=1 new_authtok_reqd=ok default=ignore] pam_listfile.so item=user sense=allow file=/etc/SAPUsers
session optional pam_systemd.so
session optional pam_gnome_keyring.so auto_start only_if=gdm,gdm-password,lxdm,lightdm
session optional pam_env.so
and adding a file
/etc/SAPUsers
which contains the names of the SAP Admin Users, in this example, SID is HA1 these would be
ardmore:~ # cat /etc/SAPUsers
ha1adm
sapadm
with the su-session file in place, modify the
/etc/pam.d/su
from the default
#%PAM-1.0
auth sufficient pam_rootok.so
auth include common-auth
account sufficient pam_rootok.so
account include common-account
password include common-password
session include common-session
session optional pam_xauth.so
to
#%PAM-1.0
auth sufficient pam_rootok.so
auth include common-auth
account sufficient pam_rootok.so
account include common-account
password include common-password
session include su-session
session optional pam_xauth.so
This new entry works as follows. During a session setup called by su it will check whether the Username provided is in the file /etc/SAPUsers and if yes it will do “success=1”, meaning it will
SKIP
the next one (ONE , 1=one) line in the pam stack, which is in this case pam_systemd.so and by this bypassing the user.slice creation of systemd
The result is that the SAP Instance will now stay in the pacemaker system.slice
`-system.slice
|-pacemaker.service
| |-2196 /usr/sbin/pacemakerd -f
| |-2198 /usr/lib64/pacemaker/cib
| |-2199 /usr/lib64/pacemaker/stonithd
| |-2200 /usr/lib64/pacemaker/lrmd
| |-2201 /usr/lib64/pacemaker/attrd
| |-2202 /usr/lib64/pacemaker/pengine
| |-2203 /usr/lib64/pacemaker/crmd
| |-4125 /usr/sap/HA1/ASCS00/exe/sapstartsrv pf=/sapmnt/HA1/profile/HA1_ASCS00_sapro0as -D -u ha1adm
| |-4296 sapstart pf=/sapmnt/HA1/profile/HA1_ASCS00_sapro0as
| |-4311 ms.sapHA1_ASCS00 pf=/usr/sap/HA1/SYS/profile/HA1_ASCS00_sapro0as
| `-4312 en.sapHA1_ASCS00 pf=/usr/sap/HA1/SYS/profile/HA1_ASCS00_sapro0as
There is no need to worry about the security of the /etc/SAPUsers file as it is only a list.
Generally this approach could be used on any non-systemd aware Resource inside or outside of the cluster.
Please keep in mind that there is a TasksMax Limit for Slices, which could be hit in case too many applications end up in the pacemaker system.slice, so increasing
DefaultTasksMax=
in /etc/systemd/system.conf might be advisable.