Summary
Reference
Newer ArcMC versions over the past few years have some basic requirements that may cause issues during installation.
The issues encountered may not be obvious so there are some basic steps to help troubleshoot installs.
---
1) Sometimes a precheck will appear to show everything on the system is fine, but some RPMs may still be missing or incorrect versions.
One of the most helpful methods to see this issue or other issues during an install is to prefix the command line install with "sh -x".
For example a root install command might look similar to this when running the binary from the current directory:
# sh -x ./ArcSight-ArcMC-2.9.6.2232.0.bin
Often a minimal Linux install will be missing RPMs such as unzip fontconfig dejavu-sans-fonts perl
The debug level output when using sh -x becomes extremely verbose.
Many common utilities like putty have a set limit to buffer so you may want to save the output to file or increase buffer accordingly.
---
2) The release notes for many years now include one step to modify the logind.conf file.
If customers are following only the admin guide for installation steps, often this if overlooked.
Please review the release notes for that modification for your version.
---
3) Sometimes an install will complete, but the UI will not be reachable.
Check that the port is allowed by the firewall (typically 443 or 9000 for non-root installs)
---
4) On Linux kernels version 8.x where you may see this error: "error while loading shared libraries: libnsl.so.1"
This typically occurs if customers are trying to go directly to a sub-version of ArcMC instead of starting with the main release and updating.
For example if trying to install 2.9.4 on linux kernel version 8.x as a fresh install and not an upgrade.
Typically, ArcMC should be installed by major release like 2.9.0 then updated accordingly, but with the release of 2.9.6 fresh installs are supported.
If you encounter the above error, try installing libnsl with something like "yum install libnsl".
---
5) Note that many installers have a known false negative reporting the tzdata package is not correct.
This error can be safely ignored during installation and continue past that point.
Also note you want to keep that package up-to-date especially if your environment spans timezones.
This has to do with many changes to timezones in recent history and vast linux changes at the OS levels.
---
6) When installing any product, it is best to use a fresh Operating System (OS) or Virtual Machine (VM).
Many people will reuse a VM or try to clean off the OS, but some artifacts remain and you may spend lengthy time troubleshooting only to have further issues at a later point.
Many companies have pre-configured ISOs or OVAs that have a lengthy change log already.
As a general Industry Standard best practice for troubleshooting lengthy installation issues, it is best to start fresh and in the end will be less time consuming.
So basically when errors are encountered, use a fresh VM and OS in a test lab environment that has not been altered by any company standards, hardening, or restrictions.
Then hardening or company policy changes can be added later to identify which are in conflict.
This is an optional troubleshooting step when issues are encountered that are causing too much time analyzing.
Companies can then focus on scripts and quick methods to add their hardening after base installs are completed and tested working.
With a little practice, that method can be much faster than using an OS or VM from an unknown state even if those company provided images have historically proven stable.
Then comparing and contrasting differences can reveal root cause.