Setting up Stat Standalone

Installation : Setting up Stat Standalone

Setting up Stat Standalone

Prerequisite:

For distributed systems, port 5445 needs to be opened in the firewall.

Data Integration

For more information about Data Integration, please refer to “Hardware Monitoring - Data Integration” .

Installation - Separate BI Server

Wildfly

Follow these steps on the BI Server:

1. Open the application server configuration file. <installation directory>/app/wildfly-8.2.0.Final/standalone/configuration/standalone-full.xml, in your preferred text editor.

2. Locate the existing section:

<response-header name="xFrameOptions" header-name="X-Frame-Options" header-value="SAMEORIGIN"/>

3. Change the header-value, to allow frames on the Central Orchestra server:

<response-header name="xFrameOptions" header-name="X-Frame-Options" header-value="ALLOW-FROM http://{orchestra-server}"/>

where {orchestra-server} is the IP-address or domain name of the Central Orchestra server.

4. Restart the BI application server.

JBoss

Follow these steps on the BI Server:

1. Open the application server configuration file, <installation directory>/app/jboss-eap-6.3/standalone/configuration/standalone-full.xml, in your preferred text editor.

2. Locate the existing section:

</valve>

3. Change the header-value to allow frames on the Central Orchestra Server:

</valve>

where {orchestra-server} is the IP-address or domain name of the Central Orchestra Server.

4. Restart the BI application server.

Configuration - Stat on a Separate Server

Configuration of Standalone Stat Server on Wildfly

If stat.war is deployed in a different application server than qSystem.ear, it is necessary to do a number of changes to the JMS configuration in order to get events forwarded from the Central server to the Stat server.

JMS queues and bridges are defined in the configuration file <ORCHESTRA>/app/wildfly-8.2.0.Final/standalone/configuration/standalone-full.xml, which is present in both installations.

1. On the server where Orchestra stat (stat.war) is deployed, create a user. In this example we use username="jms" and password="password", for the lookup of Queues, by running the script add-user, <ORCHESTRA>/app/wildfly-8.2.0.Final/bin/add-user.bat, on Windows, or <ORCHESTRA>/app/wildfly-8.2.0.Final/bin/add-user.sh, on Linux.

When running the script, supply the following input when prompted:

• b (application user)

• username you selected

• password you selected

• password again

• (blank) - simply press enter to indicate that the user should not belong to a particular group

• yes (validate the input settings)

• no (indicate that the user is not going to connect from another AS process, for e.g. EJB remoting)

If you enter a weak/short password, for example password, as in this example, you might get a warning such as “JBAS015264: Password is not strong enough, it is 'MODERATE'. It should be at least 'MEDIUM'. Are you sure you want to use the password entered yes/no?” or “JBAS015269: Password must have at least 4 characters! Are you sure you want to use the password entered yes/no?”. If this is the case, enter “no” and the script will prompt you for user/password again, or enter “yes” to use the password anyway.

Example execution:

What type of user do you wish to add?

a) Management User (mgmt-users.properties)

b) Application User (application-users.properties)

(a): b

Enter the details of the new user to add.

Using realm 'ApplicationRealm' as discovered from the existing property files.

Username : jms

Password recommendations are listed below. To modify these restrictions edit the add-user.properties configuration file.

- The password should not be one of the following restricted values {root, admin, administrator}

- The password should contain at least 4 characters, 1 alphabetic character(s)

- The password should be different from the username

Password :

Re-enter Password :

What groups do you want this user to belong to? (Please enter a comma separated list, or leave blank for none)[ ]:

About to add user 'jms' for realm 'ApplicationRealm'

Is this correct yes/no? yes

Added user 'jms' to file 'C:\qmatic\orchestra\61evtpsql\app\wildfly-8.2.0.Final\standalone\configuration\application-users.properties'

Added user 'jms' to file 'C:\qmatic\orchestra\61evtpsql\app\wildfly-8.2.0.Final\domain\configuration\application-users.properties'

Added user 'jms' with groups to file 'C:\qmatic\orchestra\61evtpsql\app\wildfly-8.2.0.Final\standalone\configuration\application-roles.properties'

Added user 'jms' with groups to file 'C:\qmatic\orchestra\61evtpsql\app\wildfly-8.2.0.Final\domain\configuration\application-roles.properties'

Is this new user going to be used for one AS process to connect to another AS process?

e.g. for a slave host controller connecting to the master or for a Remoting connection for server to server EJB calls.

yes/no? no

2. On the server where Orchestra Central (qSystem.ear) is deployed, open the file <ORCHESTRA>/app/wildfly-8.2.0.Final/standalone/configuration/standalone-full.xml and locate the section:

<jms-bridge name="centralAgentEventBridge">

<connection-factory name="ConnectionFactory"/>

</source>

<connection-factory name="ConnectionFactory"/>

</target>

<quality-of-service>AT_MOST_ONCE</quality-of-service>

<failure-retry-interval>10000</failure-retry-interval>

<max-retries>-1</max-retries>

<max-batch-size>10</max-batch-size>

<max-batch-time>100</max-batch-time>

</jms-bridge>

<jms-bridge name="centralJourneyEventBridge">

<connection-factory name="ConnectionFactory"/>

</source>

<connection-factory name="ConnectionFactory"/>

</target>

<quality-of-service>AT_MOST_ONCE</quality-of-service>

<failure-retry-interval>10000</failure-retry-interval>

<max-retries>-1</max-retries>

<max-batch-size>10</max-batch-size>

<max-batch-time>100</max-batch-time>

</jms-bridge>

3. Replace the <target> sections with the following:

There are two instances of the <target> section. However, please note that the destination name parameter is not identical in them!

<connection-factory name="jms/RemoteConnectionFactory"/>

</target>

...

<connection-factory name="jms/RemoteConnectionFactory"/>

</target>

4. Then, add a <context> section with the content below to each <target> section. The java.naming.provider.url should contain the IP-address of the application server where stat.war is deployed. The value for the key “java.naming.security.principal” should be the user name you added in step 1 and the value for the key “java.naming.security.credentials” should be the password you added for that user:

There are two instances of the <target> section! One for the destination “queue/statAgentEventQueue” and one for the destination “queue/statCentralJourneyEventQueue”, the context section below should be added to both.

</context>

The result will be something like this (you will of course have another value for the key java.naming.provider.url in both context sections):

<jms-bridge name="centralAgentEventBridge">

<connection-factory name="ConnectionFactory"/>

</source>

<connection-factory name="jms/RemoteConnectionFactory"/>

</context>

</target>

<quality-of-service>AT_MOST_ONCE</quality-of-service>

<failure-retry-interval>10000</failure-retry-interval>

<max-retries>-1</max-retries>

<max-batch-size>10</max-batch-size>

<max-batch-time>100</max-batch-time>

</jms-bridge>

<jms-bridge name="centralJourneyEventBridge">

<connection-factory name="ConnectionFactory"/>

</source>

<connection-factory name="jms/RemoteConnectionFactory"/>

</context>

</target>

<quality-of-service>AT_MOST_ONCE</quality-of-service>

<failure-retry-interval>10000</failure-retry-interval>

<max-retries>-1</max-retries>

<max-batch-size>10</max-batch-size>

<max-batch-time>100</max-batch-time>

</jms-bridge>

5. Restart the Central server.

If Central has trouble connecting to the remote stat server, make sure that firewall rules allow connections to port 8080.

If Orchestra Central still experiences JMS connection errors, such as:

WARN [org.hornetq.jms.server] (pool-3-thread-3) HQ122010: Failed to connect JMS Bridge: javax.naming.CommunicationException: Failed to connect to any server. Servers tried: [http-remoting://192.168.1.2:8080 (Operation failed with status WAITING after 5000 MILLISECONDS)] [Root exception is java.net.ConnectException: Operation failed with status WAITING after 5000 MILLISECONDS]

Or the following error in the stat server’s Wildfly server.log:

INFO [org.jboss.as.naming] (default task-16) JBAS011806: Channel end notification received, closing channel Channel ID 1362678f (inbound) of Remoting connection 02b0b61f to /192.168.1.2:55380

This combination of messages means that the remote stat Wildfly installation has trouble making an internal JMS connection which it may be trying to perform against address 0.0.0.0 by default, which must be changed. It is changed by editing the remote stat’s Orchestra run.bat / run.sh script, which resides in the <remote stat install dir>/bin folder.

For Linux installations, change the last line to this (change IP as needed):

"$QP_HOME"/app/wildfly-8.2.0.Final/bin/standalone.sh -b=192.168.1.2 --server-config=standalone-full.xml

For Windows installations, change the following line:

CALL standalone.bat --server-config=standalone-full.xml

to this:

CALL standalone.bat -b=192.168.1.2 --server-config=standalone-full.xml

Configuration of Standalone Stat Server on JBoss

Follow these steps:

1. Open the file <ORCHESTRA>/app/jboss-eap-6.3-8.2.0.Final/standalone/configuration/standalone-full.xml on the Central server.

2. Locate the section socket-binding-group entry remote-jms and change the remote-destination host from "localhost" to the address of the stat server:

<socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}">

<socket-binding name="management-native" interface="management" port="${jboss.management.native.port:9999}"/>

<socket-binding name="management-http" interface="management" port="${jboss.management.http.port:9990}"/>

<socket-binding name="management-https" interface="management" port="${jboss.management.https.port:9443}"/>

<socket-binding name="ajp" port="8009"/>

<socket-binding name="http" port="8080"/>

<socket-binding name="https" port="8443"/>

<socket-binding name="jacorb" interface="unsecure" port="3528"/>

<socket-binding name="jacorb-ssl" interface="unsecure" port="3529"/>

<socket-binding name="messaging" port="5445"/>

<socket-binding name="messaging-group" port="0" multicast-address="${jboss.messaging.group.address:231.7.7.7}" multicast-port="${jboss.messaging.group.port:9876}"/>

<socket-binding name="messaging-throughput" port="5455"/>

<socket-binding name="remoting" port="4447"/>

<socket-binding name="txn-recovery-environment" port="4712"/>

<socket-binding name="txn-status-manager" port="4713"/>

<outbound-socket-binding name="mail-smtp">

<remote-destination host="localhost" port="25"/>

</outbound-socket-binding>

<outbound-socket-binding name="remote-jms">

<remote-destination host="statServerHost" port="5445"/>

</outbound-socket-binding>

</socket-binding-group>

3. Then, modify the jms-bridges centralAgentEventBridge and centralJourneyEventBridge target to use the connection-factory "QPStatEventConnectionFactory" instead of "ConnectionFactory":

<jms-bridge name="centralAgentEventBridge">

<connection-factory name="ConnectionFactory"/>

</source>

<connection-factory name="QPStatEventConnectionFactory"/>

</target>

<quality-of-service>AT_MOST_ONCE</quality-of-service>

<failure-retry-interval>10000</failure-retry-interval>

<max-retries>-1</max-retries>

<max-batch-size>10</max-batch-size>

<max-batch-time>100</max-batch-time>

</jms-bridge>

<jms-bridge name="centralJourneyEventBridge">

<connection-factory name="ConnectionFactory"/>

</source>

<connection-factory name="QPStatEventConnectionFactory"/>

</target>

<quality-of-service>AT_MOST_ONCE</quality-of-service>

<failure-retry-interval>10000</failure-retry-interval>

<max-retries>-1</max-retries>

<max-batch-size>10</max-batch-size>

<max-batch-time>100</max-batch-time>

</jms-bridge>

4. Restart the Central server