Installation : Prerequisites - Checklist
  

Prerequisites - Checklist

The following table can be seen as a checklist for the prerequisites that need to be considered before going ahead with the installation.
We recommend printing it, so that each prerequisite can be carefully checked before going ahead. Some of the prerequisites may not be applicable for you. If that’s the case, simply mark them as N/A and move on!
 
Prerequisite
Check
N/A
The hardware and software that is used are of versions supported by the software to be installed. For information about supported versions of Operating Systems, Browsers, Databases, Java and hardware requirements, please refer to the Orchestra Data Sheet, found on Qmatic World.
 
 
All necessary hardware is installed with a supported version of the OS and database (if needed).
 
 
All cabling is in place.
 
 
The software to be installed is available.
 
 
A network of suitable capacity must be in place. For more information, see “Distributed Operations” .
 
 
Decide which installation scenario suits your organization best. For more information, see “Installation Scenarios” .
 
 
If you will be using Concierge and/or Connect, see “App Download, Installation and Upgrade” .
 
 
If you are using CentOS, please read through “Installation Note - CentOS” before starting.
 
 
If you will be using Windows Authentication, please read through “Installation Note - Windows Authentication” , before starting.
 
 
If you, for some reason, after having installed a complete system, need to redirect Stat to a separate server, please follow the instructions in “Installation Note - Configuration of stat on a separate server” .
 
 
If you will be installing Orchestra Business Intelligence, see“Introduction” .
 
 
If Oracle or Microsoft SQL Server is used as database, database must be up and running.
For more information about Oracle parameters, that might need tuning, please read “Tuning of Oracle Parameters” and for PostgreSQL parameters that might need tuning, please read “Tuning of PostgreSQL Parameters” .
 
 
If you are to install a distributed setup and will be using Stat, you must open up port 5445 in your firewall.
 
 
If you are using Microsoft SQL Server, the following settings must be applied to the installation:
the TCP/IP protocol (and port number)
SQL Server and Windows Authentication mode must be enabled.
 
 
If you will be using named instances, you need to run the installation in silent mode, using the command install.bat -s for Windows, or install.sh -s for Linux.
 
 
 

Supported Platforms

For information about supported platforms, databases etc, please see the Orchestra Data Sheet, found on Qmatic World.

App Download, Installation and Upgrade

If you are going to use the Connect and/or Concierge applications, you will need to download and install (and later upgrade) the native app(s) from either Apple App Store©, or Google Play.
To easily find the applications, we recommend that you search for “Connect Agent” /“Concierge Agent” or “Qmatic”.

Installation Note - CentOS

Before running the Orchestra installer on CentOS there are a few steps you need to go through:
1. Settings for “max user processes” and setting for “max open files”.
We recommend increasing the setting of “max user processes” to 2048 and increasing “max open files” by 30000.
If running other processes on the Orchestra server, these settings might have to be increased further.
Current max user processes limit can be verified by running:
ulimit -u
 
Current max open files limit can be verified by running:
ulimit -n
 
We suggest increasing this by adding the following lines to the end of the file
/etc/security/limits.conf.
In this example “qmatic” is the username of the user that will run the installer and the user that Orchestra will run as.
After modifying this file, the system will require a reboot. Verify the settings again after reboot.
# Limits for orchestra installer
qmatic hard nofile 30000
qmatic soft nofile 30000
qmatic hard nproc 8192
qmatic soft nproc 8192
 
2. Make sure host name is resolvable.
Orchestra installer requires that host name of the machine is resolvable. You can check host name in the file /etc/sysconfig/network.
You can verify that it is possible to resolve this by running:
ping HOSTNAME
 
If you get a response “ping: unknown host HOSTNAME” you will have to add the HOSTNAME to the file /etc/hosts.
Add the following line to the end of the hosts file:
127.0.0.1    HOSTNAME
 
3. If you are installing on a CentOs server without a GUI, you most likely need to install additional fonts that is used by the surface editor, when creating ticket layouts.
4. When running the installation using the embedded PostgreSQL database, a default Linux system sometimes has too low memory settings. The PostgreSQL process requires larger settings for shared memory, compared to the usual default of 32 MB.
Kernel semaphores need to be set according to the following command
kernel.sem = SEMMSL SEMMNS SEMOPM SEMMNI
SEMMMSL = 512
SEMOPM = 256
SEMMNI = 256
The SEMMNS is calculated from SEMMSL and SMMNI according to the following calculation
SEMMNS = SEMMSL * SMMNI = 512 * 256 = 131072
5. To make the change permanent, add or change the following line in the file /etc/sysctl.conf:
echo ‘kernel.sem=512 131072 256 256’>>/etc/sysctl.conf
 
Reboot the server for the changes to take effect.

Installation Note - TLS Security Settings

Mitigation of Denial-of-service attack

During installation of Orchestra, TLS Security settings are automatically enabled, by setting the following parameter to true:
-Djdk.tls.rejectClientInitiatedRenegotiation
If you, for some reason, want to disable this security setting, this is done by setting the above parameter to false in the file <Orchestra install dir>\app\wildfly-11.0.0.Final\bin\standalone.conf. Then restart the application server.

Mitigation of LOGJAM Man-in-the-Middle attack

During installation of Orchestra, the Diffie-Hellman key-size is automatically increased from the default 1024 to 2048.
If you want to enhance your security, you need to un-comment the parameters ephemeralDHKeySize and DHEParameters in the file <Orchestra install dir>\app\wildfly-11.0.0.Final\bin\standalone.conf. Then, restart the application server.

Installation Note - Windows Authentication

If using SQL Server, it is possible to install Orchestra and Business Intelligence with Windows Authentication.
Follow the steps below:
1. Grant Windows User Logon as service access:
a) Log on to the computer with administrative privileges.
b) Open the desktop app Local Security Policy.
c) In the left menu, expand Local Policies and click on User Rights Assignment.
d) In the right pane, right-click Log on as a service and select Properties.
e) Click Add User or Group button to add a new User.
f) In the Select Users, Computers, Service Accounts, or Groups window, find the wanted User, then click OK.
g) Click OK in the Log on as Service Properties window to save the changes.
2. Create databases:
a) Open a connection to the database with the SA account.
b) Open and execute the scripts central-mssql-integrated.sql and stat-mssql-integrated.sql, located in the db folder of the installation zip/tgz package.
c) Open the script access-mssql-integrated.sql, located in the db folder of the installation zip/tgz package, and replace the ‘DOMAIN\USERNAME’ with the actual domain name and username.
d) Save and run the access-mssql-integrated.sql script.
e) If you are also installing BI using Windows authentication, repeat step 2 a-d, but replace scripts accordingly
b) bi-jr-mssql.sql, bi-quartz-mssql.sql, bi-repository-mssql.sql
c) open and edit bi-mssql-win-auth.sql
d) run bi-mssql-win-auth.sql
3. Install with wizard - for more information, see “Orchestra Installation Wizard - installing both Orchestra and Stat” / “Orchestra Installation Wizard - Orchestra and Stat on Separate Servers” / “Business Intelligence Installation Wizard” .
4. Install with silent installer:
a) Open the install.properties file, in the installation package (zip/tgz file).
b) Locate the property integrated.security.username and enter the domain and Windows username.
integrated.security.username = domain\\db-user
c) Locate the property mssql.integrated.security and set it to true.
mssql.integrated.security = true
d) Make any other wanted updates to the install.properties file (for example selecting wanted applications) and save the file.
e) Run the installer in silent mode, using the command install.bat -s for Windows, or install.sh -s for Linux.

Installation Note - SQL Server with named instances

If using MS SQL Server with named instances:
1. Open install.properties file.
2. For each application db properties.
a) Set db host name for the different applications on the format host-name\\instance-name. Example:
agent.sqlserver.db.host = sqlserver.acme.com\\DBINSTANCE
b) Leave port property empty for each application db on SQL Server. Example:
agent.mssql.db.port =
3. Make any other wanted updates to the install.properties file (for example selecting wanted applications) and save the file.
4. Run the installer in silent mode, using the command install.bat -s for Windows, or install.sh -s for Linux.

Installation Note - Configuration of stat on a separate server

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-11.0.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-11.0.0.Final/bin/add-user.bat, on Windows, or <ORCHESTRA>/app/wildfly-11.0.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-11.0.0.Final\standalone\configuration\application-users.properties'
Added user 'jms' to file 'C:\qmatic\orchestra\61evtpsql\app\wildfly-11.0.0.Final\domain\configuration\application-users.properties'
Added user 'jms' with groups to file 'C:\qmatic\orchestra\61evtpsql\app\wildfly-11.0.0.Final\standalone\configuration\application-roles.properties'
Added user 'jms' with groups to file 'C:\qmatic\orchestra\61evtpsql\app\wildfly-11.0.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-11.0.0.Final/standalone/configuration/standalone-full.xml and locate the section:
 
<jms-bridge name="centralAgentEventBridge" quality-of-service="AT_MOST_ONCE" failure-retry-interval="10000" max-retries="-1" max-batch-size="10" max-batch-time="100">
<source connection-factory="ConnectionFactory" destination="queue/centralAgentEventQueue"/>
<target connection-factory="ConnectionFactory" destination="queue/statAgentEventQueue"/>
</jms-bridge>
<jms-bridge name="centralJourneyEventBridge" quality-of-service="AT_MOST_ONCE" failure-retry-interval="10000" max-retries="-1" max-batch-size="10" max-batch-time="100">
<source connection-factory="ConnectionFactory" destination="queue/centralJourneyEventQueue"/>
<target connection-factory="ConnectionFactory" destination="queue/statCentralJourneyEventQueue"/>
</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!
<target>
<connection-factory name="jms/RemoteConnectionFactory"/>
<destination name="queue/statAgentEventQueue"/>
</target>
 
...
 
<target>
<connection-factory name="jms/RemoteConnectionFactory"/>
<destination name="queue/statCentralJourneyEventQueue"/>
</target>
 
4. Then, add a <target-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 <target-context> section below should be added to both.
<target-context>
<property name="java.naming.factory.initial" value="org.jboss.naming.remote.client.InitialContextFactory"/>
<property name="java.naming.provider.url" value="http-remoting://192.168.1.1:8080"/>
<property name="java.naming.security.principal" value="jms"/>
<property name="java.naming.security.credentials" value="password"/>
</target-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" quality-of-service="AT_MOST_ONCE" failure-retry-interval="10000" max-retries="-1" max-batch-size="10" max-batch-time="100">
<source connection-factory="ConnectionFactory" destination="queue/centralAgentEventQueue"/>
<target connection-factory="jms/RemoteConnectionFactory" destination="queue/statAgentEventQueue">
<target-context>
<property name="java.naming.factory.initial" value="org.jboss.naming.remote.client.InitialContextFactory"/>
<property name="java.naming.provider.url" value="http-remoting://192.168.1.1:8080"/>
<property name="java.naming.security.principal" value="jms"/>
<property name="java.naming.security.credentials" value="password"/>
</target-context>
</target>
</jms-bridge>
<jms-bridge name="centralJourneyEventBridge" quality-of-service="AT_MOST_ONCE" failure-retry-interval="10000" max-retries="-1" max-batch-size="10" max-batch-time="100">
<source connection-factory="ConnectionFactory" destination="queue/centralJourneyEventQueue"/>
<target connection-factory="jms/RemoteConnectionFactory" destination="queue/statCentralJourneyEventQueue">
<target-context>
<property name="java.naming.factory.initial" value="org.jboss.naming.remote.client.InitialContextFactory"/>
<property name="java.naming.provider.url" value="http-remoting://192.168.1.1:8080"/>
<property name="java.naming.security.principal" value="jms"/>
<property name="java.naming.security.credentials" value="password"/>
</target-context>
</target>
</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.1: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.1: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-11.0.0.Final/bin/standalone.sh -b=192.168.1.1 --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.1 --server-config=standalone-full.xml