Maintain Hitachi Ops Center
Checking the validity period of a certificate in the truststore
Procedure
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
Procedure
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
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:
- Web browser: Checking the revocation status of the server certificate by using a web browser
- openssl command: Checking the revocation status of the server certificate by using a command
- Automatically by using cron: Checking the revocation status of the server certificate on a regular basis
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
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.
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
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
Check whether the value of
Cert Status
isgood
. If the value isrevoked
, the server certificate has expired.
Checking the revocation status of the server certificate on a regular basis
Outputting the revocation status check results to a file
Procedure
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.Modify the crontab file. Run the following command. For details on the command, see the crontab documentation.
crontab -u root -e
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
- Command syntax for downloading the server
certificate:
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
- Command syntax for querying the OCSP
responder:
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.
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 …
After you finish specifying the commands, save the crontab file.
Run the following command to enable crond.service.
systemctl enable crond.service
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 value is
- 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
Procedure
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.Change the crond settings. Open crond in a text editor such as vi editor and add
-s
to theCRONDARGS
value. If you use the default value, the check results will be output to /var/log/cron.CRONDARGS=-s
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
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.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 forCN
orsubjectAltName
when the SSL server certificate was created, you must issue a new server certificate.Restart the Common Services service.
Run
cschgconnect.sh -list
to check the result of the change.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/
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
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.Change the port number.
The procedure differs depending on the port number.Port number Change procedure 20951 -
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
- Restart the Common Services service.
20952 -
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
- Restart the Common Services service.
20954 -
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
-
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)
- Stop the Common Services service.
- Run the systemctl command to restart
postgresql-15@csidp
. - Start the Common Services service.
20955 -
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
-
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)
- Stop the Common Services service.
- Run the systemctl command to restart
postgresql-15@csportal
. - Start the Common Services service.
20956 -
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
- 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).
- 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
Log on to the Analyzer detail view server through an SSH client (like putty) as a root user.
Switch to the megha user:
su - megha
Generate a key for the megha user:
ssh-keygen -t rsa -b key_length
NoteKey length can be 2048 or 4096.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
(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.
Copy the public key:
ssh-copy-id meghadata@localhost
When prompted for the password, enter the meghadata user password (default:
meghadata123
).Switch to the root user:
su - root
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
Use the
restorecon
command to change file type tossh_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
Restart the sshd service:
service sshd restart
Next steps
Configuring key-based authentication to transfer data directly from Analyzer probe server to Analyzer detail view server
- 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:
Follow these steps:
- Log on to the Analyzer probe server through an SSH client (like putty) as a root user.
- 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
- Switch to the megha user:
su - megha
- 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
- Press Enter to save the key in the folllowing location:
/Installation_directory/megha/.ssh/id_rsa
For example:/home/megha/.ssh/id_rsa
- (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)
- 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
- When prompted for the password, enter the meghadata user password (default:
meghadata123
).
Follow these steps on the Analyzer detail view server:
- Log on to the Analyzer detail view server through an SSH client (like putty) as a root user.
- 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
- 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 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
).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.
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
Log on to the Analyzer detail view server through an SSH client (like putty) as a root user.
Navigate to the following directory:
/usr/local/megha/bin
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.
Enter the password of the Common Services user.
Results
Analyzer detail view server is shown in the Common Services.
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
Log on to the Analyzer probe server through an SSH client (like putty) as a root user.
Navigate to the following directory:
/usr/local/megha/bin
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.
Enter the password of the Common Services user.
Results
Analyzer probe server is shown in the Common Services.
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
Procedure
Log on to the Analyzer probe server through an SSH client (like putty) as a root user.
Stop the crond service using the command:
service crond stop
Stop the megha service using the command:
/usr/local/megha/bin/megha-jetty.sh stop
Verify the stopped status of the megha service:
/usr/local/megha/bin/megha-jetty.sh status
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
, andftpUsername
parameters are mandatory. - You cannot update the value of the
ftpServer
andftpUsername
parameters. - The value for the
authType
parameter must bePassword-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.
- The
- 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
, andftpUsername
parameters are mandatory. - You cannot update the value of the
ftpServer
andftpUsername
parameters. - The value for the
authType
parameter must bePassword-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 theftpPassword
parameter. Do not enter any value for it. You can define the password in the next step.
- The
- To download data of all the Analyzer probe server
appliances:
- 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
andftpUsername
parameters are mandatory. - You cannot update the value of the
ftpServer
,ftpUsername
, andftpPassword
parameters. If you want to change theftpPassword
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:- If you have provided a passphrase, you must enter it when prompted.
- If you set a blank passphrase, press Enter when prompted.
See Configuring key-based authentication for the Analyzer detail view server for more information.
- Switching to key-based
authentication:
- 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:
Enter the passphrase or blank value if you have provided the
keyPassphrase
parameter or enter the meghadata user password if you have provided theftpPassword
parameter.Start the megha service using the following command:
/usr/local/megha/bin/megha-jetty.sh start
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.
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.
Procedure
Log on to the Analyzer detail view server or Analyzer probe server through an SSH client (like putty) as a root user.
Stop the crond service using the command:
service crond stop
Stop the megha service using the command:
/usr/local/megha/bin/megha-jetty.sh stop
Verify the stopped status of the megha service:
/usr/local/megha/bin/megha-jetty.sh status
Run the change password script:
/usr/local/megha/bin/changePassword.sh --user
Choose the account you want to change.
Type the user password and confirm it.
NotePasswords can contain uppercase and lowercase letters, numbers, and the following special characters:@, !, ~, #, $, `, %, ^, &, *, (, ), -, _, =, +, {, }, <, >, [, ], \
Start the megha service using the following command:
/usr/local/megha/bin/megha-jetty.sh start
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
.Stopping unnecessary product services
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.
Before you begin
After you deploy the OVA and finish the configuration using the setup tool (opsvmsetup).
Procedure
From a VMware vSphere client, log in to the guest OS as the root user.
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.
Check the results by running the following command:
opsvmservicectl status
To delete the products, log in to the Hitachi Ops Center Portal and remove them.
Resetting the trust relationship with each product
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.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.
Check the content of the output file.
Make sure that the value of the
status
key isSUCCESS
for both theresetSecretResult
object and theresetKeyResult
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.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
Run the setupcommonservice command for each product registered in Common Services.
Restart the service of each product registered in Common Services.
Applying Linux security updates using yum
- Mount the Linux OS media and obtain the RPM packages:
mkdir /media/OSImage mount /dev/cdrom /media/OSImage
- 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
- Specify the repository to which the
yum command will connect.
- For Red Hat Enterprise Linux, register the system by using Red Hat Subscription Management. For details, see https://access.redhat.com/articles/11258.
- For Oracle Linux, the initial settings are set by default (the file repo is already located in the directory /etc/yum.repos.d). For details, see http://yum.oracle.com/getting-started.html.
- If you are using a proxy, specify the proxy for the
yum command:
- Add the following information to the
/etc/yum.conf file:
proxy=http://host-name:port-number proxy_username=user-name proxy_password=password
- Clear the cache for the
yum command.
yum clean all
- Add the following information to the
/etc/yum.conf file:
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
- To replace an individually installed instance of Command Control Interface with an instance of Command Control Interface installed by the Express installer, perform the procedure described in Switching to an instance of Command Control Interface installed by the Express installer.
- To replace an instance of Command Control Interface installed by the Express installer with an individually installed instance of Command Control Interface, perform the procedure described in Switching to an individually installed instance of Command Control Interface.
Switching to an instance of Command Control Interface installed by the Express installer
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.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.)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
Run the following command to uninstall Command Control Interface:
/HORCM/horcmuninstall.sh
Run the following command to delete the Command Control Interface installation directory:
rm -rf $(readlink /HORCM)
Run the following command to delete the Command Control Interface symbolic link:
rm /HORCM
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
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.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.)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
Run the following command to uninstall Command Control Interface:
/HORCM/horcmuninstall.sh
Run the following command to delete the Command Control Interface installation directory:
rm -rf $(readlink /HORCM)
Run the following command to delete the Command Control Interface symbolic link:
rm /HORCM
Install Command Control Interface.
For details on the installation method, see the Command Control Interface manual.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
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.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.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.Run the rpm command with the
--nopost
option specified to upgrade Amazon Corretto 17.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
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.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.Stop the Common Services service.
Run the following command to stop the Common Services database:
systemctl stop postgresql-15@csportal.service postgresql-15@csidp.service
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
Run the following command to start the Common Services database:
systemctl start postgresql-15@csportal.service postgresql-15@csidp.service
Start the Common Services service.