CON-11303] Installation Issue on RHEL 6.4 (64-bit) with ArcSight JIRA
- Pavan Raja
- Apr 8, 2025
- 11 min read
Summary:
The log entry you've provided details a technical issue encountered during the installation of an ArcSight SmartConnector on a RHEL 6.0 x86_64 system. The focus is on the specific packages `glibc` and `nss-softokn-freebl`, which are crucial for ensuring that software libraries and dependencies are correctly installed to support application functionality.
Here's a breakdown of what this log entry indicates:
1. **Package Information**: - `glibc-2.12-1.7.el6_0.8.i686`: This is the i686 version of the GNU C Library, which is essential for running applications that are compiled with support for this library on a 32-bit system. - `nss-softokn-freebl-3.12.8-1.el6_0.i686`: This package provides free browser plugin support for NSS, including cryptographic libraries and network security services, which are necessary components for applications that need secure communication over networks.
2. **Installation Command**: The command used to install these packages was `yum install `, indicating the use of Yum, a powerful package manager in Red Hat Enterprise Linux (RHEL) systems, which automatically handles dependencies and resolves version conflicts.
3. **Post-installation Verification**: After installation, the system administrator verified the presence of both `glibc` and its specific architecture variant by running `rpm -q glibc`. This command checks if a package is installed without specifying the architecture (i686), which suggests that multiple architectures might be present on the system.
4. **Software Installation Context**: The installation context involves setting up an ArcSight SmartConnector, possibly due to its cross-platform or compatibility requirements. Installing these libraries ensures that all necessary dependencies for running such software are in place.
5. **Additional Information from Comments**: A comment mentions potential issues with missing library dependencies and the use of a local repository (RHEL-Installation-DVD-as-Software-Repository) to resolve these dependencies, which were not available in standard repositories. This approach is typical when dealing with legacy systems or specific architectural requirements that are less common across all distributions.
6. **Future Planning**: The conversation indicates plans to move the ticket forward for platform support verification for RHEL 6, initially set for Q2R1 but corrected by Simran Brar to Q2R2. Progress was made in testing and confirmed compatibility with both RHEL 6.0-64bits and RHEL 6.1-64bits later on in the process.
This log entry is part of a broader software development and support process, where issues are tracked using Atlassian JIRA for bug tracking and project management, involving multiple team members across different sprints and releases to ensure successful resolution of platform compatibility issues.
Details:
The JIRA issue <#con-11303>
reports that Build A6192 cannot be installed on a RHEL 6.0-64bit operating system. The installation was successful on RHEL5.4-64bits and RHEL6.0-32-bits, but failed when attempted on the RHEL6.0-64bit version. A screenshot of the failure is attached to the issue for reference.
The problem seems to be related to additional libraries required for installation that are not present or correctly configured in a 64-bit environment. The ticket suggests that glibc.i686, libXext.i686, and libXtst.i686 dependencies might need to be installed manually before attempting the installation of Build A6192.
The issue is closed as "Fixed" in version 5.2.5 (Q3R1Y2012), with a note that documentation should be updated to include details about these additional libraries required for successful installation on RHEL6.0-64bits OS. The ticket also indicates that the Perforce job exists for this issue, and it has not been reopened after initial closure.
The text you provided outlines a series of actions taken by Jidong Chen and Amjad Alhait in response to issues with installing certain software packages on a Linux system, specifically mentioning Red Hat Enterprise Linux (RHEL) version 6. The comments suggest that the users were attempting to install various RPMs (Redhat Package Manager) for different libraries such as NSS, glibc, libXau, libxcb, and others, which are typically used in software development or application support but might not be included by default in a fresh installation of RHEL 6.
Jidong Chen noted that he had installed the packages manually after encountering issues during the installation process. He listed specific commands he ran to install these packages:
`rpm -ivh nss-softokn-freebl-3.12.7-1.1.el6.i686.rpm`
`rpm -ivh glibc-2.12-1.7.el6.i686.rpm`
`rpm -ivh libXau-1.0.5-1.el6.i686.rpm`
`rpm -ivh libxcb-1.5-1.el6.i686.rpm`
`rpm -ivh libXi-devel-1.3-3.el6.i686.rpm`
`rpm -ivh libX11-1.3-2.el6.i686.rpm`
`rpm -ivh libXext-1.1-3.el6.i686.rpm`
`rpm -ivh libXi-1.3-3.el6.i686.rpm`
`rpm -ivh libXtst-1.0.99.2-3.el6.i686.rpm`
Amjad Alhait echoed similar sentiments, requesting a step-by-step guide to reproduce the issue and emphasizing that XLIB libraries were expected but missing. He also mentioned concerns about the NSS library installation, questioning whether it gets installed by default and suggesting looking at documentation for ESM 5.2 support as well as prerequisites.
Simran Brar added her comments after some research on the subject, stating that manual installation of XLIB libraries is expected and recommended to follow the ESM 5.2 install guide due to its compatibility with RH6. She also expressed concerns about the NSS library's inclusion in the initial setup without a clear reason why it needed to be installed manually.
In summary, these comments indicate that certain software components might not be included by default with RHEL 6 installations and require manual intervention via command-line installation of RPM packages. The users involved were also advised to refer to specific documentation or tickets for further guidance on the process, especially considering potential compatibility issues with ESM 5.2 support.
The conversation is about ensuring that certain libraries are installed for FIPS (Federal Information Processing Standard) compliance, and specifically addressing the issue with the NSS library on RHEL 6.0. Here's a summary of the key points discussed:
1. **Missing Libraries**: The team found out that some X libraries were expected but not included by default in the installation process. These libraries are typically required for applications that need graphical user interfaces (GUIs).
2. **Manual Installation**: It was noted that these missing libraries should be installed manually, and there is a documentation available (ESM 5.2 install guide) where this information can be found. This suggests that the default installation process does not include these libraries, which could lead to errors when they are needed.
3. **NSS Library**: The team was concerned about the NSS library specifically. It was mentioned that a 32-bit version of the NSS library should be packaged for FIPS support, but it needs to be installed manually due to some dependencies on other libraries like glibc and libX11.
4. **Dependencies**: The dependency chain revealed that nss-softtokn-freebl is needed by glibc, which in turn is required by libX11. Connector (32-bit java) applications also need X11 to run GUI, but RHEL 6.0, especially the 64-bit version, does not install 32-bit libraries by default because the 64-bit ISO does not include 32-bit RPMs.
5. **Error Impact**: The team was asked to provide detailed steps about what errors would occur if the NSS library is not installed separately. They were advised that with a 32-bit nss library, you would also need a 32-bit zlib library, but the main point of concern was whether there would be specific error messages or failures related to missing components when trying to run applications that depend on these libraries.
6. **Review in Q1R2**: The issue is scheduled for review in Q1 Release 2 (Q1R2), which means it will be revisited and potentially addressed in a future update of the software, possibly as part of an upgrade or patch release to support RHEL 6.0 more effectively.
In summary, the conversation highlights the importance of ensuring all necessary libraries are included in the default installation process for FIPS compliance and application compatibility, especially when dealing with dependencies on older systems like RHEL 6.0. The team was urged to document any errors that would occur if these libraries were not manually installed, particularly focusing on the NSS library and its dependencies.
The text provided is discussing the dependency issue between `glibc` and `nss` libraries in a Linux environment, particularly within the context of Red Hat Enterprise Linux (RHEL) 6. It highlights that `glibc` should not have a dependency on `nss`, but rather `nss` should depend on `glibc`. The discussion is centered around the error messages encountered when attempting to remove the `nss-softokn-freebl` package, which contains the `libfreebl3.so` library required by `glibc`.
Here are detailed steps and information about what happens if you do not install the `nss` library separately:
1. **Error Message**: When attempting to remove or update the `nss-softokn-freebl` package without installing it, you will encounter a dependency error similar to the one provided in the text. For example:
```bash
# rpm -e nss-softokn-freebl
error: Failed dependencies:
libfreebl3.so is needed by (installed) glibc-2.12-1.7.el6.i686
libfreebl3.so(NSSRAWHASH_3.12.3) is needed by (installed) glibc-2.12-1.7.el6.i686
```
This error indicates that the `libfreebl3.so` library, which is part of the `nss-softokn-freebl` package, is required by the already installed `glibc` package. Since RPM (Red Hat Package Manager) handles dependencies to ensure software compatibility and functionality, attempting to remove a dependency without satisfying its requirements will result in an error.
2. **Installation of Specific Architecture**: To resolve this issue, you would typically need to install the `nss` library explicitly for the same architecture (`i686` in this case) as the one used by `glibc`. This can be done using a package manager command like `yum`:
```bash
# yum install nss.i686
```
Alternatively, if you are installing from source or using other package management tools, ensure that the appropriate architecture and dependency libraries are included in the installation process.
3. **FIPS Compliance**: The text also mentions the importance of checking whether FIPS (Federal Information Processing Standards) compliance is working correctly after installing `nss`. FIPS 140-2 is a U.S. government standard for cryptographic modules, and ensuring that your system meets this standard can be crucial for certain security-sensitive applications.
In summary, the absence of the `nss` library will lead to dependency issues when trying to remove or update related packages like `glibc`, as well as potential problems with FIPS compliance checks if such a feature is enabled in your system configuration. Installing the missing dependency via package managers or manual installation ensures that all required libraries are available and compatible, thus avoiding these errors and maintaining system integrity and security.
The provided text is a log of an installation process for two packages, `glibc` and `nss-softokn-freebl`, on a system running Red Hat Enterprise Linux (RHEL) 6. This process involves several steps such as setting up the install process, resolving dependencies, downloading necessary files, installing the packages, and verifying the installation using `rpm -q`.
Here's a summary of the key points:
1. The text indicates that there are two packages to be installed (`glibc` and `nss-softokn-freebl`) as part of an update or initial setup process.
2. During the dependency resolution, it was determined that `glibc` requires `libfreebl3.so` which is provided by `nss-softokn-freebl`. Thus, both packages are required for installation.
3. The installation includes updating `glibc` and installing a new package `nss-softokn-freebl`.
4. After dependency resolution, the system proceeds to download both packages from the repository; in this case, it is noted that the download took around 12 minutes with an average speed of 371 kB/s.
5. The installation was confirmed to have succeeded as indicated by a message saying "Complete!" after all necessary transactions were completed successfully.
6. Finally, `rpm -q glibc` was executed to check if the package is installed, and it returned that both versions (`x86_64` and `i686`) of `glibc` are now installed as per the provided output.
7. The log concludes with a command line prompt showing the user being in the directory `arcsight`.
The text provided is a description of the process for installing an application, presumably via a script or automated tool named "nux.bin," which runs in console mode (indicated by "-i console"). The installation process involves several steps:
1. **Preparation**: The system starts preparing to install the software by extracting necessary resources such as the Java Runtime Environment (JRE) and configuring the installer for the specific environment of the system, which is running a version of Red Hat Enterprise Linux 6.0 with kernel version 2.6.32-71.38.1.
2. **Dependency Resolution**: During the installation process, it was determined that glibc (a component of GNU C Library) is required and its dependency nss-softokn-freebl must be installed. The system resolved dependencies by confirming the presence of glibc version 2.12-1.7.el6_0 and installing nss-softokn-freebl version 3.12.8-1.el6_0, both marked for update based on the system's configuration and repository details.
3. **Installation**: The installation proceeded by updating glibc and nss-softokn-freebl to their respective versions specified in the repository, as detailed in the transaction summary provided. This setup ensures that all necessary libraries are present and compatible with the version of Red Hat Enterprise Linux being used for the installation.
The output also includes system information such as the release number and kernel version from /etc/redhat-release and uname -a commands respectively, confirming the environment in which these steps were performed. Additionally, it confirms that glibc was installed at a 32-bit architecture level (i686) to meet dependency requirements of the software being installed via nux.bin.
The provided text is from a software installation log, specifically for installing packages on an RHEL (Red Hat Enterprise Linux) system. Here's a summary of the key points:
1. **Package Installation Summary**: Two packages were installed during this process. One was upgraded, but the count remained zero, and no new packages were removed. The total download size was 4.4 MB. The installed size was reported as 0, which might be a placeholder or an error in reporting since typically it should reflect the space used by the installed packages.
2. **Detailed Package List**: Two specific packages were installed:
`glibc-2.12-1.7.el6_0.8.i686` (a library package for the GNU C Library)
`nss-softokn-freebl-3.12.8-1.el6_0.i686` (a package that provides free browser plugin support for NSS, including cryptographic libraries and network security services).
3. **Installation Command**: The command used to install the packages was `yum install `. This is a common method in Red Hat-based distributions for installing software via the Yum package manager.
4. **Post-installation Verification**: After installation, the command `rpm -q glibc` was executed to verify that both `glibc` and its associated architecture-specific variant (`glibc.i686`) were installed correctly. The output confirmed the presence of these packages on the system.
5. **Software Installation Context**: This log entry is part of a larger sequence where an ArcSight SmartConnector installation script was executed, which likely needed glibc and other dependencies to function properly due to its cross-platform or compatibility requirements.
6. **Additional Information from Comments**: A comment in the log indicates that there might be issues with missing library dependencies (`glibc.i686`, `libXext.i686`, `libXtst.i686`, and their dependencies) which were resolved by adding the RHEL-Installation-DVD-as-Software-Repository, presumably to provide a local repository for these packages that are not available in standard repositories.
This log provides valuable information about package management, system updates, and software installation procedures typical in Unix-like operating systems using RPM-based packaging systems like Yum or APT on Debian-based distributions.
The text appears to discuss a technical issue related to an installation process for a connector setup on RHEL (Red Hat Enterprise Linux) version 6.0 x86_64. The user, Kenley Fritts, suggests that instead of having the customer install multiple 32-bit libraries manually, it would be more efficient to automatically detect the system's architecture and use a different installer script tailored for 64-bit systems, which should have all necessary libraries included by default.
Susan Li, another user, comments on this thread in response to team triage discussions. The team has identified specific libraries as a concern but also mentions other areas of concern such as FIPS compliance, which is unique to the connector code. Based on the current state of investigation and planning, they have decided to defer support for RHEL 6 until future releases, with an initial goal set for Q2R1 (which likely refers to a specific release quarter). The team acknowledges that this may change if new issues arise that cannot be resolved by the planned Q2R1 release.
The conversation involves a ticket related to platform support for Red Hat Enterprise Linux (RHEL) and the process of moving its certification between sprints. Initially, on April 12th, the plan was revised to move the ticket to Q2R2 for verification regarding the new platform support for RHEL. However, Simran Brar noted that Susan entered the sprint number incorrectly and corrected it.
Later updates indicate progress in testing: In June, the certification process for RHEL 6.1 moved to Q3R1 according to team triage. Keem Loh requested verification if issue 6348 had been resolved. Christ He confirmed that the issue has been fixed on build X6348 and provided further details about its compatibility with both RHEL 6.0-64bits and RHEL 6.1-64bits.
The ticket involves coordination among team members, partners, and stakeholders to ensure successful resolution of issues related to platform support for RHEL across different versions and builds.
The issue in question is tracked using Atlassian JIRA, version 4.1.1, and involves software development bug tracking and project management. It was initially created by the owner, Simran Brar, on March 1, 2012, with no watchers assigned to it. The last update was made on July 20, 2012, followed by a resolution date of July 12, 2012.
Key points about this issue include:
Owner: Simran Brar
QA Lead: Jidong Chen
Bug tracking and project management for software development
Powered by Atlassian JIRA version 4.1.1 (build 522)
Users can report problems, request features or contact administrators through this platform.
Comments