Skip to main content

We've Moved!

Product Documentation has moved to docs.hitachivantara.com
Hitachi Vantara Knowledge

Maintain Hitachi Ops Center

The Hitachi Ops Center system administrator performs various system operation and maintenance tasks such as starting or stopping a service, backing up and restoring user data, and modifying URLs.

Checking the validity period of a certificate in the truststore

You can check whether the validity period of a certificate in the truststore has expired.

Procedure

  1. Run the following command and provide the keystore password when prompted:

    installation-directory-of-Common-Services/jdk/bin/keytool -list -v -keystore /var/installation-directory-of-Common-Services/tls/cacerts

Checking the validity period of the server certificate

You can check whether the validity period of the management server certificate has expired.
NoteIf the certificate has expired, you must renew it. Follow the procedure in Creating a private key and a certificate signing request (SSL Setup tool) to request a new certificate and overwrite the existing one. You must also reconfigure the SSL server settings and SSL client settings.

Procedure

  1. Run the following command:

    installation-directory-of-Common-Services/jdk/bin/keytool -printcert -file path-of-server-certificate

Checking the revocation status of the server certificate

You can check the revocation status of the server certificate for a Hitachi Ops Center product by using the Online Certificate Status Protocol (OCSP).
NoteIf the certificate has been revoked, you must renew it. Follow the procedure in Creating a private key and a certificate signing request (SSL Setup tool) to request a new certificate and overwrite the existing one. You must also reconfigure the SSL server settings and SSL client settings.

Before you begin

Verify that the following settings are configured on the management server:

  • The OCSP responder is functioning. If you are unsure whether it is functioning, contact the certificate authority.
  • The server certificate has the Authority Information Access (AIA) record that includes the correct address of the OCSP responder.
  • The management server can access the OCSP responder and access is not blocked by a proxy.

To check whether the AIA record includes the correct address of the OCSP responder, you can use the openssl command. Check the address of the OCSP-URI field of the AIA record. If no address is set, contact the certificate authority that signed the server certificate. The following is the command syntax and an example of the command:

Command syntax:

echo "Q" | installation-directory-of-Common-Services/openssl/bin/openssl s_client -connect host-name-or-ip-address-of-product-URL:port-number-of-product-URL 2> /dev/null | openssl x509 -noout -text

Command example:

echo "Q" | /opt/hitachi/CommonService/openssl/bin/openssl s_client -connect example.com:443 2> /dev/null | openssl x509 -noout -text

You can check the revocation status of the server certificate in one of the following ways:

Checking the revocation status of the server certificate by using a web browser

You can use the OCSP check function of your web browser to check the revocation status of the server certificate. For details on how to check the status, see the documentation for your browser.

For Firefox, you can check the status by using the following procedure.

Procedure

  1. In the settings window of Firefox, select Privacy & Security, and then select the Query OCSP responder servers to confirm the current validity of certificates check box.

  2. Use Firefox to access the URL for the target product, and then check whether an error appears. If the server certificate has expired, the SEC_ERROR_REVOKED_CERTIFICATE error appears.

    NoteFor Hitachi Ops Center API Configuration Manager and other products that do not have a web GUI, you cannot use a web browser to check the revocation status. In such cases, see Checking the revocation status of the server certificate by using a command.

Checking the revocation status of the server certificate by using a command

You can check the revocation status of the server certificate by using the OCSP check function of the openssl command. For more details, see the openssl documentation.

Procedure

  1. On the management server, run the following openssl command.

    Command syntax:

    installation-directory-of-Common-Services/openssl/bin/openssl ocsp -no_nonce -issuer issuer-certificate -cert server-certificate -url OCSP-Responder-URI -text

    The issuer certificate is either the root certificate or, if there is an intermediate certificate, specify the PEM-format certificate that combines the root and intermediate certificates.

    Command example:

    /opt/hitachi/CommonService/openssl/bin/openssl ocsp -no_nonce -issuer cacert.cer -cert httpsd.cer -url http://ad.example.com/ocsp -text
  2. Check whether the value of Cert Status is good. If the value is revoked, the server certificate has expired.

Checking the revocation status of the server certificate on a regular basis

On the management server where Hitachi Ops Center products are installed, use cron to check the revocation status of the server certificate on a regular basis. The revocation status check results can be output to a file or to syslog.

Outputting the revocation status check results to a file

Output the revocation status of a server certificate to a file as follows. Register a command in cron and output the check results to a file.

Procedure

  1. Log in to the management server as the root user.

    If you log in as an ordinary user, use the sudo command to complete the following procedure as the root user.
  2. Modify the crontab file. Run the following command. For details on the command, see the crontab documentation.

    crontab -u root -e
  3. Add a command to the crontab file for each product whose revocation status you want to check. The command you set differs depending on how the server certificate of the product to be added is referenced.

    • If you check by downloading the certificate file from the URL of the Hitachi Ops Center product:

      Specify the execution time, the command to download the server certificate, and the command to query the OCSP responder in the following format.

      * * * * * command-to-download-the-server-certificate;command-to-query-the-OCSP-responder
      • Command syntax for downloading the server certificate:

        installation-directory-of-Common-Services/openssl/bin/openssl s_client -connect host-name-or-ip-address-of-product-URL:port-number-of-product-URL [-cipher Cipher-Suite] < /dev/null 2> path-of-the-standard-error-output-file | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > path-of-download-destination-of-server-certificate
        

        For products that use both RSA and ECDSA server certificates, you must specify the command for RSA and again for ECDSA. For the -cipher option, specify an RSA or ECDSA Cipher Suite supported by the target product.

        • Example:

          ECDHE-RSA-AES256-GCM-SHA384, ECDHE-ECDSA-AES256-GCM-SHA384

      • Command syntax for querying the OCSP responder:

        installation-directory-of-Common-Services/openssl/bin/openssl ocsp -no_nonce -issuer issuer-certificate -cert path-of-server-certificate -url OCSP-Responder-URI [ -proxy [http[s]://][userinfo-of-proxy@]host-name-or-IP-address-of-proxy[:port-number-of-proxy] [/path-of-proxy] ] [-CAfile root-certificate-of-the-OCSP-responder-server] -text -out path-of-the-file-to-which-the-results-are-output 2>> path-of-the-standard-error-output-file
    • If you check by referencing the certificate file set for the Hitachi Ops Center product:

      Specify the execution time and the command to query the OCSP responder in the following format.

      * * * * * command-to-query-the-OCSP-responder
      • Command syntax for querying the OCSP responder:

        installation-directory-of-Common-Services/openssl/bin/openssl ocsp -no_nonce -issuer issuer-certificate -cert path-of-server-certificate -url OCSP-Responder-URI [ -proxy [http[s]://][userinfo-of-proxy@]host-name-or-IP-address-of-proxy[:port-number-of-proxy] [/path-of-proxy] ] [-CAfile root-certificate-of-the-OCSP-responder-server] -text -out path-of-the-file-to-which-the-results-are-output 2> path-of-the-standard-error-output-file
    Note
    • Specify the execution time for each command. Specify a value for "* * * * *". If you want to run the command every day at 4:00 a.m., specify "0 4 * * *". For details, see the crontab documentation.
    • Specify different paths for path-of-the-file-to-which-the-results-are-output and path-of-the-standard-error-output-file for each command.
    • For the issuer-certificate for the command that queries the OCSP responder, either specify the root certificate or, if there is an intermediate certificate, specify the PEM-format certificate that combines the root and intermediate certificates.
    • To use a proxy for the command that queries the OCSP responder, specify the -proxy option.
    • If the Response Verify Failure error is output to standard-error-output-file, specify the -CAfile option.
    • For details on the openssl command, see the openssl documentation.
  4. Add a command for each product, specifying each command as described in step 3.

    Example settings:

    10 4 * * * command-for-product-1
    20 4 * * * command-for-product-2
    30 4 * * * command-for-product-3
  5. After you finish specifying the commands, save the crontab file.

  6. Run the following command to enable crond.service.

    systemctl enable crond.service
  7. Restart the service to apply the crond settings. Run the following command.

    systemctl restart crond

Results

  • At the specified time, a file is output to the directory specified in path-of-the-file-to-which-the-results-are-output. Check the value of Cert Status in the output file.
    • If the value is good: The server certificate is valid.
    • If the value is revoked: The server certificate has been revoked.
    • If the value is unknown: The status is unknown.
  • If the output file does not include the Cert Status line, an error might have occurred. For details about the error, check the file output to the directory specified in path-of-the-standard-error-output-file.

Outputting the revocation status check results to syslog

Output the revocation status of the server certificate to syslog as follows.

Procedure

  1. Register a command in cron for each product whose revocation status you want to check. For details on how to specify the command, see Outputting the revocation status check results to a file. To output the results to syslog, you do not need to specify the -out option.

  2. Change the crond settings. Open crond in a text editor such as vi editor and add -s to the CRONDARGS value. If you use the default value, the check results will be output to /var/log/cron.

    CRONDARGS=-s
  3. Restart the service to apply the crond settings. Run the following command.

    systemctl restart crond

Results

At the specified time, the results are output to syslog. Search the syslog file for Cert Status. The result will be good, revoked, or unknown.

Changing the management server host name, IP address, or port number

If you change the management server host name or IP address or the port number used by Common Services, run the cschgconnect command to change the URL for accessing the Hitachi Ops Center Portal.
  1. Log in to the management server as the root user.

    If you log in as an ordinary user, use the sudo command to complete the following procedure as the root user.
  2. Run the cschgconnect command.

    • Command location

      installation-directory-of-Common-Services/utility/bin/cschgconnect.sh

    • Format

      cschgconnect.sh [-h host-name-or-IP-address] [-p port-number] | -enableip {true|false} | -list
    • Options

      • -h host-name-or-IP-address

        Specify the host name (or FQDN) or IP address used to access the Hitachi Ops Center Portal. If you specify a host name (or FQDN), specify a value using no more than 128 characters. For the host name (or FQDN), you cannot specify uppercase characters. If you do, they are converted to lowercase characters and then registered.

        The management server on which Common Services and other relevant products are installed and the web browser used to access the Hitachi Ops Center Portal must be able to resolve and reach the host name (or FQDN) and IP address.

      • -p port-number

        Specify the port number used by Common Services.

        NoteIf you change the port number, you must also change the firewall setting.
      • -enableip {true|false}

        Specify whether an IP address can be used when the host name or FQDN is used in the URL for the Hitachi Ops Center Portal. To specify that the portal can be accessed by using an IP address, specify true. To specify that the portal cannot be accessed by using an IP address, specify false. The IP address for accessing the portal is automatically acquired from the system.

        This option and other options cannot be specified at the same time.

      • -list

        Displays the current settings. This option and other options cannot be specified at the same time.

        If you change the settings by using the -h, -p, or -enableip option, the settings displayed when you specify the -list option are not applied to the system until the Common Services service is restarted.

    NoteIf you use this command to change the host name or IP address to one that differs from the value set for CN or subjectAltName when the SSL server certificate was created, you must issue a new server certificate.
  3. Restart the Common Services service.

  4. Run cschgconnect.sh -list to check the result of the change.

  5. Make sure that you can use a web browser to access the login window at the following URL:

    https://host-name-or-IP-address:port-number/portal/

  6. For each product registered in Common Services, run the setupcommonservice command for registering the product in Common Services again.

    For details, see the documentation for each product.

Changing the port number used for internal communications

You can change the port number that Common Services uses for internal communications.
  1. Log in to the management server as the root user.

    If you log in as an ordinary user, use the sudo command to complete the following procedure as the root user.
  2. Change the port number.

    The procedure differs depending on the port number.
    Port numberChange procedure
    20951
    1. In the following property file, specify the port number after the change, and then save the file.

      • Property file location*

        /var/installation-directory-of-Common-Services/userconf/config_user.properties

      • Settings

        CS_PORTAL_PORT=port-number-after-change
        CS_GW_PORTAL_PORT=port-number-after-change
    2. Restart the Common Services service.
    20952
    1. In the following property file, specify the port number after the change, and then save the file.

      • Property file location*

        /var/installation-directory-of-Common-Services/userconf/config_user.properties

      • Settings

        CS_PORTAL_IDP_PORT=port-number-after-change
        CS_IDP_OP_HTTP_PORT=port-number-after-change
        CS_GW_IDP_PORT=port-number-after-change
    2. Restart the Common Services service.
    20954
    1. In the following property file, specify the port number after the change, and then save the file.

      • Property file location*

        /var/installation-directory-of-Common-Services/userconf/config_user.properties

      • Setting

        CS_PORTAL_IDP_POSTGRESQL_PORT=port-number-after-change
    2. In the following configuration definitions file, specify the port number after the change, and then save the file.

      • Definitions file location*

        /var/installation-directory-of-Common-Services/pgdata/csidp/data/postgresql.conf

      • Setting

        port = port-number-after-change # (change requires restart)
    3. Stop the Common Services service.
    4. Run the systemctl command to restart postgresql-15@csidp.
    5. Start the Common Services service.
    20955
    1. In the following property file, specify the port number after the change, and then save the file.

      • Property file location*

        /var/installation-directory-of-Common-Services/userconf/config_user.properties

      • Setting

        CS_PORTAL_POSTGRESQL_PORT=port-number-after-change
    2. In the following configuration definitions file, specify the port number after the change, and then save the file.

      • Definitions file location*

        /var/installation-directory-of-Common-Services/pgdata/csportal/data/postgresql.conf

      • Setting

        port = port-number-after-change # (change requires restart)
    3. Stop the Common Services service.
    4. Run the systemctl command to restart postgresql-15@csportal.
    5. Start the Common Services service.
    20956
    1. In the following property file, specify the port number after the change, and then save the file.

      • Property file location*

        /var/installation-directory-of-Common-Services/userconf/config_user.properties

      • Setting

        CS_PORTAL_MANAGEMENT_PORT=port-number-after-change
    2. Restart the Common Services service.

    * If you performed installation by using an OVA, the file is located in the following directory:

    /var/opt/hitachi/CommonService/userconf/

Configuring key-based authentication for the Analyzer detail view server

You can configure the key-based authentication to download data on the Analyzer detail view server when data is directly uploaded to the Analyzer detail view server (without an intermediate FTP server).

NoteFor best results:
  • Use unique SSH host keys for every host that is using SSH.
  • Implement an SSH key management solution.

Before you begin

If the SFTP server subsystem setting is configured as sftp internal-sftp in the /etc/ssh/sshd_config file, make sure that the following entry is also present in this file:

Match User meghadata
        ForceCommand internal-sftp -u 2

Procedure

  1. Log on to the Analyzer detail view server through an SSH client (like putty) as a root user.

  2. Switch to the megha user:

    su - megha
  3. Generate a key for the megha user:

    ssh-keygen -t rsa -b key_length

    NoteKey length can be 2048 or 4096.
  4. Press Enter to save the key in the folllowing directory under the installation directory (default: /data):

    /Installation_directory/megha/.ssh/id_rsa
    For example:
    /data/megha/.ssh/id_rsa
  5. (Optional) Enter a passphrase and confirm it.

    Note
    • You cannot use quotation marks or spaces at the beginning or end of a passphrase, nor can you use contiguous multiple spaces within a passphrase.
    • If you decide to use a passphrase, make sure you note it. You will need it when updating the data download settings.
    • If you do not want to enter passphrase, press Enter and confirm it. A blank value is set.
  6. Copy the public key:

    ssh-copy-id meghadata@localhost
  7. When prompted for the password, enter the meghadata user password (default: meghadata123).

  8. Switch to the root user:

    su - root
  9. Configure the SELinux security context in the /etc/selinux/targeted/contexts/files/file_contexts.local file for the following directories available under the Analyzer detail view server installation directory (default: /data).

    • /Installation_directory/meghadata/.ssh directory:

      For example:

      semanage fcontext -a -t ssh_home_t /data/meghadata/.ssh
    • /Installation_directory/meghadata/.ssh/authorized_keys file:

      For example:

      semanage fcontext -a -t ssh_home_t /data/meghadata/.ssh/authorized_keys
  10. Use the restorecon command to change file type to ssh_home_t for the following directories available under the Analyzer detail view server installation directory (default: /data):

    • /Installation_directory/meghadata/.ssh directory:

      For example:

      restorecon -R -v /data/meghadata/.ssh
    • /Installation_directory/meghadata/.ssh/authorized_keys file:

      For example:

      restorecon -R -v /data/meghadata/.ssh/authorized_keys
    • Verify the type has been changed to ssh_home_t:
      ls -Z -a /Installation_directory/meghadata/.ssh

      For example:

      ls -Z -a /data/meghadata/.ssh
  11. Restart the sshd service:

    service sshd restart

Next steps

By default, password-based authentication is configured for downloading data to the Analyzer detail view server. If you want to switch to key-based authentication, see Updating the downloader on the Analyzer detail view server.

Configuring key-based authentication to transfer data directly from Analyzer probe server to Analyzer detail view server

Key-based authentication helps you to transfer data directly (without an intermediate FTP or FTPS server) from the Analyzer probe server to the Analyzer detail view server using the SFTP protocol with the meghadata user.
NoteFor best results:
  • Use unique SSH host keys for every host that is using SSH.
  • Implement a SSH key management solution.

Follow these procedures to configure key-based authentication:

  1. Configure the Analyzer probe server
  2. Configure the Analyzer detail view server
Configure the Analyzer Probe server

Follow these steps:

  1. Log on to the Analyzer probe server through an SSH client (like putty) as a root user.
  2. Change ownership and permission of the .ssh directory available under the Analyzer probe server installation directory.
    chown megha:megha /Installation_directory/megha/.ssh
    
    chmod 700 /Installation_directory/megha/.ssh

    For example:

    chown megha:megha /home/megha/.ssh
    
    chmod 700 /home/megha/.ssh
  3. Switch to the megha user:
    su - megha
  4. Generate a key for the megha user:
    ssh-keygen -t rsa -b key_length

    NoteKey length can be 2048 or 4096.

    For example:

    ssh-keygen -t rsa -b 2048
  5. Press Enter to save the key in the folllowing location:
    /Installation_directory/megha/.ssh/id_rsa
    For example:
    /home/megha/.ssh/id_rsa
  6. (Optional) Enter a passphrase and confirm it.
    NoteIf you decide to use a passphrase, make sure you note it. You will need this when configuring the following settings on the Analyzer probe server to transfer data:
    • Configuring data transfer settings when setting up the Analyzer probe server
    • Adding a secondary Analyzer detail view server
    • Editing an Analyzer detail view server (primary and secondary)
  7. Copy the public key to the Analyzer detail view server:
    ssh-copy-id meghadata@Analyzer_detail_view_server_IP_address_or_hostname

    For example:

    ssh-copy-id meghadata@192.168.35.31
  8. When prompted for the password, enter the meghadata user password (default: meghadata123).
Configure the Analyzer detail view server

Follow these steps on the Analyzer detail view server:

  1. Log on to the Analyzer detail view server through an SSH client (like putty) as a root user.
  2. Configure the SELinux security context in the /etc/selinux/targeted/contexts/files/file_contexts.local file for the following directories available under the Analyzer detail view server installation directory (default: /data).
    1. /Installation_directory/meghadata/.ssh directory:

      For example:

      semanage fcontext -a -t ssh_home_t /data/meghadata/.ssh
    2. /Installation_directory/meghadata/.ssh/authorized_keys file:

      For example:

      semanage fcontext -a -t ssh_home_t /data/meghadata/.ssh/authorized_keys
  3. Change file type to ssh_home_t for the following directories available under the Analyzer detail view server installation directory (default: /data):
    1. /Installation_directory/meghadata/.ssh directory:

      For example:

      restorecon -R -v /data/meghadata/.ssh
    2. /Installation_directory/meghadata/.ssh/authorized_keys file:

      For example:

      restorecon -R -v /data/meghadata/.ssh/authorized_keys
    3. Verify if the type has been changed to ssh_home_t:
      ls -Z -a /Installation_directory/meghadata/.ssh

Next steps

Make sure that you switch to the key-based authentication and SFTP protocol in the Analyzer probe UI (select Reconfigure Analyzer detail view server Server Details).

Registering Analyzer detail view server with Common Services

If you want to use Common Services installed on a different host, or you installed Analyzer detail view server using the stand-alone OVA or installer, you must register Analyzer detail view server with Common Services.

If you deployed the Ops Center consolidated OVA, Analyzer detail view is already registered in Common Services.

Before you begin

Verify the following:

  • The host name of Common Services is resolvable from the Analyzer detail view server.
  • The Analyzer detail view server and Common Services are running.
  • SSL is configured for the Analyzer detail view server and Common Services.
  • A user account exists with Common Services that has Administrator permissions.

Procedure

  1. Log on to the Analyzer detail view server through an SSH client (like putty) as a root user.

  2. Navigate to the following directory:

    /usr/local/megha/bin
  3. Run the setupcommonservice command to register the Analyzer detail view server with Common Services.

    setupcommonservice -csUri Common-Services-URL -csUsername Common-Services-user-name -appHostname Analyzer-detail-view-server-host-name-or-IP-address -appPort Analyzer-detail-view-server-port -appName product-name-to-display-in-the-portal -appDescription description-todisplay-in-the-portal
    

    Use the -help option for command usage information.

    The following is an example to register a new instance of Analyzer detail view server in Common Services:

    setupcommonservice -csUri https://myopscenter.com:443/portal -
    csUsername sysadmin -appHostname mydetailview.com -appPort 8443 -
    appName detailview_B -appDescription "detail view B"
    Note
    • The Common-Services-user-name must not contain greater than and less than signs (< >), Square brackets ([ ]), spaces, double quotation mark ("), colon (:), or ampersand (&).
    • The Analyzer-detail-view-server-host-name-or-IP-address must contain the correct host name or IP address.
  4. Enter the password of the Common Services user.

Results

Analyzer detail view server is shown in the Common Services.

NoteYou cannot unregister a Hitachi Ops Center product using the setupcommonservice command. To delete products, use the Ops Center Portal.

Registering Analyzer probe server with Common Services

If you want to use Common Services installed on a different host, or you installed Analyzer probe server using the stand-alone OVA or installer, you must register Analyzer probe server with Common Services.

Before you begin

Verify the following:

  • The host name of Common Services is resolvable from the Analyzer probe server.
  • The Analyzer probe server and Common Services are running.
  • SSL is configured for the Analyzer probe server and Common Services.
  • A user account exists with Common Services that has Administrator permissions.

Procedure

  1. Log on to the Analyzer probe server through an SSH client (like putty) as a root user.

  2. Navigate to the following directory:

    /usr/local/megha/bin
  3. Run the setupcommonservice command to register Analyzer probe server with Common Services.

    setupcommonservice -csUri Common-Services-URL -csUsername Common-Services-user-name -appHostname Analyzer-probe-server-host-name-or-IP-address -appPort Analyzer-probe-server-port -appName product-name-to-display-in-the-portal -appDescription description-todisplay-in-the-portal
    

    Use the -help option for command usage information.

    The following is an example to register a new instance of Analyzer probe server in Common Services:

    setupcommonservice -csUri https://myopscenter.com:443/portal -
    csUsername sysadmin -appHostname myprobe.com -appPort 8443 -appName
    probe_B -appDescription "probe B"
    Note
    • The Common-Services-user-name must not contain greater than and less than signs (< >), Square brackets ([ ]), spaces, double quotation mark ("), colon (:), and ampersand (&).
    • The Analyzer-detail-view-server-host-name-or-IP-address must contain the correct host name or IP address.
  4. Enter the password of the Common Services user.

Results

Analyzer probe server is shown in the Common Services.

NoteYou cannot unregister a Hitachi Ops Center product using the setupcommonservice command. To delete products, use the Ops Center Portal.

Updating the downloader on the Analyzer detail view server

You must update the downloader details on the Analyzer detail view server if any of the following conditions apply:

  • You are currently downloading the data from an intermediate FTP server and you need to update the connection details for the Analyzer detail view server or intermediate FTP server.
  • You are directly uploading data to the Analyzer detail view server (without an intermediate FTP server) and you want to switch between password-based authentication and key-based authentication.

Before you begin

NoteIf you do not want to stop the crond service, you can stop specific processes of the Analyzer detail view server and Analyzer probe server by using the crontab -e command as described in Stopping the Analyzer detail view server or Analyzer probe server services and Starting the Analyzer detail view server or Analyzer probe server services

Procedure

  1. Log on to the Analyzer probe server through an SSH client (like putty) as a root user.

  2. Stop the crond service using the command:

    service crond stop
  3. Stop the megha service using the command:

    /usr/local/megha/bin/megha-jetty.sh stop
  4. Verify the stopped status of the megha service:

    /usr/local/megha/bin/megha-jetty.sh status
  5. Run the update FTP configuration script to update the FTP server details:

    • If you are downloading the data from an intermediate FTP server using the password-based authentication and you want to update the connection details for the Analyzer detail view server or intermediate FTP server:
      • To download data of all the Analyzer probe server appliances:
        sh /usr/local/megha/bin/createOrUpdateFTPConfiguration.sh --update --authType Password-Based --ftpServer FTP-server-hostname-or-IP-address --ftpMethod FTP-method-(FTP/FTPS/SFTP) --ftpPort FTP-port --ftpUsername FTP-username --ftpPassword

        For example:

        sh /usr/local/megha/bin/createOrUpdateFTPConfiguration.sh --update --authType Password-Based --ftpServer 192.168.1.2 --ftpMethod SFTP --ftpPort 22 --ftpUsername abc --ftpPassword
        Note
        • The authType, ftpServer, and ftpUsername parameters are mandatory.
        • You cannot update the value of the ftpServer and ftpUsername parameters.
        • The value for the authType parameter must be Password-Based to download the data from an intermediate FTP server.
        • You can update the FTP server password, port, and FTP method. You can update all or one of these details. For example, if you want to update only the FTP method, enter only the ftpMethod parameter and its value.
        • If you want to change the password, enter only the ftpPassword parameter. Do not enter any value for it. You can define the password in the next step.
      • To download the data of the specific Analyzer probe server appliance:
        sh /usr/local/megha/bin/createOrUpdateFTPConfiguration.sh --update --authType Password-Based --ftpServer FTP-server --ftpMethod FTP-method-(FTP/FTPS/SFTP) --ftpPort FTP-port --ftpUsername FTP-username --ftpPassword --applianceidOption ApplianceIds --applianceidList Appliance-ID-list-separated-by-comma

        For example:

        sh /usr/local/megha/bin/createOrUpdateFTPConfiguration.sh --update --authType Password-Based --ftpServer 192.168.1.2 --ftpMethod SFTP --ftpPort 22 --ftpUsername abc --ftpPassword --applianceidOption ApplianceIds --applianceidList 1c5fbdd9-8ed3-43fe-8973-e9cba6d103c6,39cfcb01-11b2-46b4-8fce-b4d84ea5acda
        
        Note
        • The authType, ftpServer, and ftpUsername parameters are mandatory.
        • You cannot update the value of the ftpServer and ftpUsername parameters.
        • The value for the authType parameter must be Password-Based to download the data from an intermediate FTP server.
        • You can add new appliance IDs or you can remove the existing appliance IDs.
        • You can update the FTP server password, port, and FTP method. You can update all or one of these details. For example, if you want to update only the FTP method, enter only the ftpMethod parameter and its value.
        • You should use the ftpPassword parameter if you are downloading the data from an intermediate FTP server. To change the password, enter only the ftpPassword parameter. Do not enter any value for it. You can define the password in the next step.
    • To switch between password-based authentication and key-based authentication:
      • Switching to key-based authentication:
        sh /usr/local/megha/bin/createOrUpdateFTPConfiguration.sh --update --authType Key-Based --ftpServer localhost --ftpMethod SFTP --ftpPort FTP-Port --ftpUsername meghadata --keyPassphrase

        For example:

        sh /usr/local/megha/bin/createOrUpdateFTPConfiguration.sh --update --authType Key-Based --ftpServer localhost --ftpMethod SFTP --ftpPort 22 --ftpUsername meghadata --keyPassphrase
      • Switching to password-based authentication:
        sh /usr/local/megha/bin/createOrUpdateFTPConfiguration.sh --update --authType Password-Based --ftpServer localhost --ftpMethod FTP-method-(FTP/FTPS/SFTP) --ftpPort FTP-Port --ftpUsername meghadata --ftpPassword

        For example:

        sh /usr/local/megha/bin/createOrUpdateFTPConfiguration.sh --update --authType Password-Based --ftpServer localhost --ftpMethod SFTP --ftpPort 22 --ftpUsername meghadata --ftpPassword
      Note
      • The authType, ftpServer and ftpUsername parameters are mandatory.
      • You cannot update the value of the ftpServer, ftpUsername, and ftpPassword parameters. If you want to change the ftpPassword of the meghadata user, use the changePassword.sh command. See Changing the megha and meghadata passwords for more information.
      • Key-based authentication only supports the SFTP method
      • You must enter the keyPassphrase parameter when switching to key-based authentication for the first time. When configuring key-based authentication to download data to Analyzer detail view server:
  6. Enter the passphrase or blank value if you have provided the keyPassphrase parameter or enter the meghadata user password if you have provided the ftpPassword parameter.

  7. Start the megha service using the following command:

    /usr/local/megha/bin/megha-jetty.sh start
  8. Start the crond service using the following command:

    service crond start

Changing the megha and meghadata passwords

You should change the megha and meghadata user passwords to enhance the security. The megha user exists on both the Analyzer detail view server and the Analyzer probe server. The Analyzer probe server does not have a meghadata account.

NoteYou can also use this procedure if the current megha or meghadata user password has expired.

If a security policy for the maximum number of login attempts is enabled in your environment, you must disable it before changing the megha and meghadata passwords. After completing the procedure, you can re-enable the setting.

NoteIf you do not want to stop the crond service, you can stop specific processes of the Analyzer detail view server and Analyzer probe server by using the crontab -e command as described in Stopping the Analyzer detail view server or Analyzer probe server services and Starting the Analyzer detail view server or Analyzer probe server services

Procedure

  1. Log on to the Analyzer detail view server or Analyzer probe server through an SSH client (like putty) as a root user.

  2. Stop the crond service using the command:

    service crond stop
  3. Stop the megha service using the command:

    /usr/local/megha/bin/megha-jetty.sh stop
  4. Verify the stopped status of the megha service:

    /usr/local/megha/bin/megha-jetty.sh status
  5. Run the change password script:

    /usr/local/megha/bin/changePassword.sh --user
  6. Choose the account you want to change.

  7. Type the user password and confirm it.

    NotePasswords can contain uppercase and lowercase letters, numbers, and the following special characters:

    @, !, ~, #, $, `, %, ^, &, *, (, ), -, _, =, +, {, }, <, >, [, ], \

  8. Start the megha service using the following command:

    /usr/local/megha/bin/megha-jetty.sh start
  9. Start the crond service using the following command:

    service crond start

Next steps

If the Analyzer probe server is uploading the data directly to an Analyzer detail view server for which you have changed the meghadata user password, you must also update the meghadata user password on the Analyzer probe server. To change the password, log on to the Analyzer probe server and then go to the Home Reconfigure Analyzer detail view Server tab.

Stopping unnecessary product services

After deploying the Ops Center OVA, you can stop the services of products that you do not use, and specify not to start the services when the OS starts.

After the OVA is deployed, as a best practice, we recommend that you remove any products that are not being used. If you decide not to remove them, you can use the opsvmservicectl command to stop multiple product services at the same time. You can also use the command to change the setting so that the services do not start when the OS starts.

NoteThe opsvmservicectl command is installed with version 10.1.0 or a later of the Ops Center OVA. If the individual installer or a version of the OVA earlier than 10.1.0 was used, uninstall any unnecessary products.

Before you begin

After you deploy the OVA and finish the configuration using the setup tool (opsvmsetup).

Procedure

  1. From a VMware vSphere client, log in to the guest OS as the root user.

  2. Run the opsvmservicectl command to stop the services for the products that are not needed.

    • Format

      opsvmservicectl {disable|enable} product-name [product-name ...]
    • Options

      • disable

        Stops the services for the specified products and prevents them from starting automatically when the OS starts. After you stop the services, the products remain registered in Common Services.

      • enable

        Starts the services for the specified products and changes the setting so that the services automatically start when the OS starts.

      • product-name

        Specify the target products by specifying the following values. To specify multiple products, use spaces to separate the products.

        Product name

        Value to specify

        Hitachi Ops Center Automator

        Automator

        Hitachi Ops Center Analyzer

        Analyzer

        Hitachi Ops Center Analyzer detail view

        AnalyzerDetailView

        Hitachi Ops Center API Configuration Manager

        APIConfigurationManager

        Hitachi Ops Center Protector

        Protector

        Hitachi Ops Center Administrator

        Administrator

        Hitachi Ops Center Common Services

        CommonServices
        NoteDo not perform an upgrade installation of a product that is disabled by using the opsvmservicectl command, because the product might not operate correctly.
  3. Check the results by running the following command:

    opsvmservicectl status
  4. To delete the products, log in to the Hitachi Ops Center Portal and remove them.

Resetting the trust relationship with each product

If unauthorized access to Common Services occurs or unauthorized operations are performed on the Common Services settings, information such as tokens exchanged between Common Services and each product might be leaked. In this case, reset and disable the information that might have been compromised.
  1. Log in to the management server as the root user.

    If you log in as an ordinary user, use the sudo command to complete the following procedure as the root user.
  2. Run the csresettrustrelationship command.

    • Command location

      installation-directory-of-Common-Services/utility/bin/csresettrustrelationship.sh

    • Format

      csresettrustrelationship.sh -f
    • Option

      • -f

        Specify this option if you run this command. If you omit this option, the command usage is displayed.

    • Output file

      The results of running the command are output to the following file:

      /var/log/hitachi/CommonService/utility/result_reset_secert.json

    Note
    • If you run this command, logged-in users might be forcibly logged out.
    • This command runs for a period from several minutes to several tens of minutes, depending on the system configuration.
    • When the command finishes running, Common Services restarts.
  3. Check the content of the output file.

    Make sure that the value of the status key is SUCCESS for both the resetSecretResult object and the resetKeyResult object.

    If the value is ERROR, restart Common Services, and then rerun the command. If this does not resolve the problem, collect the failure information, and contact customer support.

  4. If you are linking with the identity provider by using the SAML protocol, update the metadata for Common Services in AD FS.

    This step is required because, when you reset the trust relationship, the authentication key of Common Services is forcibly updated.

    For details of the procedure, see Updating the Common Services metadata by using AD FS

  5. Run the setupcommonservice command for each product registered in Common Services.

  6. Restart the service of each product registered in Common Services.

Applying Linux security updates using yum

You can collectively (or selectively) apply OS security updates using the yum command. First, you must configure your server to access the RPM packages from the Linux OS media or the distribution website.
Accessing the RPM packages using the Linux OS media
  1. Mount the Linux OS media and obtain the RPM packages:
    mkdir /media/OSImage
    mount /dev/cdrom /media/OSImage
  2. Configure the yum repository.

    For version 7 of Red Hat Enterprise Linux or Oracle Linux:

    touch /etc/yum.repos.d/OSImage.repo
    echo [dvd]>>/etc/yum.repos.d/OSImage.repo
    echo name=dvd>>/etc/yum.repos.d/OSImage.repo
    echo baseurl=file:///media/OSImage/>>/etc/yum.repos.d/OSImage.repo
    echo gpgcheck=0>>/etc/yum.repos.d/OSImage.repo
    echo enabled=1>>/etc/yum.repos.d/OSImage.repo

    For version 8 or 9 of Red Hat Enterprise Linux or Oracle Linux:

    touch /etc/yum.repos.d/OSImage.repo
    echo [dvd-baseos]>>/etc/yum.repos.d/OSImage.repo
    echo name=dvd-baseos>>/etc/yum.repos.d/OSImage.repo
    echo baseurl=file:///media/OSImage/BaseOS/>>/etc/yum.repos.d/OSImage.repo
    echo gpgcheck=0>>/etc/yum.repos.d/OSImage.repo
    echo enabled=1>>/etc/yum.repos.d/OSImage.repo
    echo >>/etc/yum.repos.d/OSImage.repo
    echo [dvd-appstream]>>/etc/yum.repos.d/OSImage.repo
    echo name=dvd-appstream>>/etc/yum.repos.d/OSImage.repo
    echo baseurl=file:///media/OSImage/AppStream/>>/etc/yum.repos.d/OSImage.repo
    echo gpgcheck=0>>/etc/yum.repos.d/OSImage.repo
    echo enabled=1>>/etc/yum.repos.d/OSImage.repo
Accessing the RPM packages using the distribution website
  1. Specify the repository to which the yum command will connect.
  2. If you are using a proxy, specify the proxy for the yum command:
    1. Add the following information to the /etc/yum.conf file:
      proxy=http://host-name:port-number
      proxy_username=user-name
      proxy_password=password
    2. Clear the cache for the yum command.
      yum clean all
Using the yum command

To update all packages for which security-related errata are available (including packages with bug fixes or new features without security errata):

yum --security --exclude kernel* --exclude *podman* --exclude *containers-common* upgrade

To update all packages for which security-related errata are available (ignoring any newer packages without security errata):

yum --security --exclude kernel* --exclude *podman* --exclude *containers-common* upgrade-minimal

To update all kernel and podman packages to the latest supported versions that contain security errata, follow these examples.

For Red Hat kernel (must specify supported kernel version):

yum --security upgrade-minimal kernel-4.18.0-305.*

For Unbreakable Enterprise kernel (must specify supported uek kernel version):

yum --security upgrade-minimal kernel-uek-5.4.17-2102.*

For podman (must specify supported podman version):

yum --security upgrade-minimal podman-3.3.*

You can also update only those packages that correspond to a CVE or erratum, as in the following examples:

yum --cve CVE-2021-37576 upgrade-minimal

For Red Hat Enterprise Linux:

yum --advisory RHSA-2021:4056 upgrade-minimal

For Oracle Linux:

yum --advisory ELSA-2021-9474 upgrade-minimal

Replacing Command Control Interface

You can replace an individually installed instance of Command Control Interface with an instance of Command Control Interface installed by the Express installer, or replace an instance of Command Control Interface installed by the Express installer with an individually installed instance of Command Control Interface.

Switching to an instance of Command Control Interface installed by the Express installer

You can replace an individually installed instance of Command Control Interface with that installed by the Express installer.
  1. If Ops Center API Configuration Manager or Ops Center Protector is installed, stop the service.

    For details on how to stop the service, see the manual for the relevant product.
  2. Run the ps command to check for Command Control Interface processes that are running.

    ps aux
    From the list that appears, look for items in the format horcmd_number. (There might be more than one such item.)
  3. If any processes are running, run the following command to stop the Command Control Interface service:

    In the following, number consists of the fixed value 0 and instance-number. If there are multiple items in the format horcmd_number, specify each of instance-number separated by a space.
    horcmshutdown.sh instance-number
  4. Run the following command to uninstall Command Control Interface:

    /HORCM/horcmuninstall.sh
  5. Run the following command to delete the Command Control Interface installation directory:

    rm -rf $(readlink /HORCM)
  6. Run the following command to delete the Command Control Interface symbolic link:

    rm /HORCM
  7. Use the Express installer to install Command Control Interface. Select Ops Center API Configuration Manager or Ops Center Protector as the product to be installed and then perform the installation.

Switching to an individually installed instance of Command Control Interface

You can replace an instance of Command Control Interface installed by the Express installer with an individually installed instance.
  1. If Ops Center API Configuration Manager or Ops Center Protector is installed, stop the service.

    For details on how to stop the service, see the manual for the relevant product.
  2. Run the ps command to check for Command Control Interface processes that are running.

    ps aux
    From the list that appears, look for items in the format horcmd_number. (There might be more than one such item.)
  3. If any processes are running, run the following command to stop the Command Control Interface service:

    In the following, number consists of the fixed value 0 and instance-number. If there are multiple items in the format horcmd_number, specify each of instance-number separated by a space.
    horcmshutdown.sh instance-number
  4. Run the following command to uninstall Command Control Interface:

    /HORCM/horcmuninstall.sh
  5. Run the following command to delete the Command Control Interface installation directory:

    rm -rf $(readlink /HORCM)
  6. Run the following command to delete the Command Control Interface symbolic link:

    rm /HORCM
  7. Install Command Control Interface.

    For details on the installation method, see the Command Control Interface manual.
  8. Start the service of Ops Center API Configuration Manager or Ops Center Protector. For details on how to start the service, see the manual for the relevant product.

Upgrading Amazon Corretto 17

If a vulnerability is found in Amazon Corretto 17, upgrade Amazon Corretto 17.
  1. Log in to the management server as the root user.

    If you log in as an ordinary user, use the sudo command to complete the following procedure as the root user.
  2. Download Amazon Corretto 17, and store it on the management server where Common Services is installed.

    For details on the versions of Amazon Corretto 17 that are supported by Common Services, see the Common Services Release Notes.
  3. Stop the Common Services service.

    NoteIf products that use Amazon Corretto 17 are installed on the management server, stop the services of those products as needed.
  4. Run the rpm command with the --nopost option specified to upgrade Amazon Corretto 17.

  5. Start the Common Services service.

    NoteIf products that use Amazon Corretto 17 are installed on the management server, start the services of those products as needed.

Upgrading PostgreSQL 15

If a vulnerability is found in PostgreSQL 15, upgrade PostgreSQL 15.
  1. Log in to the management server as the root user.

    If you log in as an ordinary user, use the sudo command to complete the following procedure as the root user.
  2. Download PostgreSQL 15, and store it on the management server where Common Services is installed.

    For details on the versions of PostgreSQL 15 that are supported by Common Services, see the Common Services Release Notes.
  3. Stop the Common Services service.

  4. Run the following command to stop the Common Services database:

    systemctl stop postgresql-15@csportal.service postgresql-15@csidp.service
  5. Run the rpm command to upgrade the RPM package for PostgreSQL 15.

    rpm -Uv PostgreSQL-15-package-name postgresql15-libs-package-name postgresql15-server-package-name
  6. Run the following command to start the Common Services database:

    systemctl start postgresql-15@csportal.service postgresql-15@csidp.service
  7. Start the Common Services service.

 

  • Was this article helpful?