We were trying to install & configure ArcSight Logger on 64 bit Red Hat Enterprise Linux Server release 6.1 (Santiago) . We encountered strange issue. We had issue with the versions of Loggers:
- ArcSight-logger-5.3.0.6684.0.bin
- ArcSight-logger-5.3.1.6838.0.bin
Problem Details:
While installing the ArcSight Logger in console mode (with '-i console' option):
- Logger initialization failed while installing as “root” (we typically become root as 'sudo su -'). Error message, “The initialization of Logger software was unsuccessful. Reason: Platform initializer failed”.
- Logger installation and initialization went Okay, while installing as non-root user like “arcsight”. Please note, while installing as non-root user, the logger can not listen on privileged SSL port "443" and it cannot create linux service for application.
Since, our requirement was logger to be accessible on Port 443, we had to install & initialize it as root user.
Note: Even though, “root” is being used during installation,
Arcsight http processes are owned by non-privileged user ‘nobody’ for security reason.
Investigation details/result:
As we found, in both cases above, the installation itself was successful, but it failed during initialzation. We found that it was failing while
executing the script file: <Logger-Install-Dir>/current/arcsight/service/function
in the following line:
runAsOtherUser()
{
curr_user=`whoami`
if [ -f "$CURRENT_HOME/arcsight/service/user.config" -a
"X$curr_user" = "Xroot" ]; then
source $CURRENT_HOME/arcsight/service/user.config
su -c "$1"
$CUSTOM_NONROOT_USER
else
eval $1
fi
}
We got the segmentation fault at
this point, as seen in the <Logger-Install-Dir>/current/arcsight/logger/logs/logger_init_driver.log
../service/functions: line 159:
23437 Segmentation fault (core dumped) su -c
"$1" $CUSTOM_NONROOT_USER
and the actual reason seemed to be NOT
finding the “NSS_3.12.9” libraries. As we noticed the below the error message in /var/log/secure log:
su: PAM unable to dlopen(/lib64/security/pam_ldap.so):
/opt/arcsight/logger/current/local/nss/lib/libnss3.so: version `NSS_3.12.9' not
found (required by /lib64/libldap-2.4.so.2)
su: PAM adding faulty module: /lib64/security/pam_ldap.so
We checked the installed RPM packages related to the nss* on our Logger server, and found that we actually had slightly higher version
(nss_3.14.3) installed,. See below:
nss-3.14.3-4.el6_4.x86_64
nss-pam-ldapd-0.7.5-18.2.el6_4.x86_64
nss-softokn-3.14.3-3.el6_4.x86_64
nss-softokn-freebl-3.14.3-3.el6_4.i686
nss-softokn-freebl-3.14.3-3.el6_4.x86_64
nss-sysinit-3.14.3-4.el6_4.x86_64
nss-tools-3.14.3-4.el6_4.x86_64
nss-util-3.14.3-3.el6_4.x86_64
since, it was not failing while using non root user, it's obvious that, nss related code library (located under <Logger-Install-Dir>/current/local/nss/lib/libnss3.so) is being used only while doing 'su *' in the script. And it's also obvious that ArcSight's libnss library code requires (hard coded ???) nss_3.12.9 version of nss libraries installed on the server.
Resolution:
- I guess, the simple resolution of this problem would be to lower the version of nss libraries to 3.12.9, however, in our case it's not possible because of operation policy not to go with lower version and always maintain the latest version of libraries. Many of your organization may have similar policy in effect, so read below what (work-around ) option you have until software vendor provides the fix:
- Here’s how we're able to successfully install and configure ArcSight Logger using the ‘root’ user without lowering the version of nss libraries. As previously discussed, the issue seemed to be incompatibility with the nss* libraries (software code seems to be hard-coded to require 3.12.9 version of nss libraries) and required some application specific script changes.
- /opt/arcsight/logger/current/arcsight/logger/bin/scripts/relative_paths_env.sh
- /opt/arcsight/logger/current/arcsight/service/functions
- /opt/arcsight/logger/current/arcsight/logger/bin/scripts/web.sh
Once, the files updated, save the files.
Hit the [Enter] from the first console window and continue the initialization/configuration.
It seemed that once you remove
the nss/lib path entry from the LD_LIBRARY_PATH, the application uses the latest version of nss
libraries installed/available on your server.
Thanks for the well-written post and I will follow your updates regularly and this is really helpful. Keep posting more like this.
ReplyDeleteDevOps Training in Chennai
DevOps Certification in Chennai
AWS Training in Chennai
AWS course in Chennai
Cloud Computing Training in Chennai
Cloud Computing Courses in Chennai
DevOps Training in Velachery
DevOps Training in Tambaram
DevOps course in Chennai