Developers

Kx Platform Deployment Guide
Kx Platform
Deployment Guide 4.2 (v5)
1
About Kx
Kx was founded in 1993 by Arthur Whitney and Janet Lustgarten to address a
simple problem: the inability of traditional relational database technology to
keep up with escalating volumes of data. This problem is even more acute
today, as data records already number in the trillions and are escalating
exponentially. Businesses however, need immediate access to real-time and
historical data for a whole range of applications. From research through
trading, smart meter data analysis, web site analytics, customer behaviours
and a plethora of other applications, all need a high-velocity analytics
platform.
Since the company’s inception, Kx’s singular goal has been to provide its
customers with the fastest, most efficient, and most flexible tools for
processing real-time and historical data. This focus has enabled us to
become the worldwide leader in high-volume, high-performance databases.
Contact
North American Office (NY): +1 (212) 447 6700
European Office (UK): +44 28 3025 2242
Sales Email: info@firstderivatives.com
2
Documentation
All rights reserved. No part of this document may be reproduced, stored in a
retrieval system or transmitted in any form or by any means, without the prior
written permission of First Derivatives plc, except in the case of brief
quotations embodied in critical articles or reviews.
Kx has made every effort in the preparation of this document to ensure the
accuracy of the information. However, the information contained in this
document is provided without warranty, either express or implied. Kx will not
be held liable for any damages caused or alleged to be caused either
directly or indirectly by this document.
About this document

This Document describes the steps required to deploy the Kx Platform via a
Release Bundle
3
Contents
About Kx ................................................................................................................................... 2
Contact ................................................................................................................................. 2
Documentation ....................................................................................................................... 3
About this document .......................................................................................................... 3
Contents ................................................................................................................................... 4
Introduction .............................................................................................................................. 6
Installation Pre-requisites ......................................................................................................... 7
Downloading the Release Bundle ...................................................................................... 11
Deploying the Release ......................................................................................................... 12
Transferring Release to Deployment Host....................................................................... 12
Running the Installer .......................................................................................................... 13
Interacting with the Deploy ................................................................................................. 17
Deployment Footprint ....................................................................................................... 17
Install Location ................................................................................................................ 17
Log Files............................................................................................................................ 17
Data Location................................................................................................................. 18
Scripts ............................................................................................................................... 19
Control Web UI ................................................................................................................... 20
Dashboards for Kx .............................................................................................................. 23
Analyst ................................................................................................................................. 24
Restarting Single Host Deploy .............................................................................................. 26
Upgrading a Deploy ............................................................................................................. 29
Updating Licenses ................................................................................................................. 33
Appendix A – install.sh additional options ......................................................................... 35
Appendix B – Deployment Configurations ........................................................................ 36
1. Multi Host Control and Web clustered deploy ....................................................... 38
Control Master/Slave Deploy ....................................................................................... 39
............................................................................................................................................. 39
Web Cluster Deploy ....................................................................................................... 43
Completing the deploy ................................................................................................. 44
4
2. Non-clustered Control with separate Web Host .................................................... 47

.......................................................................................................................................... 47
Control deploy................................................................................................................ 47
Web Server Deploy ............................................................................................................ 50
3. Control and Web cluster deploy .............................................................................. 53
Restarting Multi-Host Deploy ............................................................................................ 56
Shutdown ........................................................................................................................ 56
Start-up ............................................................................................................................ 57
Appendix C – Default Process Workflows .......................................................................... 59
Appendix D – TLS Configuration .......................................................................................... 60
Enabling TLS at Deploy Time ............................................................................................. 60
Enabling TLS Post Deploy .................................................................................................. 63
Appendix E – Tomcat SSL Installation.................................................................................. 65
Appendix F – App Server Memory Allocation ................................................................... 67
Appendix G – Enabling SSO Deployment .......................................................................... 68
Appendix H – CPU Affinity .................................................................................................... 71
Appendix I – Control Package Import................................................................................ 72
Auto Package Import .................................................................................................... 72
Import Environment Variables ...................................................................................... 74
Package Configuration................................................................................................. 75
Appendix J – Platform Support Scripts ................................................................................ 76
Reporting Issues .................................................................................................................. 78
Appendix K – Process Instance Configuration .................................................................. 79
Appendix L – Install Script Command Line Options .......................................................... 81
Appendix M – Install Configuration File Options ............................................................... 82
5
Introduction
This Deployment Guide will describe the steps required to install the Platform Kx
Bundle. This bundle contains the software components which make up the core
platform and include the Dashboard Visualization layer (an example of which is
given below).
6
Installation Pre-requisites
To install the KxPlatform bundle you will need the following:
Software/Licensing
For all Software and Licensing requests please contact support@firstderivatives.com
 Nexus User Account

 KDB+ Software License (k4.lic)
 Delta Software License (.delta.lic)
Desktop
 SCP Client (WinSCP)

 SSH Client (PuTTY)
 Google Chrome Browser
Server
 Target Deploy Server running:

o Red Hat Enterprise Linux (RHEL) / Centos 6.5+
o Red Hat Enterprise Linux (RHEL) / Centos 7.0+
 CPU : Minimum 4 Core+ Intel® Xeon® processor
 RAM : Minimum 8GB+ DDR4 Memory
 Storage: 1TB+ per node
Required Libraries - Analyst
RPM (RHEL / Centos 6.5+) RPM (RHEL / Centos 7.0+) Library

fontconfig-2.8.0-5.el6.x86_64 fontconfig-2.10.95-7.el7.x86_64 libfontconfig.so.1
freetype-2.3.11-17.el6.x86_64 freetype-2.4.11-11.el7.x86_64 libfreetype.so.6
glibc-2.12-1.132.el6_5.4.x86_64 glibc-2.17-106.el7_2.4.x86_64 libpthread.so.0
libc.so.6
libdl.so.2
libm.so.6
libstdc++-4.4.7-18.el6.x86_64 libstdc++-4.8.5-4.el7.x86_64 libstdc++.so.6
libgcc-4.4.7-18.el6.x86_64 libgcc-4.8.5-4.el7.x86_64 libgcc_s.so.1
libpng-1.2.49-2.el6_7.x86_64 N/A libpng12.so.0
N/A libpng-1.5.13-7.el7_2.x86_64 libpng15.so.15
7
Required Linux Binaries
RPM (RHEL / Centos 6.5+) RPM (RHEL / Centos 7.0+) Binary

bash-4.1.2-29.el6.x86_64 bash-4.2.46-19.el7.x86_64 bash
bzip2-1.0.5-7.el6_0.x86_64 bzip2-1.0.6-13.el7.x86_64 bzip2
coreutils-8.4-37.el6.x86_64 coreutils-8.22-15.el7_2.1.x86_64 basename
cat
cp
date
echo
head
id
mkdir
mv
printf
readlink
rm
rmdir
sort
tail
touch
tr
uname
gawk-3.1.7-10.el6.x86_64 gawk-4.0.2-4.el7.x86_64 awk

glibc-2.12-1.132.el6_5.4.x86_64 glibc-2.17-106.el7_2.4.x86_64 ldconfig
grep-2.6.3-6.el6.x86_64 grep-2.20-2.el7.x86_64 grep
gzip-1.3.12-22.el6.x86_64 gzip-1.5-8.el7.x86_64 gunzip
gzip
net-tools-1.60-110.el6_2.x86_64 hostname-3.13-3.el7.x86_64 domainname

hostname
net-tools-1.60-110.el6_2.x86_64 net-tools-2.0-0.17.20131004git.el7.x86_64 ifconfig
procps-3.2.8-30.el6.x86_64 procps-ng-3.3.10-5.el7_2.x86_64 ps
rsync-3.0.6-12.el6.x86_64 rsync-3.0.9-17.el7.x86_64 rsync
sed-4.2.1-10.el6.x86_64 sed-4.2.2-5.el7.x86_64 sed
tar-1.23-11.el6.x86_64 tar-1.26-29.el7.x86_64 tar
unzip-6.0-4.el6.x86_64 unzip-6.0-15.el7.x86_64 unzip
util-linux-ng-2.17.2-12.14.el6_5.x86_64 util-linux-2.23.2-26.el7.x86_64 taskset
which-2.19-6.el6.x86_64 which-2.20-7.el7.x86_64 which
Required Third Party Software
 Java Runtime Environment 1.8

 Open SSL 1.0.1+ (This is only required if you wish to use SSL/TLS for Apache
Tomcat or KDB+)
8
Dashboards PDF Viewer
Dashboards for Kx provide the ability to convert a dashboard in a web browser to a

PDF. In order to do this you need to have the following installed on your deploy host.
 Nodejs 8.11.1+
 Google Chrome 65.0.3325.181+
KDB License
KDB licenses are tied to the hostname of a machine and specifically the hostname
in FQDN (<HOSTNAME>.<DOMAINNAME>) format. When run on a machine which is
incorrectly configured you will get a “host” error when running the q binary.
In order for KDB+ to run, the hostname in the license file must be present as an alias
to a network interface in the /etc/hosts file on the box. The network interface aliased
will be used for inter process communication so it must be one which is accessible by
all hosts wishing to connect to the system. The format of the entry in /etc/hosts
should be as follows:
<INTERFACE IP><FQDN><HOSTNAME>
For example if a host with IP address 10.190.1.232 is called kdbdev and is on the
firstderivatives.com domain then the /etc/hosts file should look like this:
10.190.1.232 kdbdev.firstderivatives.com kdbdev
9
Delta License
Control for Kx is licensed via the .delta.lic file. The file contains an encoded
hostname string which is matched to the hostname of the deployed server via the
following checks.
Control for Kx determines the FQDN of the host by parsing the /etc/hosts file and
checking each valid FQDN against the hostname in the license file for a match.
Once a match is found it is checked against the values in the failover.csv (written by
the installer).
The FQDN value written into the failover.csv is determined as follows:
1. Running the hostname command to check if it returns the FQDN

2. Check the aliases of each of the hosts network interfaces for one which is in
the format of a FQDN
Default Ports
The various software components are pre-configured to use a set of default ports.
The ports below are required to be free on the box for each installation.
Port Process Description Access

2001 Control Port for main control process [Desktop] to port 2001 on
platform deploy server
2002 LogStreamer Port for Log Streamer process [Server ]to Server in Control
which allows communication cluster
and synchronization between (where clustering is enable)
Control instances.
8080 Tomcat HTTP Port [Desktop] to port 8080 on
8443 Tomcat HTTPS Port [Desktop] to port 8443 on
(where Apache Tomcat is
deployed with SSL/HTTPS)
10
Downloading the Release Bundle
To download the release bundles navigate to the Nexus Download URL

below
https://nexus.firstderivatives.com/nexus/content/repositories/KxReleases/PlatformKx/latest
NB: You will be prompted to enter your nexus login credentials in order to
access the page.
Once the page has loaded you will see the following:
You will see packages for 3 different OS’s (RHEL65, RHEL70, and MS Windows)
You will need to download the GA.tgz which matches your OS (RHEL6/RHEL7) and
also the latest Patch Version (e.g. P2.tgz) (each patch release contains all previous
patches since the GA).
For Example:
RHEL6 deploy download:
 PlatformKx-4.0.2-RHEL65-GA.tgz
 PlatformKx-4.0.2-RHEL65-P2.tgz
RHEL7 deploy download:
 PlatformKx-4.0.2-RHEL70-GA.tgz
 PlatformKx-4.0.2-RHEL70-P2.tgz
11
Deploying the Release
This section deals with deploying the release, the deployment layout in this example
is a Non Clustered Single Host deploy. For details relating to Multi Sever Clustered
deploys please see Appendix B in this doc.
Transferring Release to Deployment Host
Using your SCP Client scp the downloaded bundle into your target deploy host as
shown in the screenshot below:
Using the SSH Client untar the KxPlatform package using the following command:
tar –xvfPlatformKx-4.0.2-RHEL65.tgz
Once the tarball is unpacked the result will be a directory called:
PlatformKx-4.0.2-RHEL65
12
Using the SCP Client drag the two license files (k4.lic and .delta.lic) into the
root directory of the untarred folder created above
Running the Installer
The Bundle installer (install.sh) wraps the main installation script (installDeltaXML.sh)
by configuring the install through on screen prompts and generates an installation
profile (scripts/install.config.run)which is loaded by installDeltaXML.sh. Once the
bundle has been copied, unpacked and the licenses are in place it’s time to run the
installer as follows:
$ cd EvalKx-4.2.0S1-RHEL65-SNAPSHOT
$ ./install.sh
The script will print to the terminal. The first prompt will be for the location of the
deployment. The default is $USER/kxinstall. If you wish to deploy to a non-default
directory enter it at the prompt otherwise hit enter.
=============================================================
== install.sh [2.1.0] ==
=============================================================
Platform install directory [/home/estuart/kxinstall] :
Before the deploy configuration continues a pre deploy script called checkHost.sh
will be run. The script will collect information about the deploy host. If the host is not
configured correctly or if there are missing dependencies i.e. Java 1.8 is not installed
then the deploy will fail.
13
You can disable the pre deploy check by running install.sh with the -h flag as follows:
+-----------------------------------------------------------+
Running Pre Deploy Script [checkHost.sh]
+-----------------------------------------------------------+
The script will print to the terminal. For Deploy Mode select option 1 (Single Host
Deploy):
+-----------------------------------------------------------+
+-----------------------------------------------------------+
[1] Single
[2] Control
[3] Web Server
[4] Daemon
+-----------------------------------------------------------+
Select Mode [1-4] : 1
The script will prompt you for a free port to be used by the Control process. The
default port is 2001 you can either hit return and accept the default or enter a new
value (see below)
Default Port
Configuring Single Node Deploy:

Please enter free port to be used by Control [2001] :
Using port [2001] for Control
Custom Port
Configuring Single Host Deploy:

Please enter free port to be used by Control [2001] : 2017
If either the Default port or the port you select is currently in use by another process
on the deploy host you will be prompted to enter a new port (see below)
Configuring Single Host Deploy:

Please enter free port to be used by Control [2001] :
Port [2001] in use
In this example, we will be using control port 2017.
CPU Affinity (taskset)
At this point you may be prompted to enter the number of CPU cores you wish to run
KDB+ on. This depends 2 factors, the number of cores on the box (see Max: value
below) and the number of cores your KDB+ License (k4.lic) supports. In the example
below I am installing on a 10 CPU Core host but my license file only covers the use of
10 cores.
14
Number of [Licensed KDB+] [CPU cores] [Max: 10] : 10

You now have two options. 1) HTTP or 2) HTTPS.
OPTION 1 - HTTP
+------------------------------------------------+
[1] HTTP
[2] HTTPS
+------------------------------------------------+
Select App Server Deploy Type [1-2] : 1
+------------------------------------------------+
OPTION 2 - HTTPS
+------------------------------------------------+
[1] HTTP
[2] HTTPS
+------------------------------------------------+
Tomcat Java Keystore [/home/estuart/.keystore] :
Tomcat Java Keystore Password [changeme] : password1
App Server HTTPS port [8443] :
Now you can configure the port by pressing enter to use the default (8080) or by
entering your own port. In this case I used the default 8080 port.
OPTION 1 - HTTP
+------------------------------------------------+
App Server HTTP port [8080] :
+------------------------------------------------+
OPTION 2 – HTTPS
+------------------------------------------------+
+------------------------------------------------+
TLS Encryption
If the bundle release version supports TLS Encryption you will be prompted here to
enable it. TLS configuration is dealt with in Appendix D - TLS Configuration. For this
example we will proceed without encryption:
Encryption
Deploy with TLS/SSL Encryption Enabled [no] :
License Files
The installer will now prompt you for the location of you k4/kc license files for KDB+
and then for the location of your delta license (.delta.lic). In the example below
both files are in a directory called licenses in the user home dir (~/licenses).
Please enter location of a kx license file (k4.lic) [dir] : /home/estuart/licenses
This completes the deploy configuration, the script should now deploy the packages
Running Deploy
Installing [15] Packages
[****************]
Once deployment is complete the bundle installer will bring up the system. On
successful installation you will see the following:
Installation complete.
15
+-----------------------------------------------------------+
Kx Platform Startup
[estuart@web-a.fd.firstderivatives.com]
+-----------------------------------------------------------+
Starting Control .....done
Starting Daemon .....done
Starting App Server .....done
Starting Workflow [DS_STARTALL_FXEVAL] .....done
Starting Workflow [DS_launch_AT_A] .....done
Starting Workflow [DS_launch_html5eval] .....done
+-----------------------------------------------------------+
Delta Control:
[http://control-a.fd.com:8080/control]
Dashboards:
[http://control-a.fd.com:8080/dashboards/quickview]
Analyst:
[http://control-a.fd.com:8080/analyst]
+-----------------------------------------------------------+
Finished.
Post Deploy
Once the deploy has completed the post deploy env script called checkEnv.sh will
be run which will create a TGZ file with details of the deploy. The TGZ can be found
inside the bundle directory and it will be named something like KX-INSTALL-LOGS-
20180117-103731.tgz.
If you deploy with TLS Enabled an additional validation script called validateCerts.sh
will be run. The output from this and the checkEnv.sh script will be printed to the
screen and all log files will be include inside the TGZ above.
If you do not wish to run the post deploy validation as part of your deploy then run
the install.sh with the -n flag as follows:
$ ./install.sh -n
=============================================================
== install.sh [2.1.0] ==
=============================================================
Skip Env Check
16
Interacting with the Deploy

This section will show you how to use the various sections of the deploy using the
information printed by the deploy
Deployment Footprint
The Deployment Footprint comprises of the main directories within the deploy and
include locations of scripts and log files.
Install Location
The default location for a Kx Platform deploy is in a directory called kxinstall inside
the deployment users home dir. i.e.
~/kxinstall
Inside this dir there are 4 main sub directories
Directory Contents
checkpoint Control checkpoints which are point in time snapshots of a

Control installation in the form of a set of XML files.. These
provide rollback functionality.
delta-bin Start scripts, base Packages (KDB+, Control) and 3rd party
packages (Tomcat)
delta-data Process log files and the data associated with the
installation including Control internal tables, Ticker Plant
logs files, Historical Databases etc
packages Delta Solution and Custom Environment packages which
install into Control
Log Files
Control and process log filers can be found at the following location
/home/xxx/kxinstall/delta-data/DeltaControlData/logdir/
Inside here there is several important logs such as the main Control log=
DeltaControl.log and the Daemon log= DeltaControlDaemon.log.
Tomcat log files can be found at the following location
/home/xxx/kxinstall/delta-bin/software/Tomcat_7_0_73/latest/logs
The tomcat log directory contains the log files for all Kx Platform web applications
such as Dashboards and Control UI.
17
Data Location
The delta-data folder contains all the data associated with the platform along with
the process log files. By default the delta-data directory lives at the same level as the
delta-bin directory inside the deploy.
If you wish to specify a different location for the delta-data dir (i.e. in order to put it
on a different disk/partition) then you will need to uncomment the following inside
the bundle install config (scripts/install.config) or add the following to a custom install
config (passed in via -p).
# Custom location for delta-data dir

delta-data-dir=/path/to/delta-data
The delta-data dir location will now be created at the path specified by delta-data-
dir in the install configuration.
18
Scripts
Scripts which are used to start and stop various components within the deploy can
be found at the following location
/home/xxx/kxinstall/delta-bin/bin
A description and usage of the main scripts can be found in the table below.
NB for instructions on how to start-up and shutdown the deploy please see section
Shutdown and Start-up of Single Host Deploy
Script Description
startup.sh Main start script which controls the start-up of all of the
components within the environment.
shutdown.sh Main shutdown script which controls the shutdown of
all the components within the environment
The details of the other scripts are given below. These scripts are typically only run
when the solution is deployed on multiple hosts see Appendix B
Script Description
startDeltaControl.sh Starts Control process

stopDeltaControl.sh Stops Control process
startDeltaControlDaemon.sh Starts Daemon Process
stopDeltaControlDaemon.sh Stops Daemon Process
startAppServer.sh Starts App Server Workflows (DS_launch_APPSERVER_A
& DS_launch_APPSERVER_B)
NB: Control / Daemon must be running
stopAppServer.sh Stops App Server Workflows (DS_launch_APPSERVER_A
& DS_launch_APPSERVER_B)
NB: Control & Daemon must be running
startWorkflows.sh Start Workflows. Takes either a single workflow name
or a comma separated list of workflows.
If neither are specified the script will start-up all
workflows in the startup_workflows.txt file within the
delta-bin/config directory.
NB: Control & Daemon must be running)
stopWorkflows.sh Stops Workflows. Takes either a single workflow name,
a comma separated list of workflows or the value ALL
(which causes all running workflows to be stopped).
If no value is passed in the script will shut down all
workflows in the startup_workflows.txt file within the
delta-bin/config directory.
NB: Control & Daemon must be running
19
Control Web UI
The Control Web UI was introduced in version 4.0.0 and replaces the previous Eclipse
DCUI Desktop client.
To log in to Control Web UI follow the link provided by the start-up output in the
previous section, an example of which is seen below:
Upon navigating to the following link you will be presented with the following screen
Delta Control:
[http://kx-deploy.firstderivatives.com:8080/control]
Login using the following credentials:

 Username: Administrator
 Password: password
20
On successful log in you will be presented with the following screen. This screen
shows the Process Library Status Viewer, you can see from the screen shot below
that workflows are already running
Also inside the Web UI you will notice a navigation menu. From here you can do
many things, such as start and stop workflows and create new users.
21
To view a workflow, click on the workflow tab and then select a workflow such as
DS_launch_AT_A
Currently you can see this workflow is started as the workflows are a bright green
colour. To stop a workflow simply select the red square (the stop button) and the
workflow will stop, to start it up again click the green button
22
Dashboards for Kx
To log in to Dashboards follow the link provided by the start-up output in the previous
section, an example of which is seen below:
Dashboards:
[http://kx-deploy.firstderivatives.com:8080/dashboards/quickview]
Upon navigating to the link you will be presented with the following screen
Login using the username and password:

23
Analyst
To access Analyst follow the link provided by the start-up output in the previous
section, an example of which is seen below:
Analyst:
[http://kx-deploy.firstderivatives.com:8080/analyst]
Upon following the link you will be provided with the following login screen, Logon
with the Username and password:
24
Upon clicking the logon button you will be presented with another screen, select the
number of Workspace CPU Slaves and click ok
When this is done you will need to create a workspace, to do this click the create
workspace button and then enter a name for it
When a workspace has been created, click on the open workspace and Analyst will
start open successfully
25
Restarting Single Host Deploy
In order to shut down the deploy you should go to the kxinstall directory and
navigate to the main bin directory as follows.
$ cd ~/kxinstall/delta-bin/bin
Once here you should run the shutdown script. This can be done with the following
command:
$ ./shutdown.sh
The output of the above command should look something like this:
Kx Platform Shutdown
[kxuser@kx-deploy.firstderivatives.com]
+-----------------------------------------------------------+
Stopping App Server .....done
Stopping Workflow [DS_launch_MS_A] .....done
Stopping Workflow [DS_launch_ALERT_A] .....done
Stopping Workflow [DS_launch_OPS_A] .....done
Stopping Workflow [DS_launch_REPORT_A] .....done
Stopping Workflow [DS_launch_AT_A] .....done
Stopping Workflow [ALL] .....done
Stopping Remaining Processes .....done
Stopping Daemon .....done
Stopping Control .....done
+-----------------------------------------------------------+
Finished.
You can check that the processes have been shut down using the “ps” command if
you know the install directory (default in $HOME/kxinstall. To do this run the “ps”
command as follows.
$ ps -ef | grep $USER/kxinstall | grep -v grep

$
If the running the command above gives no output as above then the environment
has been successfully shutdown. If there are still processes running they should be
killed using the “kill” command.
26
Then in order to start up the deploy again, you can use the ./startup.sh from the
same directory. The output should look something like this:
Kx Platform Startup
[kxuser@kx-deploy.firstderivatives.com]
+-----------------------------------------------------------+
Starting Workflow [DS_launch_MS_A] .....done
Starting Workflow [DS_launch_ALERT_A] .....done
Starting Workflow [DS_launch_OPS_A] .....done
Starting Workflow [DS_launch_REPORT_A] .....done
+-----------------------------------------------------------+
Delta Control:
[http://kx-deploy.firstderivatives.com:8080/control]
Dashboards:
[http://kx-deploy.firstderivatives.com:8080/dashboards/quickview]
Analyst:
[http://kx-deploy.firstderivatives.com:8001/analyst]
+-----------------------------------------------------------+
Finished.
Using the “ps” command you can check that the 3 main processes have been
started.
Control
$ ps -ef | grep $USER/kxinstall | grep centralconfig

ddempsey 14232 1 6 14:58 pts/0 00:00:06 q q/centralconfig.q_ -tdir
/home/ddempsey/kxinstall/delta-data/DeltaControlData/tdir -qsrc
/home/ddempsey/kxinstall/delta-data/DeltaControlData/qsrc -p 2250 -fail
/home/ddempsey/kxinstall/delta-bin/config/failover.csv
Daemon
$ ps -ef | grep $USER/kxinstall | grep DeltaDaemonServiceMain

ddempsey 14261 1 4 14:58 pts/0 00:00:06 java -Dnetty.server.port=12169 -
Ddaemon.fileMntBase=/home/ddempsey/kxinstall/delta-data -Djava.awt.headless=true -
Xms1024m -Xmx2048m -verbose:gc -XX:+PrintGCTimeStamps -XX:+PrintGCDetails -
XX:ParallelGCThreads=5 -Xmn100m -XX:MaxGCPauseMillis=2000 -XX:GCTimeRatio=10 -
XX:+DisableExplicitGC -XX:+HeapDumpOnOutOfMemoryError -Ddelta.daemon.host=control-
a.fd.com -Ddelta.host=control-a.fd.com -DdeltaControl.host=control-a.fd.com -cp
conf:hotfix:hotfix/*.jar::lib/aopalliance-1.0.jar:lib/commons-beanutils-
1.8.0.jar:lib/commons-cli-1.2.jar:lib/commons-codec-1.7.jar:lib/commons-
collections-3.2.1.jar:lib/commons-exec-1.1.jar:lib/commons-io-2.4.jar:lib/commons-
lang-2.5.jar:lib/commons-logging-1.1.1.jar:lib/deltaj-core-4.1.0.9.jar:lib/deltaj-
daemon-4.1.0.2.jar:lib/deltaj-perfmon-4.1.0.9.jar:lib/ezmorph-1.0.6.jar:lib/guava-
13.0.1.jar:lib/jcl-over-slf4j-1.7.5.jar:lib/json-lib-2.4-jdk15.jar:lib/jul-to-
slf4j-1.7.5.jar:lib/log4j-1.2.17.jar:lib/logback-classic-1.0.13.jar:lib/logback-
core-1.1.3.jar:lib/nanotime-1.0.1.jar:lib/netty-all-4.0.24.Final.jar:lib/sigar-
1.6.4.jar:lib/slf4j-api-1.7.5.jar:lib/spring-aop-3.2.2.RELEASE.jar:lib/spring-
beans-3.2.2.RELEASE.jar:lib/spring-context-3.2.2.RELEASE.jar:lib/spring-core-
3.2.2.RELEASE.jar:lib/spring-expression-3.2.2.RELEASE.jar:lib/sysmon-3.0.2.6.jar:
com.fd.delta.daemon.DeltaDaemonServiceMain >> /home/ddempsey/kxinstall/delta-
data/DeltaControlData/logdir/DeltaControlDaemon.log 2>&1
Tomcat
27
$ ps -ef | grep $USER/kxinstall | grep apache

ddempsey 14373 1 51 14:58 pts/0 00:01:46
/home/ddempsey/buildtools/sun/java/jdk1.8.0_05/bin/java -
Djava.util.logging.config.file=/home/ddempsey/kxinstall/delta-
bin/software/Tomcat_7_0_82/latest/conf/logging.properties -
Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -
DinstanceName=ds_appServer_a.1 -DinstanceId=82 -DdeltaControlPort=2250 -
DdeltaControlHost=control-a.fd.com -
DdeltaAppServer.data=/home/ddempsey/kxinstall/delta-data/DeltaAppServer -
Dnetty.server.port=17003 -
DdeltaAppServer.fileMntBase=/home/ddempsey/kxinstall/delta-data -
DdeltaAppServerVirusScanEnabled=false -DdeltaAppServer.dashTitle=First_Derivatives
-XX:OnOutOfMemoryError=/home/ddempsey/kxinstall/delta-
bin/software/DeltaAppServer_4_1_0/scripts/killAppServer.sh -
XX:HeapDumpPath=/home/ddempsey/kxinstall/delta-data/DeltaAppServer -Xms1280m -
Xms2048m -DdeltaControl.tls=OFF -Dlog.dir=/home/ddempsey/kxinstall/delta-
bin/software/Tomcat_7_0_82/latest/logs -Dtomcat.port=8081 -Dtomcat.server.port=8006
-Dtomcat.redirect.port=8088 -Dtomcat.secure.port=8443 -Dtomcat.ajp.port=8010 -
Dtomcat.connector.max.threads=1000 -Ddelta.appserver.host=control-a.fd.com -
Ddelta.appserver.netty.server.port=17003 -
Dtomcat.deploy=/home/ddempsey/kxinstall/delta-
bin/software/Tomcat_7_0_82/latest/webapps/connect/ -
Dconnect.jgroups.bind_port=18001 -
Dconnect.jgroups.tcpping.initial_hosts=localhost[18001] -Dresponse.timeout.ms=60000
-Drequest.maxage.ms=20000 -Dsoft.session.timeout.ms=300000 -
Dhard.session.timeout.ms=86400000 -Dsession.expiry.timer.freq.ms=30000 -
Daction.on.websocket.disconnect=unsubscribeAll -
Dwebsocket.message.size.limit.chars=8388608 -
Dwebsocket.message.send.time.limit.ms=10000 -
Dwebsocket.message.buffer.limit.bytes=1048576 -Droles.check.enabled.flag=true -
Dconnect.json.html.encode=false -Drtmps.transport= -Drtmp.transport= -
Djgroups.config=./jgroups-nio.xml -Dappserver.jgroups.bind_port=17001 -
Dappserver.jgroups.tcpping.initial_hosts=localhost[17001] -Dheartbeat-frequency=30
-XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+UseParallelGC -
XX:ParallelGCThreads=6 -XX:+HeapDumpOnOutOfMemoryError -
Djava.net.preferIPv4Stack=true -Djdk.tls.ephemeralDHKeySize=2048 -
Djava.endorsed.dirs=/home/ddempsey/kxinstall/delta-
bin/software/Tomcat_7_0_82/latest/endorsed -classpath
/home/ddempsey/kxinstall/delta-
bin/software/Tomcat_7_0_82/latest/bin/bootstrap.jar:/home/ddempsey/kxinstall/delta-
bin/software/Tomcat_7_0_82/latest/bin/tomcat-juli.jar -
Dcatalina.base=/home/ddempsey/kxinstall/delta-bin/software/Tomcat_7_0_82/latest -
Dcatalina.home=/home/ddempsey/kxinstall/delta-bin/software/Tomcat_7_0_82/latest -
Djava.io.tmpdir=/home/ddempsey/kxinstall/delta-
bin/software/Tomcat_7_0_82/latest/temp org.apache.catalina.startup.Bootstrap start
28
Upgrading a Deploy
Upgrade packages for the Kx Platform deploy are delivered via the nexus download
site. There are 2 types of upgrade release:
 Patch Release
 Major / GA Release
Patch Release
A patch release consists of a subset of the platform constituent packages

containing bug fixes for issues which have been address since the previous Major
Release.
There can be several patch releases subsequent to each Major release and it is
important to keep your platform installation up to date with the most recent patch.
Patch releases are detailed on the Kx Release Information page:
The table above shows that there have been five patches released since the GA or
Major Release of version 4.0.2. The latest patch release (Patch 5 (P5)) above also
contains all of the previous patch releases (in this case Patches 1-4 + Patch 5).
29
Major / GA Release
A Major or GA release consists of a new version of all constituent packages which

contain bug fixes along with new features which have been added to the platform
since the previous Major Release.
Major releases are detailed on the Kx Release Information page:
The table above gives the links to the GA release 4.0.3. In order to perform a fresh
deploy of the 4.0.3 release or upgrade a previous deploy to version 4.0.3 you must
download both the GA and the latest patch release. In this case 4.0.3 and 4.0.3
Patch 1.
Patch bundles contain only the packages which have changed since the GA was
released and they can be untarred over the top of an existing GA bundle download
when doing a clean deploy. See below both the GA and the Patch untar into the
same directory name PlatformKx-4.0.3-RHEL70
$ tar -xvzf PlatformKx-4.0.3-RHEL70-GA.tgz

PlatformKx-4.0.3-RHEL70/
PlatformKx-4.0.3-RHEL70/scripts/
PlatformKx-4.0.3-RHEL70/scripts/installDeltaXML.sh
PlatformKx-4.0.3-RHEL70/scripts/install.config
PlatformKx-4.0.3-RHEL70/scripts/functions.sh
PlatformKx-4.0.3-RHEL70/scripts/startup_workflows.txt
PlatformKx-4.0.3-RHEL70/README.txt
PlatformKx-4.0.3-RHEL70/install.sh
PlatformKx-4.0.3-RHEL70/docs/
PlatformKx-4.0.3-RHEL70/docs/KxPlatformDeploymentGuide-v21.pdf
PlatformKx-4.0.3-RHEL70/packages/
PlatformKx-4.0.3-
RHEL70/packages/Analyst_4_0_3_9789_Linux_64bit_310_gcc483_libc217.tgz
PlatformKx-4.0.3-RHEL70/packages/AnalystUI_4_0_3_18627.tgz
PlatformKx-4.0.3-RHEL70/packages/ControlWebUI_4_0_3_18610.tgz
PlatformKx-4.0.3-RHEL70/packages/DeltaAppServer_4_0_3_18613.tgz
PlatformKx-4.0.3-RHEL70/packages/DeltaConnect_4_0_3_9778.tgz
PlatformKx-4.0.3-RHEL70/packages/DeltaControl_4_0_3_9778.tgz
PlatformKx-4.0.3-RHEL70/packages/DeltaDashboard_4_0_3_18613.tgz
PlatformKx-4.0.3-RHEL70/packages/DeltaStream_4_0_3_9782.tgz
PlatformKx-4.0.3-RHEL70/packages/HTML5Dashboards_4_0_3_18613.tgz
PlatformKx-4.0.3-RHEL70/packages/HTML5DashboardsEval_4_0_3_18613.tgz
30
PlatformKx-4.0.3-RHEL70/packages/Java_1_8_0_6080_linux_x64.tgz
PlatformKx-4.0.3-RHEL70/packages/KDBPlus_3_5_0_20170907.tgz
PlatformKx-4.0.3-RHEL70/packages/Tomcat_7_0_73_403_9499.tgz
$ tar -xvzf PlatformKx-4.0.3-RHEL70-P1.tgz

PlatformKx-4.0.3-RHEL70/
PlatformKx-4.0.3-RHEL70/scripts/
PlatformKx-4.0.3-RHEL70/scripts/installDeltaXML.sh
PlatformKx-4.0.3-RHEL70/scripts/install.config
PlatformKx-4.0.3-RHEL70/scripts/functions.sh
PlatformKx-4.0.3-RHEL70/scripts/startup_workflows.txt
PlatformKx-4.0.3-RHEL70/README.txt
PlatformKx-4.0.3-RHEL70/install.sh
PlatformKx-4.0.3-RHEL70/docs/
PlatformKx-4.0.3-RHEL70/docs/KxPlatformDeploymentGuide-v21.pdf
PlatformKx-4.0.3-RHEL70/packages/
PlatformKx-4.0.3-RHEL70/packages/HTML5Dashboards_4_0_3P1_19094.tgz
PlatformKx-4.0.3-RHEL70/packages/HTML5DashboardsEval_4_0_3P1_19094.tgz
Upgrading a Deploy
Upgrades to an existing deploy are performed by downloading the latest Patch or

GA Release (plus subsequent patches) untaring the bundles and running the
install.sh script inside the bundle.
Pre upgrade steps
Before attempting to upgrade a deploy it is important that you perform the following
pre-upgrade steps to avoid the loss of Data or Configuration from your existing
deploy.
1. Shutdown the Deploy
The deploy should be shutdown using either the shutdown.sh script (in the case of a
single host deploy) or using the component shutdown scripts (stopDeltaControl.sh,
stopDeltaControlDaemon.sh etc) in the case of a multi host deploy (Appendix B –
Deployment Configurations: Restarting Multi-Host Deploy)
2. Confirm all processes have been terminated
Once the shutdown scripts have been executed a final check should be performed
at OS level on all hosts in the deploy to ensure the processes have successfully
terminated.
You can check that the processes have been shut down using the “ps” command if
you know the install directory (default in $HOME/kxinstall. To do this run the “ps”
command as follows.
$ ps -ef | grep $USER/kxinstall | grep -v grep

$
31
If the running the command above gives no output as above then the environment
has been successfully shutdown. If there are still processes running they should be
killed using the “kill” command.
Upgrade steps
Once the deploy has been successfully shutdown you can now proceed with the
upgrade. In order to upgrade the release bundles must be copied to all hosts in the
environment and the install.sh script should be run inside the untarred release
bundle(s) on each host as follows. NB if you are using a non-default deploy location
you must enter it at the “Platform install directory” prompt below.
$ ./install.sh
=============================================================
== install.sh [2.0.5] ==
=============================================================
Platform install directory [/home/ddempsey/kxinstall] :
+-----------------------------------------------------------+
Warn: Detected KX installation in [/home/ddempsey/kxinstall]
This tells us that the installer has found an existing deploy, enter yes to proceed with
the upgrade:
Warn: Detected KX installation in [/home/ddempsey/kxinstall]

Continue with upgrade: [yes]:
Upgrading Deploy
The installer will proceed with the upgrade. The upgrade process involves copying all
or some of the packages from the bundle into your deploy location (by default
$USER/kxinstall) and then updating the version variables in the delta.profile to match
the version of the newly deployed packages. Where packages contain Control for
Kx entities (analytics, instances, workflows etc) an additional step is run to import the
contents of these packages into the Control instance (Appendix I – Control Package
Import)
On a successful upgrade you should see:
Running Deploy
[***]
+-----------------------------------------------------------+
+-----------------------------------------------------------+
If your deploy fails you should consult the installation script log, found in the scripts
directory (e.g. scripts/ installDeltaXML.20180123_120538.log) and the
DeltaControl.log, found in the main platform log file directory (delta-
data/DeltaControlData/logdir/DeltaControl.log) in the deploy location.
32
Updating Licenses
In order to run the Platform you need 2 valid license files:
 KDB+ Software License (k4.lic)

 Delta Software License (.delta.lic)
When the licenses expire you will be require to update each license in your deploy.
Licenses live inside the main deploy dir at the following path delta-bin/config
The Delta License is a hidden file (filename starts with a “.”) so in order to view the
licenses in the directory you need to run:
$ ls -a delta-bin/config/
. .. .delta.lic delta.xml failover.csv footer.txt k4.lic ssl-certs
startup_workflows.txt tls-certs webserver-packages.txt
License files are delivered as follows.
KDB+ Software License
Zip file which contains client name and expiry date.
e.g. fd-10Jul15.lic.zip
Zip contains the k4.lic
Delta Software License
Single file which contains client name and expiry date
e.g. .FD-10Jul15-delta.lic
33
Updating Licenses
The license files are updated as follows:
KDB+ Software License
Unzip license, locate k4.lic and copy it into delta-bin/config.
This will replace the current license.
Delta Software License
Copy/rename the file to .delta.lic and copy it into delta-bin/config.
This will replace the current license.
34
Appendix A – install.sh additional options
The following table outlines additional arguments that can be added when running
the install.sh script:
Command Description Usage

-i Load an instance csv file ./install.sh –i instance.csv
containing predefined
instances and ports for the
deploy to use
-p Load a custom install config ./install.sh –p install.config.example
file containing configuration
for the deploy to use
-s Skip environment start-up ./install.sh –s
post deploy
-h Skip host check ./install.sh –h
-n Skip env check ./install.sh –n
-? Shows a message detailing all ./install.sh -?

available command line
options.
NB if you load a custom install.config file the install.sh will no longer prompt you for
the Single / Multi server or TLS configuration. This should be configured in your custom
install.config and if accept defaults is off the installDeltaXML.sh script will prompt you
for options.
35
Appendix B – Deployment Configurations
There are several deployment options for the Kx Platform. The Platform can be
thought of as series of layers which can be spread across multiple hosts in order to
provide resilience and traffic segregation (e.g. Web traffic VS application traffic).
Evaluation deploys will typically only use 1 host which will have all layers deployed
on it. The table below describes the three main layers in a Kx Platform Deploy.
Layer Description
Control Control process provides centralised configuration and process
control.
Web The web layer consists of a series of UI Applications installed into
an Apache Tomcat web server
Application Typically consists of a series of Stream components (TP, RDB HDB
etc) which are responsible for processing and providing access to
the data within the system.
Daemon Process
Control is used to configure and to run all processes and layers within the system. In
order to configure and run processes on a remote host (i.e. a separate Web or
Application host) a lightweight Daemon process is deployed which connects back
to Control. The Daemon typically runs on each Host in the deploy.
In this next section there will be 4 different Deployment configurations demonstrated

which vary.
36
Pre Deploy
Before running the deploy we need to ensure that we have a set of free ports on
each server that we can use. For Control we will use the same port on the
Master/Slave hosts. The default port value is 2001, to check if this is free on each
Control host run:
$ netstat -ant | grep -w 2001
If the port is free there will be no output but if a process is listening on the port then
you will see something like this.
$ netstat -ant | grep -w 2001

tcp 0 0 0.0.0.0:2001 0.0.0.0:* LISTEN
For Web boxes we need the following ports to be free

 8080 HTTP port for Tomcat
 8443 HTTPS port for Tomcat
If any of the ports above are in use the installer will select alternative values.
37
1. Multi Host Control and Web clustered deploy

In a typical multi host deploy there are 4 separate hosts. 2 running Control for Kx
instances (in a Master / Slave Failover Cluster) along with the stream processes (TP,
RDB, HDB etc) and 2 which runs the Web.
Host Details
control-a.fd.com Runs Master Control, Daemon and Stream KDB+ Processes
control-b.fd.com Runs Slave Control, Daemon and Stream KDB+ Processes
Web-a.fd.com Runs Master Daemon and Tomcat (Including Dashboards)
Web-b.fd.com Runs Slave Daemon and Tomcat (Including Dashboards)
The diagram below shows what this deploy would look like and the following section
describes how this deploy type can be achieved using the bundle installer.
control-a.fd.com control-b.fd.com
web-a.fd.com web-b.fd.com
You will do this in two sections; a control master/slave deploy and a web server
cluster deploy.
38
Control Master/Slave Deploy
control-a.fd.com control-b.fd.com
This section deals with the installation of the Master Control Instance. To deploy the
Master Control node you need to first select option [2]: Control
+----------------------------------------+
+----------------------------------------+
[1] Single
[2] Control
[3] Web Server
[4] Daemon
+-----------------------------------------------------------+
Select Mode [1-4] : 2
Then select if you want it to be a cluster, which it will be by default:
+-----------------------------------+
Configure Control Clustering[yes]:
+-----------------------------------+
You will now be prompted for the port for Control. This should be the same port on
both the Master/Slave hosts and so must be free to use. (see Pre Deploy above).
Host Configuration
!! THE SAME PORT MUST BE USED FOR EACH CONTROL INSTANCE IN THE CLUSTER!!
39
The next section deals with the host configuration, here we will enter details of the 4
hosts within the deploy. We will be prompted for hostnames, NB these must be in
FQDN form. we will also be prompted for the number of CPU cores on each host to
allow the installer to taskset our software appropriately across all available cores.
The current host is the Master Control host and so we need to enter the hostname of
the Slave Control Host
Master
Is this the [Master Control] Node [yes] : yes
FQDN of [Slave Control] node : control-b.fd.com
Slave
Is this the [Master Control] Node [yes] : no
FQDN of [Master Control] node : control-a.fd.com
From here we move on to the taskset configuration of the Control Cluster. In this
case we are entering the number of CPU Cores on which we are licensed to run
KDB+ on both of the control hosts. A value of 10 Cores will result in Control and the
Daemon running on Core 0 with the platform process instances being run across
cores 1-9. Do this on both Master and Slave.
Number of [Licensed KDB+] [CPU cores] on [Control Node(s)] : 10
The web server is configured via Control and so we must now enter the hostname
and the number of CPU cores on the webserver host. Here enter 5 cores on both
Master and Slave.
FQDN of [Web Server A] Node : web-a.fd.com

Configure [Web Server B][yes]: yes
FQDN of [Web Server B] Node : web-b.fd.com
Number of [CPU cores] on [Web Server] Nodes(s): 5
The TLS configuration is dealt with in Appendix D. In this case we are deploying
without TLS. And with a normal KDB+ license see below:
On a successful deploy you should see the following:
Encryption
+-----------------------------------------------------------+
KDB+ License Type
+-----------------------------------------------------------+
Please enter location of a kx license file (k4.lic) [dir]: /home/estuart/licences
+-----------------------------------------------------------+
Running Deploy
[*********]
+-----------------------------------------------------------+
Install.sh Finished
40
When deploying a Control node note that no processes are started up at the end of
the deploy. Details of how to bring up a multi-host deploy are dealt with at the end
of this section.
Install Config Configuration
If you are using the install script (installDeltaXML.sh) directly or passing a non-default
install.config file into the install.sh wrapper script (via -i) then you can configure the
above deploy layout as follows:
# control-a.fd.com
# Delta Control server bind port
# Delta Control UI connects to DC on this port
DELTACONTROL_PORT=2017
# Delta Control Daemon Configuration

DELTACONTROL_REMOTEHOST=control-a.fd.com
DELTACONTROL_REMOTEPORT=2017
# Apache Tomcat HTTP port

# Tomcat web address [http://localhost:8080/]
TOMCAT_PORT=8080
# Enable Delta Control Failover Cluster:

delta-control-clustering=1
delta-control-master-hostname=control-a.fd.com
delta-control-master-port=2017
delta-control-slave-hostname=control-b.fd.com
delta-control-slave-port=2017
# Host to start _a and _b process instances

auto-configure-instance-hostname-a=control-a.fd.com
auto-configure-instance-hostname-b=control-b.fd.com
# Bind all process instances to given taskset

auto-configure-instance-taskset=1-9
# Host to start _a and _b App Server process instances

app-server-hostname-a=web-a.fd.com
app-server-hostname-b=web-b.fd.com
# Bind App Server process to given taskset

app-server-taskset=1-9
41
# control-b.fd.com


TOMCAT_PORT=8080





42
Web Cluster Deploy
For both master and slave select Web Server to start the deploy
+----------------------------------------------+
+----------------------------------------------+
[1] Single
[2] Control
[3] Web Server
[4] Daemon
+----------------------------------------------+
Select Node Type [1-4] : 3
+----------------------------------------------+
The next part is to configure the web deploy. Start this by saying you are doing a
Control Cluster. When entering the FQDN of the control master and slave enter the
nodes from the previous Control Master/Salve section:
+----------------------------------------------+
Configuring Web Server Deploy
Is this Deploy connecting to a Control Cluster [no] : yes
FQDN of Master Control Node : control-a.fd.com
FQDN of Slave Control Node : control-b.fd.com
Now enter a free control cluster port to use:
Control Cluster Port : 2017
+----------------------------------------------+
43
You now have two options. 1) HTTP or 2) HTTPS. Do this on both master and slave. If
you choose the HTTPS option
OPTION 1 - HTTP
+------------------------------------------------+
[1] HTTP
[2] HTTPS
+------------------------------------------------+
+------------------------------------------------+
OPTION 2 - HTTPS
+------------------------------------------------+
[1] HTTP
[2] HTTPS
+------------------------------------------------+
+------------------------------------------------+
OPTION 1 - HTTP
+------------------------------------------------+
+------------------------------------------------+
OPTION 2 – HTTPS
+------------------------------------------------+
+------------------------------------------------+
You can finish the deploy and on successful deploy you should see the following:
Encryption
Deploy with TLS/SSL Encryption Enabled[no] :
+------------------------------------------------+
Running Deploy
[*********]
+------------------------------------------------+
+------------------------------------------------+
Kx Platform Startup
[estuart@web-a.fd.com]
+------------------------------------------------+
Starting Daemon . . .done
+------------------------------------------------+
Finished.
Install.sh Finished.
Completing the deploy

Once you have completed the previous steps you can now fully complete the
deploy and access the full range of features incl. Dashboards.
On Control Master and Slave navigate to the kxinstall/delta-bin/bin directory and

run ./startup.sh:
[estuart@control-a.fd.com ~]$ cd kxinstall/delta-bin/bin
44
[estuart@control-a.fd.com bin]$ ./startup.sh
On successful startup you will see the following:
Master
+-----------------------------------------------------+
Kx Platform Startup
[estuart@control-a.fd.com }
+-----------------------------------------------------+
Starting Control . . .done
+-----------------------------------------------------+
Finished.
Slave
+-----------------------------------------------------+
Kx Platform Startup
[estuart@control-b.fd.com }
+-----------------------------------------------------+
Starting Control . . .done
+-----------------------------------------------------+
Finished.
Finally, you can start the necessary workflows from this point such as App Server:
[estuart@control-a.fd.com ~]$ ./startAppServer.sh

KDB+ license valid
taskset -c 0 q q/run_command.q_ :control-a.fd.com:2017 .r.ismaster[] -nolog
2018.02.20 16:01:44 .r.ismaster[] = 1b
KDB+ 3.5 2018.02.09 Copyright (C) 1993-2018 Kx Systems

l64/ 1()core 27710MB estuart control-a.fd.com 10.152.20.15 EXPIRE 2018.03.16
firstderivatives.com INTERNAL #49564
:control-a.fd.com:2017 is the master, starting workflows
KDB+ 3.5 2018.02.09 Copyright (C) 1993-2018 Kx Systems

l64/ 1()core 27710MB estuart control-a.fd.com 10.152.20.15 EXPIRE 2018.03.16
firstderivatives.com INTERNAL #49564
opening connection to :control-a.fd.com:2017 as deltacomponent

running command: .wf.runWF'[`DS_launch_APPSERVER_A`DS_launch_APPSERVER_B]
(::;::)
# web-a.fd.com AND web-b.fd.com


45

TOMCAT_PORT=8080





46
2. Non-clustered Control with separate Web Host
Control-a.fd.com
Web-a.fd.com
Control deploy
Like previous, first the control side of the deploy will be demonstrated. Select the
control option after running install.sh

+-----------------------------------------------------------+
[1] Single
[2] Control
[3] Web Server
[4] Daemon
+-----------------------------------------------------------+
We are not doing a cluster so enter ‘no’ for the next part:
+-----------------------------------------------------------+
Configure Control Clustering [yes] : no
+-----------------------------------------------------------+
Enter a free port to use, in this case we will use 2017:
+-----------------------------------------------------------+
Node Configuration
47

cores 1-9.
Number of [Licensed KDB+] [CPU cores] on [Control] Node(s) : 10
Now you can enter the details of the web server part of the deploy (which is
covered in the next section)
FQDN of [Web Server A] Node : web-a.fd.com

Configure [Web Server B] [yes] : no
Number of [CPU cores] on [Web Server] Node(s) : 5
We can run the deploy without TLS enabled so just press enter as the default is [no]
Encryption
On success you should see the following:
+-----------------------------------------------------------+
Running Deploy
[*********]
+-----------------------------------------------------------+
install.sh Finished.
48
# control-a.fd.com


TOMCAT_PORT=8080

delta-control-master-hostname=master-hostname
delta-control-slave-hostname=slave-hostname

auto-configure-instance-hostname-b=NOHOSTSET


app-server-hostname-b=NOHOSTSET

49
Web Server Deploy

The second part to a mutli-host non-cluster deploy is the web server which will be
detailed below.
Select option [3] to specify web server
[1] Single
[2] Control
[3] Web Server
[4] Daemon
+-----------------------------------------------------------+
We are not deploying a cluster so say no to the following. Press enter:
+-----------------------------------------------------------+
Configuring Web Server Deploy
Is this Deploy connecting to a Control Cluster [no] : no
Just as for the control deploy we had to fill in details of the web server, we now need
to fill in details of the control deploy on the web server deploy like follows:
FQDN of Control Node : control-a.fd.com

Control Port : 2017
You now have two options. 1) HTTP or 2) HTTPS.
OPTION 1 - HTTP
+------------------------------------------------+
[1] HTTP
[2] HTTPS
+------------------------------------------------+
+------------------------------------------------+
OPTION 2 - HTTPS
+------------------------------------------------+
[1] HTTP
[2] HTTPS
+------------------------------------------------+
+------------------------------------------------+
OPTION 1 - HTTP
+------------------------------------------------+
+------------------------------------------------+
OPTION 2 – HTTPS
+------------------------------------------------+
+------------------------------------------------+
Similarly, we won’t be using TLS encryption so just press enter for the next part:
Encryption
50

On successful deploy you should see the following:
Encryption
Running Deploy
[**********]
+-----------------------------------------------------------+
+-----------------------------------------------------------+
Kx Platform Startup
[estuart@web-a.fd.com]
+-----------------------------------------------------------+
+-----------------------------------------------------------+
Finished.

On the Control box, navigate to /kxinstall/delta-bin/bin and run ./startup.sh. On
success you should see:
+-----------------------------------------------------------+
+-----------------------------------------------------------+
Finished.
# web-a.fd.com

DELTACONTROL_REMOTEHOST= control-a.fd.com

TOMCAT_PORT=8080

delta-control-master-hostname=master-hostname
delta-control-slave-hostname=slave-hostname

auto-configure-instance-hostname-b=
51


app-server-hostname-a=localhost
app-server-hostname-b=localhost

52
3. Control and Web cluster deploy
Control-a.fd.com Control-b.fd.com
This Deploy is very similar the previous deploy, where the only difference is that we
don’t use separate boxes to host the web server side.
Select [2] control on both master and slave:
[1] Single
[2] Control
[3] Web Server
[4] Daemon
+-----------------------------------------------------------+
Since this is a cluster deploy, say yes by pressing enter to the following:
Configure Control Clustering [yes] :
53
You can now configure the control side of the deploy by entering the master and
slave host names and a free port to use:
Master
Node Configuration
Is this the [Master Control] Node [yes] :
FQDN of [Slave Control] Node : control-b.fd.com
Slave
Node Configuration
Is this the [Master Control] Node [yes] : no
FQDN of [Master Control] Node : control-a.fd.com
cores 1-9.
Number of [Licensed KDB+] [CPU cores] on [Control] Node(s) : 10
This is the part where this deploy differs from the previous deploy. You must specify
the details of the web server nodes a and b, a being the same as the master control
node and b being the same as the slave control node. Do the following on both
master and slave:
FQDN of [Web Server A] Node : control-a.fd.com

Configure [Web Server B] [yes] :
FQDN of [Web Server B] Node : control-b.fd.com
Number of [CPU cores] on [Web Server] Node(s) : 5
We will be doing this without TLS encryption enabled so press enter to default to [no]
for the following:
Encryption
Upon successful deploy you should see the following on both master and slave:
Running Deploy
[****************]
+-----------------------------------------------------------+
54

On the Control Master box, navigate to /kxinstall/delta-bin/bin and run ./startup.sh.
On success you should see:
+-----------------------------------------------------------+
+-----------------------------------------------------------+
Finished.
# control-a.fd.com AND control-b.fd.com THE SAME


DELTACONTROL_REMOTEHOST= control-a.fd.com

TOMCAT_PORT=8080





55
Restarting Multi-Host Deploy
Shutdown
The shutdown of a Multi Host deploy is done in the reverse order with the AppServer
and Workflows being brought down before the Control layer.
The following scripts should be run in turn on the Control Master Host:
$ ./stopAppServer.sh
$ ./stopWorkflows.sh
$ ./stopAllProcesses.sh
Once the above scripts have successfully run its time to bring down the Daemon on
each Host in the deploy. This is done by running the stopDeltaControlDaemon.sh
script.
With the daemons stopped the last step is to bring down the Control Cluster. When
doing this you always stop the Slave Control instance first.
On control-b.fd.com run:
$ ./stopDeltaControl.sh
Once this is complete logon to control-a.fd.com and run the same script:
$ ./stopDeltaControl.sh
56
Start-up
When dealing with a Multi Host Deploy the order in which the various components
are brought up is very important. The following section will give the order in which to
bring up the components on each Host using the Deployment above as an
example.
Control Layer
With Control deployed in a failover cluster the Control instance on host control-
a.fd.com is our preferreed Master. When starting up a pair of clustered Control
instances the Master should be started first and the Slave should be started second.
control-a.fd.com
$ ./startDeltaControl.sh
Sourcing [../delta.profile]
Sourcing [../delta_user.profile]
Sourcing [../delta.instance.profile]
KDB+ license valid
Starting Delta Control 4.1.0 on port 2001 using KDB+ 3.5.0
Delta Control [PID:32052] started successfully
control-b.fd.com
$ ./startDeltaControl.sh
KDB+ license valid
Starting Delta Control 4.1.0 on port 2150 using KDB+ 3.5.0
Delta Control [PID:32105] started successfully
You should see the folllowing in the DeltaControl.log on control-a.fd.com
This process is now the master
And this in the DeltaControl.log on control-b.fd.com
This process is a slave - attempting to sync with master ###

`host`port`handle`uid!(`control-a.fd.com;2001i;6i;0)
57
Daemons
With the Control layer running the Daemons should now be started on each host in
the deploy. This is done using the startDeltaControlDaemon.sh in the bin directory.
Example output from running this script is given below.
$ ./startDeltaControlDaemon.sh
/home/ddempsey/kxinstall/delta-bin/software/DeltaControl_4_1_0/jcore/Daemon
Daemon running as pid 32193
Delta Daemon [PID:32193] started successfully
NB on the web host above the Daemon will have been brought up as part of the
initial deploy.
App Server
With the Daemon processes running we can now start the AppServer process which
runs inside Tomcat. This is done by running the start startAppServer.sh script on the
Master Control Host
[ddempsey@control-a.fd.com bin]$ ./startAppServer.sh
NB the AppServer can take a few minutes to become fully operational. Once it is
accessible via the URL the system start-up is complete.
Workflows
Once the Daemons and AppServer are running we can now bring up the system
processes via the startWorkflows.sh script which is run on the Master Control Host.
Below the script is run without arguments, this will start-up all workflows in the
startup_workflows.txt file within the delta-bin/config directory.
[ddempsey@control-a.fd.com bin]$ ./startWorkflows.sh
58
Appendix C – Default Process Workflows

The bundles are delivered in 2 different formats, Platform and Eval. The Platform
bundle contains all the necessary components on which a Kx Solution can be built
whereas the Eval bundle contains the platform with some example Evaluation
solution package. Each bundle comes with its own startup_workflows.txt file which
list the workflows which are started when the environment is brought up (normally via
the startup.sh script).
Each bundle will bring up the DS_launch_APPSERVER_A workflow via the

startAppServer.sh script in delta-bin/bin.
The additional workflows for each bundle type are given below:
Platform Bundle
Workflow Description
DS_launch_MS_A Messaging Service: Process instance which aids discovery
for publishers and subscribers within the system
DS_launch_ALERT_A Alerts Eco-System: Process instances required to configure
and generate alerts
DS_launch_OPS_A Operations Eco-System. Process instances to store and
provide access to monitoring statistics
DS_launch_REPORT_A Reporting Eco-System: Process instances required to
configure and generate reports
DS_launch_AT_A Action Tracker Eco-System: Process instances required to
create, transition and store action tracker items
Eval Bundle
Workflow Description
DS_STARTALL_FXEVAL Starter workflow which starts FX Eval process instances, Alert
Eco-System and Reporting Eco-System.
DS_launch_AT_A Action Tracker Eco-System: Process instances required to
create, transition and store action tracker items
DS_launch_html5eval Starts dashboard eval stats engine
59
Appendix D – TLS Configuration
KDB+ version 3.4 onwards supports SSL/TLS connections. The Kx platform supports TLS
from version 4.0.2 onwards on both Linux and Windows.
Certificates / Keys:
In order to use TLS you need to provide the following certificates and key files.
Name Description
server-crt.pem Server certificate file
server-key.pem Server key file
ca.pem Certificate Authority file
Enabling TLS at Deploy Time
Installing - Using Default Install Config
Place the files above in a known location on each deploy host. When prompted to
Deploy with TLS/SSL Encryption Enabled answer yes.
Encryption
Deploy with TLS/SSL Encryption Enabled [no] : yes
Client Certs
By default TLS configuration omits the Client certificate but If you wish to include your
client Certificate in the TLS deploy you can do so by answering yes to the prompt
below. You will then be asked for the location of your client-crt.pem file. In this
example we will accept the Default option of no.
Deploy TLS/SSL Client Certificate [client-crt.pem] [no] :
Next enter the location of your certificate files (in the example below all the required
certificate files are in the users home directory in a sub directory called certs). Each
certificate file will be copied into the scripts directory inside the bundle so avoid
prompting for future upgrades.
TLS/SSL Certificates
Location of server certificate file (server-crt.pem]) [dir] : ~/certs
The deploy should now proceed with TLS enabled.
Using certificate [/home/ddempsey/certs/server-crt.pem]
60
Using certificate [/home/ddempsey/certs/server-key.pem]

Using certificate [/home/ddempsey/certs/ca.pem]
The script will check the current directory, the scripts directory and any directory you
provide when prompted for each of the required certificate files. Any files which are
not found in these locations will be prompted for. In the example below the
certificate directory has been provided but the ca.pem is not present so the script
prompts for the location of this file:
Location of server certificate file (server-crt.pem]) [dir] : ~/certs

Using certificate [/home/ddempsey/certs/server-crt.pem]
Using certificate [/home/ddempsey/certs/server-key.pem]
Location of certificate authority file (ca.pem]) [dir] :
Installing - Non Default InstallConfig
If you are passing your own custom install config file into the install.sh script (via -p)
then you’ll need to either:
Add the TLS options manually to your install config
In order to do this, add the following lines to your custom install config which will tell
the installer you want to deploy with TLS enabled and where it can find your .pem
files:
# TLS
tls-encryption-enabled=1
ssl-server-cert-file=server-crt.pem
ssl-server-key-file=server-key.pem
ssl-ca-cert-file=ca.pem
You can now run the deploy as normal and it will be TLS enabled.
Configure TLS via the main install script
If you answer yes to enable TLS encryption you will then be prompted for the
location of the required .pem files listed in the table above.
[tls-encryption-enabled]
Install with TLS encryption enabled [no]: yes
+-----------------------------------------------------------+
please enter location of file [server-crt.pem]:
You will then see the following and the install will complete with TLS enabled.
Installing with TLS Encryption enabled
Post Deploy Checks
61
With TLS on you will see the following line in the delta.profile
export DELTACONTROL_TLS=ON
The certificates provided above will have been copied into the [delta-bin/config/tls-
certs] directory as follows:
$ ls ~/kxinstall/delta-bin/config/tls-certs/
ca.pemkeystore.jks server-crt.pem server-key.pem
install.config file into the install.sh wrapper script (via -i) the you can configure TLS as
follows:
#============================================================
# TLS CONFIGURATION
#============================================================
tls-encryption-enabled=1
ssl-server-cert-file=/path/to/server-crt.pem
ssl-server-key-file=/path/to/server-key.pem
ssl-ca-cert-file=/path/to/ca.pem
#tls-include-client-certificate=1
#ssl-client-cert-file=client-crt.pem
62
Enabling TLS Post Deploy
If TLS was not enabled at deploy time it can be enabled post deploy using the
following steps.
Certificates / Keys:
In order to use TLS you need to provide the following certificates and key files.
Name Description
server-crt.pem Server certificate file
server-key.pem Server key file
ca.pem Certificate Authority file
The certificates above should be copied into the tls-certs dir inside the deploy
(delta-bin/config/tls-certs).
Generating Keystore
Once the certificates above are in place you need to use them to create a Java
Keystore which will be used by the App Server to connect to the TLS enabled KDB+
processes including Control for Kx.
In order to create the keystore you must have openssl (1.0.1+) installed and a Java
JRE/JDK 1.8 on your PATH.
To create the keystore cd into the delta-bin/config/tls-certs directory and run the
following commands.
$ cat server-crt.pem ca.pem > all.pem

$ openssl pkcs12 -export -inkey server-key.pem -in all.pem -name serverKeyStore -
out all.p12 -passin pass:changeit -passout pass:changeit
$ keytool -importkeystore -srckeystore all.p12 -srcstoretype pkcs12 -destkeystore
keystore.jks -srcstorepass changeit -deststorepass changeit
$ rm all.p12 all.pem
You should now a Java Keystore named keystore.jks inside the tls-certs dir.
$ ls -1
all.pem
ca.pem
keystore.jks
server-crt.pem
server-key.pem
Update delta.profile
With the certificates and keystore in place the next step is to enable TLS
63
by opening the delta.profile and setting:
As an additional check ensure that this line is followed by the TLS environment
variables below. If they are not present add them.
export DELTACONTROL_PERM_MAP=YES
export SSL_CERT_FILE=${DELTA_CONFIG}/tls-certs/server-crt.pem
export SSL_KEY_FILE=${DELTA_CONFIG}/tls-certs/server-key.pem
export SSL_CLIENT_CERT_FILE=${DELTA_CONFIG}/tls-certs/client-crt.pem
export SSL_CA_CERT_FILE=${DELTA_CONFIG}/tls-certs/ca.pem
export SSL_CA_CERT_PATH=${DELTA_CONFIG}/tls-certs/
export SSL_KEYSTORE_FILE=${DELTA_CONFIG}/tls-certs/keystore.jks
export SSL_KEYSTORE_PASS=changeit
export SSL_VERIFY_SERVER=YES
export SSL_VERIFY_CLIENT=NO
Restart Environment
The changes above will not take effect until the environment is restarted. This is done
by cd’ing into the delta-bin/bin directory and running shutdown.sh followed by
startup.sh.
4.1.0+ Additional Steps
If enabling TLS on a 4.1.0+ deploy there is an additional step required if you are using
HTTPS Tomcat connectors with TLS enabled back end. The additional step involves
exporting your certificates form the connector keystore (See Appendix E) and
importing it into your javax.net.ssl.trustStore (delta-bin/config/tls-certs/keystore.jks).
The steps required to do this are given below and they assume your connector
keystore is in your home dir (~/.keystore). cd into the delta-bin/config/tls-certs
directory and run the following commands.
$ keytool -export -alias tomcat -keystore ~/.keystore -rfc -file tomcat.cer -

srcstorepass changeit -deststorepass changeit
$ keytool -import -alias tomcat -keystore keystore.jks -rfc -file tomcat.cer -
srcstorepass changeit -deststorepass changeit -noprompt
$ rm -f tomcat.cer
The command above assumes the key you wish to export has the alias “tomcat” in
the connector keystore (~/.keystore) and that the password of that keystore is
changeit (-srcstorepass changeit).
64
Appendix E – Tomcat SSL Installation

Tomcat is deployed as the Web Application server of choice for Dashboards. By
default the Tomcat instance is configured to serve content over HTTP but it can be
configured on deploy to use HTTPS (SSL) instead. The steps required to enable
HTTPS/SSL are described below:
In order to enable SSL on the Tomcat deploy you must provide a Java Keystore
which contains the required certificates,
You can generate a keystore using the following instructions from the tomcat docs
page:
https://tomcat.apache.org/tomcat-7.0-doc/ssl-howto.html
To install and configure SSL/TLS support on Tomcat, you need to follow these simple
steps.
1. Create a keystore file to store the server's private key and self-signed
certificate by executing the following command:
$JAVA_HOME/bin/keytool -genkey -alias tomcat -keyalg RSA
and specify a password value of "changeit".
If you are using the bundle install config (scripts/install.config) change the app-
server-install-type to 2, uncomment the tomcat-keystore-file and tomcat-keystore-
password and update the path to the keystore and the keystore password.
#============================================================
# TOMCAT / APP SERVER OPTIONS
#============================================================
# Install app server with HTTP (1) HTTPS (2)

app-server-install-type=2
# Tomcat SSL Options

tomcat-keystore-file=~/.keystore
tomcat-keystore-password=changeit
If you are using a custom install config then you need to add the 3 install options
above into your config
65
Tomcat URLs
Tomcat will use the TOMCAT_SECURE_PORT value as the port for your HTTPS/SSL
connector. The HTTP port (TOMCAT_PORT) will redirect to the HTTPS/SSL port.
With HTTP/SSL enabled Tomcat will be accessible using:
https://<server>:<TOMCAT_SECURE_PORT>/
e.g.
https://kxplatform:8443/
and also via HTTP
http://<server>:<TOMCAT_PORT>/
e.g.
http://kxplatform:8080/
NB The HTTP connector will redirect the user to the HTTPS port.
66
Appendix F – App Server Memory Allocation
From release 4.0.2 onwards the memory allocation for the App Server is controlled
via the following environment variables in the delta.profile.
Environment Variable Default (Megabytes) Description

APPSERVER_JVM_INITIAL_MEMORY 1280 Initial and minimum
heap size for JVM.
APPSERVER_JVM_MAX_MEMORY 2048 Maximum heap size for
JVM.
The values above can be altered at deploy time as follows:
JVM Memory Pre-sets
For production deploys of App Server the recommend values for the JVM heap sizes
are:
 APPSERVER_JVM_INITIAL_MEMORY = 1280
 APPSERVER_JVM_MAX_MEMORY = 8192
These can be achieved by adding the following to the end of either the bundle
install config (scripts/install.config) or a custom install config (passed in via -p).
#============================================================
# NEW / CUSTOM CONFIGURATION
#============================================================
tomcat-install-type=2
Custom Memory Allocation
If you wish to tune the memory allocation yourself then you can do this by adding
the following to the end of either the bundle install config (scripts/install.config) or a
custom install config (passed in via -p).
#============================================================
# NEW / CUSTOM CONFIGURATION
#============================================================
app-server-jvm-initial-memory=2560
app-server-jvm-max-memory=5120
67
Appendix G – Enabling SSO Deployment
As of 4.1.0, the platform support Single Sign On in the form of SAML. This allows the
platform to offload authorization to a third party Identity Provider (IDP)
Enabling SAML
SAML requires a number of ENV variables to be set before starting up the

environment.
Env Example Description

SPRING_PROFILES_ACTIVE saml To enable SAML SSO, the ENV must be set to
saml
SAML_SP_METADATA_ENTITY_ID hostPortUID A unique ID required to identify the Platform
(Service Provider) to the Identity Provider (IDP).
See IDP documentation for specific limitations
SAML_IDP_METADATA_FILE <fullPath to IDP xml> SAML IDPs provide a metadata file used by the
SP to allow trusted communication between
the SP and IDP. This should be downloaded
and available to the platform
SAML_KEYSTORE_FILE $SSL_KEYSTORE_FILE Encrypted TLS communication between an SP
and IDP. By default the certificates defined as
part of a TLS install are used; though any valid
keystore file is acceptable
SAML_KEYSTORE_PASS $SSL_KEYSTORE_PASS Password for the KEYSTORE file above
APPSERVER_SPLASHPAGE saml/index.jsp SAML requires a specific entry point. This must
be defined as in the Example column
1. Install platform as per normal. Install configuration file can be used to set the
ENV variables defined above if known. They can also be set post installation
as detailed below)
2. Update the delta.profile as appropriate:
a. Set ENV SPRING_PROFILES_ACTIVE to saml.
b. Provide unique SAML_SP_METADATA_ENTITY_ID.
c. Set the location of the SAML_IDP_METADATA_FILE. The IDP metadata
file can be retrieved from the IDP in use.
d. Set the APPSERVER_SPLASHPAGE to saml/index.jsp.
3. If using a TLS deploy; the default keystore and password can be set to the
same keystore and password used for inter process communication;
SAML_KEYSTORE_FILE=$SSL_KEYSTORE_FILE,
SAML_KEYSTORE_PASS=$SSL_KEYSTORE_PASS. Otherwise a unique keystore and
password can be generated and defined by these ENVs.
4. Modify the web.xml to enable Spring security filters. Located at …/delta-
bin/software/Tomcat_7_0_82/apache-tomcat-7.0.82/webapps/ROOT/WEB-
INF/web.xml. Uncomment the section titled ‘Added for SAML; uncomment’.
68
5. Start the environment including Tomcat

6. It is now necessary to update your IDP with the SP (the Platform) metadata
details to allow the SP to authorize through the IDP. This includes information
include the EntityID of the SP; message encryption details and various URLs for
redirection. Depending on the IDP; this may be possible by uploading the SP
metadata file; which is available @
http://<hostOfEnv>:<portOfEnv>/saml/metadata. This provides an XML
describing the SP which your IDP may accept. If the IDP does not accept an
XML, it may be necessary to populate the SP configuration manually on the
IDP. This data will be available in the downloaded XML. See your IDP for
further details on how to configure an SP
7. Once setup, navigate to the base URL http://<hostOfEnv>:<portOfEnv> to
login to the environment through SAML
In addition, there are number of other ENV configuration values which can be set to
change the SAML setup
Env Default Description

SAML_BASEURL http://${DELTAAPPSERVER_HO Used for the base redirect URL post
ST}:${TOMCAT_PORT} authorization with the IDP if
$TOMCAT_USES_SSL is ‘0’
SAML_SECURE_BASEURL https://${DELTAAPPSERVER_H Used for the base redirect URL post
OST}:${TOMCAT_SECURE_POR authorization with the IDP if
T} $TOMCAT_USES_SSL is ‘1’
SAML_MAX_AUTH_AGE 28800 Max age in seconds a SAML Authorized
Assertion can live
SAML_USERID_FIELDS principle The fields (csv) used by the platform to
identify the user being authorized. It can be
any field provided by the IDP upon
authorization
Further advanced configuration of the Platform SAML configuration can be

achieved by modification of the spring saml configuration file at
.../webapps/ROOT/WEB-INF/classes/saml/securityContext.xml. See Spring
documentation on how to do so; https://docs.spring.io/autorepo/docs/spring-
security-saml/1.0.x-SNAPSHOT/reference/htmlsingle/.
69
SAML User Management
Upon authorization by the IDP, a user may or may not exist within the platform. It is
necessary post authorization that a user exists within the platform configuration to
enable UI sessions to be created, maintained and destroyed. The platform provides
the ability to auto create SSO users who do not exist on initial login and provide
default permissions through user groups. This is maintained by the config parameter
CONTROL_SSO:DEFAULT.
pKey pValue
createUser true/false. If true; the user will be auto created on
first login
defaultGroup User Group to assign user to when created.

Multiple defaultGroup pKey rows can be present
to allow a created user to be assigned to multiple
user groups
70
Appendix H – CPU Affinity
KDB+ is typically licensed to run on a number of CPU cores. By default the q binary
will be run under taskset (Linux) or psrset (Solaris). On some Linux systems there is also
the option of running KDB+ under numactl (if enabled). This can be achieved by
adding the following to a custom install config (passed in via -p).
cpu-affinity-cmd=numactl --interleave=all --physcpubind=

kdb-cpu-affinity=0-9
dcd-cpu-affinity=0-9
NB. When running with numactl any process instances kicked off by Control or the
Daemon can only use all or a subset of the CPU cores defined by kdb-cpu-affinity
(Control) and dcd-cpu-affinity (Daemon).
If the process instance is configured to use cores outside of this range you will see
the following in the process instance log file (delta-
data/DeltaControlData/logdir/<process.instance.log>)
libnuma: Warning: cpu argument X out of range
For this reason it is recommended that the auto-configure-instance-taskset values

match those of dcd-cpu-affinity and kdb-cpu-affinity (see above) or use a subset
e.g. auto-configure-instance-taskset=0-3
The install config options above will result in Control being started using numactl as
follows:
numactl --interleave=all --physcpubind=0-9 q q/centralconfig.q_ …
The Daemon will also be run under numactl and the CPU core set is configured via
dcd-cpu-affinity above.
numactl --interleave=all --physcpubind=0-9 ./run.sh
71
Appendix I – Control Package Import
Control is a KDB+ database process which contains configuration and code. The
contents of Control are imported from a set of XML files delivered in the TGZ
packages within the release bundles. Importing the XML files into Control causes
their contents to be converted into Control entities which are stored in the
database. This import can be initiated via the Control Web UI or using the install
script (Auto Import).
Auto Package Import
As outlined in the single server deploy above, installing the Platform involves an
import step at the end. The process for importing packages is automated via the
install script but it is useful to understand how it works. The installation process for a
package which contains Control entities is defined below.
1. The package contents are copied into the kxinstall/packages directory.

NB This is where all Control based packages are deployed.
2. The path to the current version of each package is updated by changing the
package’s version environment variable in delta.profile
3. The deployed package path is added to DELTA_IMPORT_PACKAGES which
are imported when Control is started in import mode
4. Import mode is enabled (DELTA_AUTO_IMPORT=YES)
5. Control is started in import mode
6. Control creates a check point of its current state
7. The package contents are imported into Control.
8. Control is shutdown
72
Using the Platform’s Stream package the steps above are outlined in an upgrade
from version 4.0.3 to version 4.1.0 of the Platform.
1. The package is copied into the kxinstall/packages directory beside the

existing package as follows:
$ cd ~/kxinstall/packages/
$ ls -1
DeltaStream_4_0_3
DeltaStream_4_1_0
2. The delta.profile is updated so that the DELTASTREAM_VERSION 4_1_0 instead

of 4_0_3.
export DELTASTREAM_VERSION=4_1_0
export DELTASTREAM_HOME=${DELTA_PACKAGE_HOME}/DeltaStream_${DELTASTREAM_VERSION}
As a result after sourcing the delta.profile (part of Control start up) the
DELTASTREAM_HOME variable now gives the PATH to the new 4_1_0 package.
$ . delta.profile
$ echo $DELTASTREAM_HOME
/home/ddempsey/kxinstall/packages/DeltaStream_4_1_0
3. The delta_user.profile is updated to include the list of installed packages

which are due for import DELTA_IMPORT_PACKAGES. This delta_user.profile is
sourced by the startDeltaControl.sh script after the delta.profile hence the
reason for making the change here. (Once the import is complete the
changes to this file are reverted)
export
DELTA_IMPORT_PACKAGES=${DELTASTREAM_HOME}:${ANALYST_HOME}:${HTML5DASHBOARDSEVAL_HOME}
4. The delta_user.profile is then updated to turn on import mode in Control. This is

done by setting DELTA_AUTO_IMPORT to YES.
export DELTA_AUTO_IMPORT=YES
5. Control is then started with import mode enabled via startDeltaControl.sh.
6. Control creates a check point of its current state.
$ cd ~/kxinstall/
$ ls -1 checkpoint/
checkpoint_108
7. Package contents are imported into Control.
$ cd ~/kxinstall/delta-data/DeltaControlData/logdir/
$ grep "finished importing packages" DeltaControl.log
73
### normal ### (10381): finished importing packages ### ,"DeltaCore:package/"

### normal ### (10381): finished importing packages ###
("DeltaStream:/home/ddempsey/kxinstall/packages/DeltaStream_4_0_3";"Analyst:/..
8. Control is shutdown.
Import Environment Variables
The variables which control the auto import as seen above are:
Post Control for Kx Version 3.0.1
DELTA_AUTO_IMPORT
When set to NO, Control starts up as normal and does not attempt to import any
packages. When DELTA_AUTO_IMPORT is set to YES Control imports each package
on the DELTA_IMPORT_PACKAGES list in turn.
DELTA_IMPORT_PACKAGES
List of package home directories. All packages whose locations are listed on this
Environment variable will be imported into Control when DELTA_AUTO_IMPORT = YES.
DELTA_PACKAGES_PATH
Dictates where packages can be saved to. Anything that attempts to save outside
those locations will be rejected.
Pre Control for Kx Version 3.0.1
DELTA_PACKAGES_DIR
List of package locations which are searched when DELTA_AUTO_IMPORT is

enabled.
DELTA_STARTUP_PACKAGES
List of package names to search for when DELTA_AUTO_IMPORT is enabled.
74
Package Configuration
In order for a package to be able to import into Control it must contain the
following:
File Description
Control Entities XML files which define a set of Delta Control entities (instance,
task, configparam etc)
Package cfg and _export.cfg files which defined the set of entities which
Manifest Files should be imported into Control. Each entry in the .cfg file
corresponds to a XML file in the package.
NB if an entity exists as and XML file but is not defined in the .cfg
file it will not be imported into Control
Package _permissions.xml file which defines the permissions for each of the
Permissions entities when imported into Control
The files above are the bare minimum of content required for a package to be
imported into Control. In order for a package to be deployed using the install script it
requires additional content which is outside of the scope of this document.
75
Appendix J – Platform Support Scripts
Post 4.1.0 the Platform and Eval bundles will contain a pair of platform support
scripts.
Script Description
checkHost.sh Run checks on the host including Hostname/ FQDN. Check for
RPM prerequisites and required binaries
validateCerts.sh Run openssl client/server and validate the SSL certificates
provided.
checkEnv.sh Check the environment for log file errors and grab information
such as process lists and taskset values.
checkHost
When the bundle installer (install.sh) runs you will see the following output:
+-----------------------------------------------------------+
+-----------------------------------------------------------+
This tells you that the installer found and ran the checkHost.sh script and that it ran
successfully will all validation steps passed.
76
validateCerts
If the platform is deployed with TLS enabled a script call validateCerts.sh will run post
deploy. This script runs the openssl client and server and provides the output to a log
file in platform-info/logs/openssl-client.log. See sample output below:
+----------------------------------------------------------+
Validate SSL Certificates
+----------------------------------------------------------+
Running SSL Certificate Validation Script
[validateCerts.sh
-c /home/ddempsey/kxinstall/delta-bin/config/tls-certs
-l platform-info/logs]
+===========================================================+
Certificate Directory [-c] set to [/home/ddempsey/kxinstall/delta-bin/config/tls-
certs]
Log Directory [-l] set to [platform-info/logs]
============================================================
== validateCerts.sh [1.0] ==
============================================================
+----------------------------------------------------------+
[ddempsey@control-a.fd.com]
[Fri 19 Jan 14:37:44 UTC 2018]
[validateCerts.log]
+----------------------------------------------------------+
Check OpenSSL Installed
+----------------------------------------------------------+
Found OpenSSL [/usr/bin/openssl]
Version [OpenSSL 1.0.1e-fips 11 Feb 2013]
+----------------------------------------------------------+
Get SSL Certificates
+----------------------------------------------------------+
Using certificate [/home/ddempsey/bundles/4.1.0/GA/PlatformKx-4.1.0-
RHEL70/scripts/server-crt.pem]
RHEL70/scripts/server-key.pem]
RHEL70/scripts/ca.pem]
+----------------------------------------------------------+
Run OpenSSL Server
+----------------------------------------------------------+
Starting SSL Server on port [44330]
[openssl s_server -accept 44330 -www
-key /home/ddempsey/bundles/4.1.0/GA/PlatformKx-4.1.0-RHEL70/scripts/server-
key.pem
-cert /home/ddempsey/bundles/4.1.0/GA/PlatformKx-4.1.0-RHEL70/scripts/server-
crt.pem
-CAfile /home/ddempsey/bundles/4.1.0/GA/PlatformKx-4.1.0-RHEL70/scripts/ca.pem]
Started OpenSSL Server [PID:12777]
+----------------------------------------------------------+
Run OpenSSL Client
+----------------------------------------------------------+
[openssl s_client -connect localhost:44330 < /dev/null > platform-
info/logs/openssl-client.log]
depth=1 C = US, ST = New York, L = Brooklyn, O = Example Brooklyn Company, CN =
examplebrooklyn.com
verify error:num=19:self signed certificate in certificate chain
verify return:0
DONE
+----------------------------------------------------------+
Kill OpenSSL Server
+----------------------------------------------------------+
Killed OpenSSL Server [PID:12777]
+----------------------------------------------------------+
Finished [validateCerts.sh].
77
checkEnv.sh
Once the deploy is complete the checkEnv script will be run to gather information
about the deploy. You will see the following output:
+----------------------------------------------------------+
Finished [checkEnv.sh].
+-----------------------------------------------------------+
Script Output
The scripts above write output to the following directory scripts/platform-info. Once
the deploy is complete the output from the scripts is tarred up along with the install
log files into a TGZ such as the one below (KX-INSTALL-LOGS-20180119-143407.tgz):
$ ls
install.log install.sh KX-INSTALL-LOGS-20180119-143407.tgz packages README.txt
scripts tmp
Should a deploy fail this TGZ can be sent to FD Support to be analysed.
The contents of the output directory are as follows.
Directory Description
platform-info/logs Output from the Platform Support scripts.
platform-info/<host>/env-info Environment information collected by checkEnv.sh
platform-info/<host>/host-info Host information collected by checkHost.sh
Reporting Issues
Should you experience problems with your environment post deploy you can run the
Platform support scripts independently of the install to collate the relevant host and
environment info. The scripts should be run on each affected host in the deploy and
the resulting TGZ should be sent with a detailed description of the issue to the FD
Support alias.
The scripts can be run using the wrapper script as follows:
$ cd PlatformKx-4.1.0-RHEL70/scripts/
./runSupportScripts.sh
+----------------------------------------------------------+
Current install location [~/kxinstall]:
This will run the chekHost, checkEnv and validateCerts (if applicable) and generate
a time stamped TGZ named something like this KX-SUPPORT-LOGS-20171219-
152627.tgz.
78
Appendix K – Process Instance Configuration
Process instances are configured via the delta.instance.profile (delta-

bin/delta.instance.profile) which is written by the install script. The
delta.instance.profile defines the Host, Port and Taskset values for each process
instance contained within the Platform.
The values given for Host, Port and Taskset can be defined in several ways. The
options are detailed below.
Auto Configuration
The following install script options are used to automatically configure the process
instances.
Install Option Value Default Details

Type
auto-configure-instance- Port 3000 This is the seed value for all
portstart process instances
configured by the install
script. Each instance will
have a port which is an
increment of this value i.e.
3000, 3001, 3003 etc.
auto-configure-instance- hostname Install server The host name which all
hostname-a hostname process instances ending in
_a will be assigned. Delta
Stream is shipped with 2
copies of all tasks,
instances and workflows.
This is to allow for a resilient
(A/B) configuration across 2
servers.
auto-configure-instance- hostname Install server The host name which all
hostname-b hostname process instances ending in
_b will be assigned. If
deploying a and b on the
same host then each
instance in the pair will
have different port values,
if deployed on different
hosts each instance will
have the same port value.
auto-configure-instance- Taskset NONE Taskset CPU list which will
taskset CPU list be applied to all processes
in the
delta.instance.profile. The
syntax is the same as that
79
which would be used when

specifying a CPU mask with
the –c option (see man
taskset).
CSV File Configuration
A csv file containing configuration details for process instances can be used as an
alternative to automatic configuration.
The CSV file should be in the following format:

INSTANCE-NAME,HOST,PORT,TASKSET
For example if we wished to configure an instance called “ds_ms_a” to run on host

“delta1.firstderivatives.com”, listening on port “4000” and being bound to CPU cores
“1-4” we would put the following in the instances CSV file.
ds_ms_a,delta4.firstderivatives.com,4000,1-4
The CSV file is passed into the install script using the -i command line option. e.g.
./installDetaXML.sh -i instances.csv -p install.config
Once the install completes you should see the following in the delta.instance.profile.
grep ds_ms_a ~/delta/delta-bin/delta.instance.profile

export ds_ms_a_HOST="delta4.firstderivatives.com"
export ds_ms_a_PORT="4000"
export ds_ms_a_TASKSET="1-4"
Any instances which are not specified in the CSV file will have their Host, Port and
Taskset options configured via the Auto Configuration settings above:
export ds_ms_a_HOST="delta4.firstderivatives.com"
export ds_ms_a_PORT="4000"
export ds_ms_a_TASKSET="1-4"
export dm_rte_bridge_a_HOST="delta1.firstderivatives.com"
export dm_rte_bridge_a_PORT="3000"
export dm_rte_bridge_a_TASKSET=""
80
Appendix L – Install Script Command Line

Options
This section describes the command line options which are available in the
installDeltaXML.sh script. For a complete list run:
./installDeltaXML.sh -?
Option Argument Required Description

-a NO Always upgrade/overwrite package without prompting user
-c Directory Package directory
-d NO Debug mode. Write Debug logging to install log file
-e Directory License directory
-i Instance CSV File Load Instance CSV configuration file
-k KDB+ Version Default KDB+ version i.e. -d 2.6.0. Used when more than
one version of KDB+ are being installed
-l NO Print a list of the installed package versions
-m YES Name of a single package to deploy
-n NO Don't get a list of ports which are in use via netstat
-o YES Comma separated list of environment package SVN URLs
-p Install Profile Load profile file for install
-q NO Quiet mode, reduces screen output. (Requires install
profile)
-r NI Reinstall
-s NO Deploy with TLS Encryption Enabled
-t NO No taskset. Do not set taskset option during install
-u NO Skip clean-up of tmp install directory
-v NO Print version and exit
-w NO Write install profile, Writes install profile based on
what is entered during the installation. Install profile
can then be used with the -p option to repeat the
installation.
-x NO Clean deploy
? NO Print list of command line options
81
Appendix M – Install Configuration File Options
This section contains the complete list of options which can be added to an
installation configuration file to be passed into the install script using the (-p)
command line options.
Install Location Options
Install Config Option Values Details

delta-install-dir Path Provides a non-default location for the
installation directory.
delta-bin-dir Path Non default location for delta-bin
directory.
delta-data-dir Path Non default location for delta-data
directory.
delta-package-install-dir Path Non default location for package
installation directory
delta-dev-package-install-dir Path Non default location for dev package
installation directory
delta-log-dir Path Non default location for Install Script
log directory
delta-package-dir Path Non default location for the directory
which contains the Delta installation
packages.
Delta Control Installation Options

delta-install-type 1 (Control only) The installation type defines the type of
2 (Daemon only) Delta Control installation being
3 (Control and performed.
Delta Daemon)
delta-control-clustering 1 (Enabled) Enable Control clustering configuration
0 (Disabled)
delta-control-master-hostname Hostname Hostname of Master Control
delta-control-master-port Port Port of Master Control
delta-control-slave-hostname Hostname Hostname of Slave Control
delta-control-slave-port Port Port of Slave Control
delta-control-use-ldap 1 (Enabled) When enabled Control will use LDAP for
0 (Disabled) user authentication.
NB this configuration requires a custom
LDAP configuration file to be present in
the following location in order to start
Delta Control: ${DELTA_CONFIG}/LDAP_EX.txt
master-dc 1 (YES) Set to 1 (YES) if this config Is for the
0 (NO) master Control instance in a single host
Control cluster
CPU Affinity Options (Control / Daemon)

cpu-affinity-cmd Affinity Use an affinity command other than taskset
Command (linux) psrset (solaris). Examples include
numactl
dcd-cpu-affinity CPU Cores CPU Cores which Daemon will bind to
kdb-cpu-affinity CPU Cores CPU Cores which Control will bind to
82
KDB+ Options

install-32bit-kdb 1 (Enabled) Install 32 Bit KDB+ on a 64 Bit host
0 (Disabled)
skip-kdb-license-validation 1 (Enabled) When enabled the install script will
0 (Disabled) Skip license check when DC is
installed on KDB+
elastic-kdb-license 1 (Enabled) Install with elastic KDB+ license
0 (Disabled) file (kc.lic)
license-dir Directory Directory which contains KDB+ and
Delta License files
App Server Options

install-dashboard-nodc 1 (Enabled) Install Delta Dashboards into a
0 (Disabled) standalone Tomcat deploy which does
not connect to a Delta Control
instance.
tomcat-install-type 1 (Development Set the JVM Java Heap Size.
Install) Development install: 2560m
2 (Production Production install: 5120m
Install)
tomcat-add-cors-filter 1 (Enabled) Enable the Cors filter in the tomcat
0 (Disabled) installation.
tomcat-keystore-file Path Path to Java RSA Keystore file for
Tomcat SSL deploy
tomcat-keystore-password String Keystore RSA password
app-server-install-type 1 (HTTP) Set the configuration for HTTP, HTTPS
2 (HTTPS) with a certificate in the tomcat
3 (HTTPS with install and HTTP Offloaded where a
SSL Offloaded to netscaler handles the SSL traffic.
Netscaler))
dashboards-use-captcha 1 (Enabled) Enable CAPTCHA on dashboard login
0 (Disabled)
dashboard-install-type 1 (Red 5) Select the messaging type for flex
2 (BlazeDS) dashboards
app-server-jvm-initial-memory Integer Initial and minimum heap size for JVM
(Megabytes) Default 1280
app-server-jvm-max-memory Integer Maximum heap size for JVM.
(Megabytes) Default 2048
production-tomcat-install 1 (Enabled) Set Maximum heap size for JVM to 8192
0 (Disabled) (Megabytes)
app-server-beans-buffer-size-limit Integer Adjust the value of bufferSizeLimit
in App Server server-beans.xml
app-server-allow-from-uri URI White listed URIs when
antiClickJackingOption is enabled in
Tomcat. Format is
[URI1][URI2][URI3]
tomcat-connection-timeout Integer Modify default connection timeout
(20000) in tomcat connectors
83
TLS Encryption Configuration Options

tls-encryption-enabled 1 (Enabled) Install with TLS Encryption enabled without

0 (Disabled) prompting at install time
ssl-server-cert-file File Path Location of Server certificate file for TLS
encryption
ssl-server-key-file File Path Location of Server key file for TLS
encryption
ssl-ca-cert-file File Path Location of Certificate Authority file for
TLS encryption
tls-include-client-certificate 1 (Enabled) Include the client certificate file (ssl-

0 (Disabled) client-cert-file) when deploying with TLS.
Default disabled
ssl-client-cert-file File Path Location of Client certificate file for TLS
encryption
overwrite-tls-certificate 1 (Enabled) Overwrite existing TLS certificates.
0 (Disabled) Default 0 (Disabled)
Auto Instance Configuration Options

auto-configure-instance-portstart port This is the seed value for all process

instances configured by the install
script. Each instance will have a port
which is an increment of this value i.e.
3000, 3001, 3003 etc.
auto-configure-instance-hostname-a hostname The host name which all process instances
ending in _a will be assigned. Delta
Stream is shipped with 2 copies of all
tasks, instances and workflows. This is to
allow for a resilient (A/B) configuration
across 2 servers.
auto-configure-instance-hostname-b hostname The host name which all process instances
ending in _b will be assigned. If
deploying a and b on the same host then
each instance in the pair will have
different port values, if deployed on
different hosts each instance will have
the same port value.
auto-configure-instance-taskset taskset Taskset CPU list which will be applied to
CPU list all processes in the
delta.instance.profile. The syntax is the
same as that which would be used when
specifying a CPU mask with the –c option
(see man taskset).
auto-configure-missing-instances 1 (Enabled) Automatically configure process instances
0 (Disabled) which are not defined in instance CSV.
Default 1 (Enabled)
app-server-hostname-a hostname Host to run ds_appServer_a
(delta.instance.profile)
app-server-hostname-b hostname Host to run ds_appServer_b
app-server-hostname-taskset taskset Taskset value for ds_appServer_a/
CPU list ds_appServer_b instances
84
Package Import Options

delta-package-auto-import 1 (Enabled) 1 (Enabled) - Run the auto-import of XML

0 (Disabled) packages without prompting the user.
0 (Disabled) - Do not run the auto-import,
continue without prompting the user.
always-import-on-slave 1 (Enabled) Default (Disabled)
0 (Disabled) When enabled it allows auto package import
on Slave Control.
max-import-check-retries Integer By default the install script will check up
to 100 times if the auto import has
completed. There is a 20 second interval
between each check.
General Options
accept-defaults 1 (Enabled) When enabled (1) the user will not be

0 (Disabled) prompted for package environment variables,
the script will accept the default value
where it exists.
fail-on-duplicate-port 1 (Enabled) Fail if a duplicate host/port value is
0 (Disabled) detected in a user supplied instances CSV
file.
prompt-when-ports-in-use 1 (Enabled) Prompt the user for input when a port the
0 (Disabled) deploy is attempting to use is currently in
use
debug-mode 1 (Enabled) Print debug info to the log file
0 (Disabled)
quiet-mode 1 (Enabled) Reduces screen output
0 (Disabled)
no-prompt 1 (Enabled) Set always-overwrite, always-upgrade,
0 (Disabled) accept-defaults, delta-package-auto-import
to 1. Set prompt-when-ports-in-use to 0
skip-port-check 1 (Enabled) Don't get a list of ports which are in use
0 (Disabled) via netstat
skip-cleanup 1 (Enabled) Skip removal of tmp directories during
0 (Disabled) cleanup
no-taskset 1 (Enabled) No taskset. Do not set taskset option during
0 (Disabled) install
tmp-dir Absolute By default the install script unpacks all
path installation packages in the /tmp partition
before copying their contents to the install
directory.
This config option allows the script to use
a different location as the tmp package
directory.
pre-install-script Path to Bash or Perl script to execute before
script installing packages.
NB script name must end in .sh or .pl
script must exit with 0 or 1
post-install-script Path to Bash or Perl script to execute after
script installing packages.
NB script name must end in .sh or .pl
script must exit with 0 or 1
strict-fqdn-check 1 (Enabled) When enabled use strict checks to get FQDN
0 (Disabled) of host from either hostname or /etc/hosts
always-use-cp 1 (Enabled) Always use “cp” binary to copy packages
0 (Disabled) instead of rsync
skip-analyst-lib-check 1 (Enabled) Skip the check for Analyst library
0 (Disabled) dependencies
skip-etc-hosts-check 1 (Enabled) Skip check of /etc/hosts for IP/FQDN
0 (Disabled) combination
skip-env-dir-creation 1 (Enabled) Do not create directories specified as ENV
0 (Disabled) variables in package install config files
startup-workflows-file Path to file Copy workflows file into
${DELTA_CONFIG}/startup_workflows.txt
85
Package Options
always-upgrade 1 (Enabled) Do not prompt when attempting to

0 (Disabled) upgrade and existing package
always-overwrite 1 (Enabled) Always overwrite package version
0 (Disabled) which is already installed
without prompting
install-package-list Comma Comma separated list of Delta
separated Installation product packages
list (e.g. KDBPlus,
DeltaControl,DeltaStream). When
specified the install script will
only add packages listed to the
installation list.
The packages must exist in the
install script package arrays or
the custom solution / environment
lists below.
custom-solution-package-list Comma Comma separated list of solution
separated packages which do not already
list exist in the install script
package arrays.
This config option can be used to
add custom solution packages to
installation list.
Useful for client specific
packages which are not listed in
the install script.
custom-environment-package-list Comma Comma separated list of
separated environment configuration
list packages which do not already
exist in the install script
package arrays.
This config option can be used to
add custom environment
configuration packages to
installation list.
Useful for client specific
packages which are not listed in
the install script.
delta-exclude-packages Comma Comma separated list of product
separated packages to exclude from
list installation. Even if the
packages are present in the
package directory they will be
ignored by the install script.
Example:
delta-exclude-
packages=DeltaStream,DeltaEqEval,
Tomcat
environment-package-import-list Comma Comma separated list of
separated environment package.cfg files.
list The packages these files describe
will be added to the list of
packages to be imported when
Delta Control does an auto import
on a package deploy. The .cfg
files must exist inside packages
in the DELTA_PACKAGE_HOME
directory.
delta-env-package-import 1 (Enabled) If enabled automatically add the
0 (Disabled) packages from the environment-
package-import-list list to the
list of packages to be imported
when Delta Control does an auto
import.
If disabled and environment-
package-import-list is not blank
the script will prompt the user.
86
env-package-urls Comma Comma separated list of URLs for

separated environment packages to be
list checked out from SVN by the
install script. All packages in
this list will be checked out to
the $DELTA_DEV_PACKAGE_HOME
(<install-dir>/dev_packages)
directory. If all packages share
the same base URL i.e. they are
from the same repo, the base url
can be specified using the env-
package-base-url and the
remaining SVN dir structure can
be placed in the env-package-urls
string.
env-package-base-url URL Base URL for environment
packages. This string will be
prepended to all urls in the env-
package-urls list above and the
result must form a valid SVN
location.
dev-package-urls Comma Comma separated list of URLs for
separated development packages to be
list checked out from SVN by the
install script. All packages in
this list will be checked out to
the $DELTA_DEV_PACKAGE_HOME
(<install-dir>/dev_packages)
directory. If all packages share
the same base URL i.e. they are
from the same repo, the base url
can be specified using the dev-
package-base-url and the
remaining SVN dir structure can
be placed in the dev-package-urls
string.
dev-package-base-url URL Base URL for development
packages. This string will be
prepended to all urls in the dev-
package-urls list above and the
result must form a valid SVN
location.
dc-package-url URL URL for Delta Control package
when installing directly from
SVN. (Please note this does not
provide the Docgen or Delta
Control Daemon and should only be
used for dev purposes)
local-package-dirs Comma Comma separated list of dirs
separated which contain install packages
list which are in unzipped directories
read-package-portstart-env When enabled the install script
will read PORTSTART environment
variables which are present in a
packages install config. These
variables are no longer used in
Stream from 3.0.0 onwards.
Ignore-os-package-validation 1 (Enabled) Do not attempt to validate
0 (Disabled) packages in the install list
against the host OS
fail-on-unmatched-os-specific-package 1 (Enabled) Fail installation if we cannot
0 (Disabled) match a package to the host OS
web-node 1 (Enabled) Automatically exclude all
0 (Disabled) packages apart from Control,
Tomcat and Web Packages
kdb-node 1 (Enabled) Automatically exclude all web
0 (Disabled) packages and Tomcat.
87
Package Update Options

reset-admin-password 1 (Enabled) If an install package contains an Administrator

0 (Disabled) user reset its password to the default
(password) before importing into Delta Control.
admin-conn-password Encrypted If an installation package contains dashboard
connection connections the password in each connection XML
password file will be updated to the admin-conn-password
prior to the package being imported into Delta
Control
admin-user-password Encrypted user If an installation package contains users the
password password in each user XML file will be updated
to the admin-user-password prior to the package
being imported into Delta Control
88

Developers

Uploaded by

Copyright:

Available Formats

Developers

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Developers

Uploaded by

Copyright:

Available Formats

Kx Platform Deployment Guide

European Office (UK): +44 28 3025 2242

Sales Email: info@firstderivatives.com

About this document

2. Non-clustered Control with separate Web Host .................................................... 47

To install the KxPlatform bundle you will need the following:

For all Software and Licensing requests please contact support@firstderivatives.com

 Nexus User Account

 SCP Client (WinSCP)

 Target Deploy Server running:

Required Libraries - Analyst

RPM (RHEL / Centos 6.5+) RPM (RHEL / Centos 7.0+) Library

Required Linux Binaries

RPM (RHEL / Centos 6.5+) RPM (RHEL / Centos 7.0+) Binary

gawk-3.1.7-10.el6.x86_64 gawk-4.0.2-4.el7.x86_64 awk

net-tools-1.60-110.el6_2.x86_64 hostname-3.13-3.el7.x86_64 domainname

Required Third Party Software

 Java Runtime Environment 1.8

Dashboards PDF Viewer

Dashboards for Kx provide the ability to convert a dashboard in a web browser to a

10.190.1.232 kdbdev.firstderivatives.com kdbdev

The FQDN value written into the failover.csv is determined as follows:

1. Running the hostname command to check if it returns the FQDN

Port Process Description Access

Downloading the Release Bundle

To download the release bundles navigate to the Nexus Download URL

RHEL6 deploy download:

RHEL7 deploy download:

Deploying the Release

Transferring Release to Deployment Host

Once the tarball is unpacked the result will be a directory called:

Running the Installer

Configuring Single Node Deploy:

Configuring Single Host Deploy:

Configuring Single Host Deploy:

CPU Affinity (taskset)

Number of [Licensed KDB+] [CPU cores] [Max: 10] : 10

Please enter location of a kx license file (k4.lic) [dir] : /home/estuart/licenses

Interacting with the Deploy

Inside this dir there are 4 main sub directories

checkpoint Control checkpoints which are point in time snapshots of a

Tomcat log files can be found at the following location

# Custom location for delta-data dir

startDeltaControl.sh Starts Control process

Login using the following credentials:

Login using the username and password:

Restarting Single Host Deploy

$ ps -ef | grep $USER/kxinstall | grep -v grep

$ ps -ef | grep $USER/kxinstall | grep centralconfig

$ ps -ef | grep $USER/kxinstall | grep DeltaDaemonServiceMain

$ ps -ef | grep $USER/kxinstall | grep apache

A patch release consists of a subset of the platform constituent packages

Patch releases are detailed on the Kx Release Information page:

A Major or GA release consists of a new version of all constituent packages which

Major releases are detailed on the Kx Release Information page:

$ tar -xvzf PlatformKx-4.0.3-RHEL70-GA.tgz

$ tar -xvzf PlatformKx-4.0.3-RHEL70-P1.tgz

Upgrades to an existing deploy are performed by downloading the latest Patch or

Pre upgrade steps