For the BPA/TSCO Agent, can the embedded Java installation be removed or upgraded? The embedded JRE deployed is being detected during vulnerability scanning as needing to be upgraded

Version 2
    Share:|

    This document contains official content from the BMC Software Knowledge Base. It is automatically updated when the knowledge article is modified.


    PRODUCT:

    BMC Performance Assurance for Virtual Servers


    APPLIES TO:

    BMC Performance Assurance for Virtual Servers



    PROBLEM:

     

    We are being asked to upgrade the Java version deployed on all machines in our environment. The BMC Performance Assurance (BPA), TrueSight Capacity Optimization (TSCO), and Perceiver products all ship with an embedded Java Runtime Environment (JRE). Can that embedded JRE be upgraded to the latest Java version within these products?

      

    Applies To:

      

    TrueSight Capacity Optimization (Gateway Server/Capacity Agent) 11.3, 11.0, 10.7, 10.5, 10.3, 10.0
    BMC Capacity Optimization
    BMC Performance Assurance
    BMC Performance Perceiver

     


    SOLUTION:

     

    BMC Performance Assurance (BPA), BMC Performance Perceiver (Perceiver), and TrueSight Capacity Optimization (TSCO) all ship their own embedded Java Runtime Environment (JRE) install which they use. So, the JRE version installed on the machine itself won't impact BPA, TSCO, or Perceiver. At the system level any JRE version can be installed or no JRE installed at all -- those products won't use the version installed and will continue to run their embedded version.

    So, if the Java version is being upgraded in the environment what is the requirement? Is an existing embedded application java version going to be detected and replaced even for application specific JRE installations with a new JRE version? If so that would not be a tested or supported product configuration. But if all that is being done is that the JRE version at the OS level is being upgraded then that will have no impact on BPA, TSCO, or Perceiver because it is not using that installation of JRE and will continue to use its embedded JRE version (with different JRE versions being associated with different product versions).

    The JRE installs that the BPA, TSCO, and Perceiver products are not visible at the system level (it isn't installed via the normal Java install process so it can't be uninstalled via the standard Add/Remove Programs on Linux). The only way it would be detected on the system is if a scan for java.exe binaries installed within the BPA, TSCO, or Perceiver installation directory was executed and checked the version of that java.exe binary.

    So, the expectation is that the replacement of any natively installed JRE package on the machine with a newer version will have no impact on BPA, TSCO, and Perceiver since that JRE isn't being used. But that doesn't mean those product will now be running under the new JRE version -- they will continue to run under the JRE version they were shipped with.

      

    Q: I think my security team is going to detect and replace the embedded version of java shipped with 3rd party applications, not just the system level JRE installation. What impact will that have?

      

    There really isn't a good technical way to replace an embedded JRE within a 3rd party product since it isn't a separate detectable and replaceable install so it isn't clear how technically the security team would be planning on going in and replacing an embedded JRE from within a 3rd party product.

    Almost no product that installs its own embedded JRE version will support having that version removed and replaced with a completely different version. In general a product must be QA tested and frequently have its code modified to work with a new version of the JRE.

    The BPA console won't really be a major issue (since the JRE installed as part of BPA is only for the install/uninstall component and the BPAMaintenanceTool -- so if that part doesn't work it won't impact the product itself.  For Perceiver the only version of the JRE that is known to work and is supported is the version of the JRE that is embedded by default within Perceiver.  TSCO also only supports the embedded version of JRE that is shipped with the product.

      

    Q: What is the purpose of the /[BPA Installation Directory]/BMCBPAInstallJVM JRE installation?

      

    That directory is used for:
      (A) The uninstall of the BPA/TSCO Agent product
      (B) The BPAMaintenanceTool (BPAPatchTool)

    So, if you aren't doing an uninstall and you aren't running the patch installer on the machine then it would be possible to remove that directory.  The actual BPA agent functionality (collect and transfer data) doesn't rely on that BMCBPAInstallJVM directory and will function without it.  The TSCO Gateway Server Manager functionality and other console functionality also does not rely on this directory and will function without it.

    Technical Support has done some limited testing of the BPAMaintenanceTool.sh on Red Hat Enterprise Linux (RHEL) running an updated JRE version and it looked good.  The BPA Maintenance Tool successfully loaded and it was still possible to apply the latest patch both via the GUI and via the silent install.  So, it looks on the surface at least it would be possible to remove the /[BMCBPAInstallJVM] directory and replace it with a symbolic link to a central never Java install on the machine [even in the scenario where the TSCO Agent was deployed using JRE version 7 and the java version has been upgraded to JRE version 8.  This is true at least on RHEL -- although if it works there one would expect it to work on other platforms since the code is the same.

      

    Since the ability to patch the TSCO Gateway Server and Capacity Agent is important functionality it is recommended, if the directory must be removed, to replace it with a symbolic link that points to a valid JRE installation directory on the machine.

      

    Q: Are there any TSCO Agent official product installation images available which include an embedded JRE version 8 rather than JRE version 7?

      

    In general the JRE version is updated with the most current JRE version available at the time that a new TSCO release is being packaged.  But, there have been instances where for specific deployment requirements the TSCO Agent image has been refreshed with a newer version of the embedded JRE.

      

    Request for Enhancement (RFE) QM002405247: 'Request quarterly updates be provided for embedded JRE associated with any TSCO components' is being used to track the request to remove or refresh the embedded Java Run Time (JRE) environment associated with the TSCO Agent and other TSCO components.

    The TSCO Agent version 10.5.00 and 10.7.01 packages for Linux have already been rebuild with a current embedded JRE version and the packages available on the EPD site have been replaced.

    Here is the md5sum of the new TSCO Agent packages for Linux: 
      New Image :  af74fbee0d6138629e3e385e420bcb64 *TSCO_Agent_ver10.5.00_Linux_x86_x86-64.tar
      New Image :  324eef5d583642707471a99b8e3f0e67 *TSCO_Agent_ver10.7.01_Linux_x86_x86-64.tar

    Those installation images will deploy the Oracle JRE version 1.8.0_162 in the /[TSCO Agent Installation Directory]/BMCBPAInstallJVM directory rather than the older version.

    Contact Technical Support for additional information regarding which TSCO Agent versions and platforms are available and which JRE version they contain.  Technical Support can request other packages (such as the Windows packages) to be rebuilt with the newest JRE version.

      

     

      

    Q: Can the TSCO Agent/Gateway Server embedded BMCBPAInstallJVM directory just be removed?

    Yes, the /[TSCO Agent Installation Directory]/BMCBPAInstallJVM directory can be deleted from both the TSCO Agent and Gateway Server installation with no impact on normal product operation.  The JRE is necessary when installing the latest TSCO Agent/Gateway Server Cumulative Hot Fix (CHF) so if it has been removed (and hasn't been replaced with a symbolic link pointing to another valid JRE version on the machine) it would be necessary to then include a JRE as part of the TSCO Agent/Gateway Server CHF deployment package.  This should be a straigh tfoward process if the deployment is being done via an automated process, such as a BMC Server Automation (Bladelogic) patch deployment.  By setting the JAVA_HOME environment variable to the path of the desired JRE version before running the patch installer it will be able to find the custom JRE version on the machine rather than using the 'BMCBPAInstallJVM' JRE.  

    Related Products:

      
       
    1. BMC Capacity Optimization
    2.  
    3. BMC Capacity Optimization
    4.  
    5. BMC Performance Perceiver for Servers
    6.  
    7. BMC Performance Assurance for Servers
       Legacy ID:KA408757

     


    Article Number:

    000094955


    Article Type:

    Solutions to a Product Problem



      Looking for additional information?    Search BMC Support  or  Browse Knowledge Articles