Post-core component installation tasks
Install required RPM packages on Redhat Enterprise Linux 8 (RHEL 8.x)
Run the following command when installing MainView Middleware Monitorservices on RHEL 8.x:
yum install libnsl
Install a required compatibiltiy package on SUSE Enterprise Linux 15 (SLES 15.x)
Run the following command when installing MainView Middleware Monitorservices on SLES 15.x:
Start services
Following installation, you must start the MainView Middleware Monitor (MVMM ) services in the correct order.
Start and stop order
In addition to the required start and stop order for services, the following table includes the program name for the services.
Start order | Services | Program | Stop order |
|---|---|---|---|
1 | MVMM Application Service | qpas | 6 |
2 | MVMM Topic Service | qpts | 5 |
3 | MVMM Event Service | qpes | 4 |
4 | MVMM History Service | qphs | 3 |
5 | MVMM Client Gateway Service | qpcgateway | 2 |
6 | (Optional) MVMM ProactiveNet Service | qpps | 1 |
Before you begin
On UNIX systems, ensure that the UNIX userid that starts the services has read access to /dev/random and /dev/urandom.
To start the services on Windows
- Open the Windows Service Control Manager.
- Scroll through the services, and locate MVMM Application Service. The status of the service is displayed as Started if it is running or blank if it is stopped.
- Select MVMM Application Service and click Start. A dialog box appears indicating the service is being started.
- If the service does not start, verify that the service is proxy configured with a valid user account and password.
- Repeat for the remaining services in the start order listed in the Start and stop order table.
To start and stop the services on Windows or UNIX using the command prompt
- Open a command prompt.
- Perform the required operation listed in the following table using the corresponding long or short command option.
To do this… | Use long option | Use short option* |
|---|---|---|
Start the service. | --start | -s |
Stop (kill) the service. | --stop | -k |
Run the program as a console application. | --console | -c |
Debug the service configuration startup. | --debug | -d |
Specify the service's configuration file. | --conf filename | -f filename |
Print the product version and exit. | --version | -v |
Install the program as a Windows service, with an automatic startup (Windows only). | --install | -i |
Remove the program from the Windows Service Manager (Windows only). | --remove | -r |
Print this option list. | --help | -h |
Display transient checkpoint data and exit. | --transient | -t |
Specify the service to be debug build only, used with third party tools that change process name (for internal use only). | --progname serviceName | -p |
*The short options are not valid with the MVMM Client Gateway Service. | ||
Verify your MVMA integration
By default, two minutes after starting the MVMM services, a Monitor Edition or newly-installed licensed edition of MVMA will be configured if it hasn’t already been done so. During the configuration process, MVMA is restarted and MVMM will wait up to five minutes for MVMA to restart. BMC recommends that you wait about ten minutes before attempting to log in to MVMA for the first time.
This section includes:
- Verifying in the qpas-webmc.log file
- Verifying using the mqtool CLI
- Logging into for the first time
- How to re-configure after configuration issues
Verifying in the qpas-webmc.log file
After MVMA restarts, or MVMA stops reconnecting if there was a configuration issue, the qpas-webmc.log file contains LM_NOTICE output. Below is an example of the output, where the configuration succeeded:
Verifying using the mqtool CLI
You can also use the mqtool CLI to verify the configuration.
Below is an example of output when the configuration was successful.
Logging into MVMA for the first time
When logging into MVMA for the first time, and when using the MVMA security, you can use any user that is a member of the MVMA Administrators group or that has the “MVMA Integration Configuration” permission. For an initial test, you can use the SA user.
When using Active Directory you can use the MVMA administrative user specified during execution of the Security Configuration Tool.
If you are still unable to log in to MVMA, see the instructions in the following sections.
If you are using MVMM Security
When integrating with MVMA located on another host, network interfaces are used by default to determine a hostname or IP address to configure MVMA, so that it can connect to MVMM .
Search the MVMA log (log/bmm.admin.log) for the string “URL”. For example: URL 'ldaps://testhost.bmc.com:15011'.
Verify the host from the log (for example, testhost.bmc.com) is reachable using ping or another network tool.
If for some reason the hostname or IP address used is not reachable from the MVMA machine, you can specify a hostname or IP address by changing the ldap_hostname keyword of the [App_Service] stanza in services.cfg from localhost to a reachable hostname or IP address. When altering this value, you will have to re-install and re-configure MVMA as outlined in How to re-configure MVMA after configuration issues.
If you are using Active Directory
Verify that when the Security Configuration Tool was used, all the values passed validation. If not, re-execute the Security Configuration Tool and correct those values. Otherwise, execute the ADCheck CLI to see if it reports any possible configuration errors that can be corrected. If any configuration values were altered, reconfigure the MVMA integration by executing the following command from the MVMM installation directory:
If the old value still seems to be in use, you may need to re-install MVMA and reconfigure, as outlined in How to re-configure MVMA after configuration issues.
Contacting BMC Support
If are still unable to log into MVMA, the following is required when contacting BMC Support.
- Output from executing the mqtool CLI and ADCheck CLI to obtain the current configuration state.
- Execute from the MVMM installation directory: mqool -v --check-config -p BMCSOFTWARE SA
- Execute from the MVMM installation directory if using Active Directory, ADCheck.
- MVMM do_support
- MVMAlogs
How to re-configure MVMA after configuration issues
- Stop MVMA
- Uninstall MVMA
- Re-install MVMA
- Start MVMA
- Execute from the MVMM installation directory: mqtool --reconfigure -p BMCSOFTWARE SA
If for some reason you are unable to re-install MVMA you will need to contact BMC Support to assist you in altering the values in the MVMA database.
Secure communication among product componentsThis section describes the post-installation security setup when necessary.
- Securing HTTPS in the Application Service
- Certificates for securing TLS communications
- Report Access in Secure Mode (HTTPS)
Securing HTTPS in the MVMM Application Service
You can securely access the MVMM product launch page, distribute agents, or view and download reports by using HTTPS (configured, by default, on network port 15004). You must have an X.509 TLS Certificate available to use HTTPS.
If you have not installed an X.509 TLS Certificate post-install, the MVMM Application Service generates a self-signed X.509 TLS Certificate. This certificate and its private key are held in the java keystore file in the following location: InstallDir/jetty/webapps/localhost.jks.
That certificate is presented to your web browser whenever you visit a secured web page on the MVMM Application Service so that you can be certain that you are communicating only with the MVMM Application Service, and that any information sent or received remains confidential.
Most web browsers do not accept a self-signed certificate by default. Some browsers might let you import or temporarily accept a self-signed X.509 certificate.
Make sure you verify the following before accepting a self-signed certificate:
- Review the browser dialog boxes.
- Make sure you are exporting the exact certificate you require.
- Use trusted, secure, and distributed information to verify a self-signed certificate.
If your local security policies do not permit self-signed certificates, you must install a certificate signed by a trusted Certificate Authority.
To install a Certificate Authority (CA) Signed Certificate
MVMM requires a certificate and key to be provided in a Java keystore (a .jks file). You must acquire or prepare the Java keystore according to your certificate handling processes.
- Open services.cfg in a text editor and locate the lines:
jetty_keystore=jetty/webapps/localhost.jks
jetty_keystore_password=OBF:1fuk1kl61f9d1mrf1ldm1gu71ldw1mrn1f991klg1fuq
jetty_keystore_keypassword=OBF:1fuk1kl61f9d1mrf1ldm1gu71ldw1mrn1f991klg1fuq To generate OBF encoded passwords for both the keystore and key passwords, run the obfpassword program from the installation directory:
CD InstallDir
obfpassword.bat passwordIn the above example, password is the keystore or key password.
Copy and paste the OBF generated passwords into the jetty_keystore_password and jetty_keystore_keypassword lines in services.cfg. Do not use the MD5 string.
- Replace jetty/webapps/localhost.jks with the path to your certificate and localhost.jks is the name of the new or existing keystore file.
- Recycle the services to enable the changes made after editing services.cfg.
To verify that the expected certificates are being used by the MVMM Application Service, enter https://hostname:15004 in the address bar of the browser.
The hostname is the IP address or host name of the computer running the MVMM Application Service.
Certificates for securing TLS communications
The MVMM services use X.509 certificates to secure TLS communications in several scenarios. The following table summarizes the certificates:
Use | Configuration Section | Certificates | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
HTTPS |
| |||||||||||||||||
LDAPS |
| |||||||||||||||||
Agent Tunnel |
|
Report Access in Secure Mode (HTTPS)
The same SSL certificate that is used to identify the Application Service is used to secure access to reports accessed either through the Management Console, via a browser, or from the command line (if using HTTPS in the report URL – which is the default option).
The SSL certificate is verified by the underlying HTTP client. The HTTP client making the request can attempt to verify the SSL certificate (i.e. verify that the certificate was issued by an already trusted Certificate Authority). If the identity cannot be verified by the HTTP client (usually accessing pre-configured trust stores, such as Java keystores), the report might not render.
Some HTTP clients (e.g. web browsers, the Management Console) can give the user the option to verify the certificate themselves. That verification lasts for the current viewing session. Additionally, some HTTP clients (depending on local security policies) allow the user to import the certificate into a local trust store. That verification persists over future viewing sessions.
Users must consider that local security policies can override default behavior as described above (e.g. a site-wide policy might block users from importing any certificates into their browser).
To understand how to configure the certificates in the Application Service, refer to Services Configuration Examples.
Tunneling Agent connections
This section includes:
- Overview
- Connection initiation direction
- Service initiated tunnels for Tunneling Agent connections
- Multiple Agents on a host
- Agent keys and certificates
Overview
Connections between the MVMM Agent tier and the MVMM Services tier can, optionally, be routed via a secure tunnel. In this mode all network traffic between the MVMM Agent host and the MVMM Services host is tunneled via a single TCP/IP connection, and the traffic is encrypted using TLS.
This both protects the data from eavesdropping and simplifies the network management, since the only port requirements are for the TLS tunnel itself.
When a MVMM Agent is deployed from a bootstrap configuration it is configured to work against the MVMM Services from which it was deployed. If tunneling is configured in the Services, the Agent is deployed with the appropriate configuration options already set.
An exception to this is for end-user provided keys and certificates where client authentication is required. In this case, the agent must be configured with its keys and certificates after deployment.
Similarly to configuring the MVMM Services for end-user provided keys and certificates (see the Services Configuration Examples), the Java Keytool can be used to populate the key stores for the agent.
Configuration options should then be set in the agents configuration file (located in bmmtm_agent/configuration/services/tunnel.properties). Those properties are documented in the following table.
Many of the defaults for values are derived from those set in the services configuration (services.cfg). Those parameters are described in Defining-configuration-options-in-services-cfg.
MVMM Agents distributed as part of a bootstrap package have these properties set at the point of distribution.
Property name | Description |
|---|---|
tunnel.to.address | Default: [Topic_Service].agent_ts_host |
tunnel.to.port | Default: [Tunnel_Service].tunnel_port |
tunnel.bind.address | Default: 0.0.0.0 |
tunnel.service.proxy.ms.local | Default : [App_Service].web_secure_port |
tunnel.service.proxy.ms.remote | Default : [App_Service].web_secure_port |
tunnel.service.proxy.ts.local | Default: [Topic_Service].listen_port |
tunnel.service.proxy.ts.remote | Default : [Topic_Service].listen_port |
tunnel.client.proxy.qpea.local | Default: 2612 |
tunnel.client.proxy.qpcfg.local | Default: 6002 |
ssl.truststore.file | Default: bmtmAgentTrustStore.jks |
ssl.truststore.password | Default : changeit |
ssl.truststore.type | Default: jks |
ssl.trustmanager.algorithm | Default: PKIX |
ssl.keystore.file | Default: bmtmAgentKeyStore.jks |
ssl.keystore.password | Default : changeit |
ssl.keystore.type | Default: jks |
ssl.keymanager.algorithm | Default: PKIX |
Connection initiation direction
The tunnel connection initiation direction can be configured for each agent via the ConnectionInitiation preference, using the agentpref tool. It can also be set to an initial value when a bootstrap package is provisioned.
ConnectionInitiation | Description |
0 | No tunnel |
1 | Agent initiated (TCP connection originates from the Agent tier). |
2 | Service Initiation (TCP connection originates from the Service tier). |
Service initiated tunnels for Tunneling Agent connections
Bootstrap packages that are provisioned with a "ConnectionInitiation" preference of "2" (which is equivalent to selecting the "MVMM Services initiate Secure Tunnel Connection to Agent" option on the Agent Distribution site) must be introduced to the MVMM Services using hosttool. This is required in order that the MVMM Services know that a tunnel must be initiated. See Managing-HostTool-with-the-CLI for further details.
This step is not required if the Agent is deployed in a different connection initiation mode, and then later switches to a Service initiated tunnel mode (since, at that point, the Agent is already known to the Services).
When migrating an Agent to an alternate MVMM Service tier and the Agent is running a Service Initiated tunnel, the Agent must be explicitly removed from the previous MVMM Service tier. To do this, use the Object Repository tab in the Management Console, or hosttool.
Multiple Agents on a host
To support multiple agents using Agent Initiated tunnels, two additional ports must be defined via extension preferences (this is in addition to normal port customization required to support multiple agents – i.e. changes to eaapi.ini, and ServicePort preferences changes for the "WebSphere MQ Monitor" and "WebSphere MQ Configuration" extensions, as appropriate).
Extension name | Preference name | Value |
|---|---|---|
MVMM Tunnel Service | ASProxyPort | Any free, unused port number. |
MVMM Tunnel Service | MSProxyPort | Any free, unused port number. |
So, for example:
% agentpref --port 2712 --set "BMTM Tunnel Service" ASProxyPort 16009
% agentpref --port 2712 --set "BMTM Tunnel Service" MSProxyPort 17009
MVMM Agent keys and certificates
If Agent Authentication is required in the MVMM Services, and internal certificates are being used, then each MVMM Agent must be explicitly authenticated to the MVMM Services after it has been deployed.
For example:
% cd bmtm-agent/bin
% agent –-console
osgi> authClient services.host.name userId password
where services.host.name should be replaced with the hostname of MVMM Services.
Depending on your configuration, you might be prompted to verify the MVMM Services certificate. Inspect the presented certificate carefully, and compare the signatures to ensure that you are authenticating with the expected entity.
If a MVMM Agent needs to trust a different MVMM Service (rather than the one from which it was deployed), it can add the MVMM Services to its trust store as follows:
% cd bmtm-agent/bin
% agent –-console
osgi> trustServer services.host.name
where services.host.name should be replaced with the hostname of MVMM Services.
Depending on your configuration, you might be prompted to verify the MVMM Services certificate. Inspect the presented certificate carefully, and compare the signatures to ensure that you are trusting the expected entity.
A MVMM Agent only trusts one set of MVMM Services at a time. If it is directed to a previously trusted MVMM Service tier it must re-authenticate that server, using the process described above.