Page History
...
Installation, updates and upgrades are performed using the .tar.gz/.zip installer installation archives provided for the initial installation of newer releases.
- JS7 - Installation instructions apply.
- For environments with a larger number of JOC Cockpit instances the update, upgrade and patch processes can be automated in a number of ways:
- Users can use their preferred tools such as Ansible®, Puppet®, Chef®.
- Users can apply the JOC Cockpit Installer Installation Script that is described in this article either standalone or in combination with such tools.
...
- Rollout of JS7 JOC Cockpit is considered critical as the software allows jobs to be executed on a larger number of servers.
- Attention should be paid to the integrity of the sources for JS7 component downloads.
- This includes intermediate devices on which JS7 software installers are stored in a user's environment.
- One option is to run the JOC Cockpit Installer Installation Script from
sudo
and to use the digest functionality that compares the script to a hash value stored with thesudoers
file.
- The solution for updating, upgrading and patching the JS7 JOC Cockpit is based on shell scripting by design
- to provide readability and to rely only on OS commands,
- to prohibit the use of any 3rd-party components and additional dependencies that require code to be executed on the machines that run the JOC Cockpit.
- The JOC Cockpit Installer Installation Script can be integrated in a number of ways:
- by running one's own SSH script on top of the JOC Cockpit Installer Installation Script,
- by use of tools such as Ansible®, Puppet® that make use of an SSH Client,
- by use of JS7 workflow automation as explained below.
- It is recommended that a separate Standalone Controller and Agent are used for deployment purposes, for details see JS7 - Deployment.
- Access to the Controller and Agent for rollout should be securely managed.
JOC Cockpit
...
Installation Script
The JOC Cockpit Installer Installation Script is provided for download and can be used to automate updates, upgrades and patches of JS7 JOC Cockpits.
...
Download
Find the JOC Cockpit Installer Installation Script for download from JS7 - Download.
Usage
Invoking the JOC Cockpit Installer Installation Script without arguments displays the usage clause:
...
--setup-dir
- Specifies the directory in which the installer for the JOC Cockpit should be extracted. This is not the JOC Cockpit installation directory but the directory that holds installer files.
--response-dir
- Specifies the directory that holds a copy of the JOC Cockpit installer
joc_install.xml
response file and optionally related files. This file is available after extraction of the installer tarball and specifies options for installation of the JOC Cockpit. Files in the response directory are copied to the working directory specified with the--setup-dir
option. and are applied when invoking the installer by./setup.sh -u joc_install.xml
, see JS7 - JOC Cockpit - Headless Installation on Linux and Windows. - Users should keep their copy of the response file and specify the directory with this command line option. Response files can be re-used within the same minor release of the JOC Cockpit, for example when updating from release 2.2.1 to 2.2.4. When updating, for example, from release 2.2.x to 2.3.x it is recommended to check from the installer tarball if a newer version of the file is available.
- Users should note that the response file can hold references to a license file and to a JDBC Driver .jar file. The JOC Cockpit setup is executed from the working directory specified with the
--setup-dir
option. Paths in thejoc_install.xml
response file can be used relative to the working directory, for example usingsos.pem
for a license file without specifying a directory if the license file is available in the response directory as it will be copied to the working directory.
- Specifies the directory that holds a copy of the JOC Cockpit installer
--release
- Specifies a release number such as 2.3.1 for download from the SOS web site if the
--tarball
option is not used.
- Specifies a release number such as 2.3.1 for download from the SOS web site if the
--tarball
- Optionally specifies the path to a .tar.gz file that holds the JOC Cockpit installation files. If this option is not used the installer tarball will be downloaded from the SOS web site for the release indicated with the
--release
option. - Download is performed with
curl
which takes account ofhttp_proxy
andhttps_proxy
environment variables and the relevant settings from a.curlrc
file.
- Optionally specifies the path to a .tar.gz file that holds the JOC Cockpit installation files. If this option is not used the installer tarball will be downloaded from the SOS web site for the release indicated with the
--home
- Specifies the directory in which the JOC Cockpit should be installed.
- This option overwrites the JOC Cockpit installation directory specified in the
joc_install.xml
response file with the<installpath>
element.
--data
- Specifies the directory in which the JOC Cockpit installs configuration files. The configuration directory is accessible from the
jetty_base
symlink in the JOC Cockpit home directory. - This option overwrites the JOC Cockpit configuration directory specified in the
joc_install.xml
response file with the<entry key="jettyBaseDir" value="..."/>
element.
- Specifies the directory in which the JOC Cockpit installs configuration files. The configuration directory is accessible from the
--user
- The JOC Cockpit
joc_install.xml
response file holds therunningUser
setting that optionally specifies the user account of the JOC Cockpit daemon service. This setting allows to take precedence over the response file setting. - The user account specified will be used for the JOC Cockpit installation.
- The JOC Cockpit
--patch
- A patch is identified by the release number to which it is applied which is specified with the
--release
option and by- the JOC Cockpit security level: low, medium, high,
- a sequential number such as patch-1, patch-2.
- A patch is specified as
--patch=low.patch-1
,--patch=low.patch-2
,--patch=medium.patch-1
etc.
- For JOC Cockpit patches are consolidated, i.e. patch-2 includes any patches of patch-1.
- Patches are downloaded from the SOS web site if the
--tarball
option is not used. - Patches are added to the JOC Cockpit's
JETTY_BASE/webapps/joc/WEB-INF/classes
directory. When updating JOC Cockpit later on then theclasses
sub-directory will be emptied. - If a backup directory is specified then a JOC Cockpit's existing installation directory will be added to a .tar.gz file in this directory.
- A patch is identified by the release number to which it is applied which is specified with the
--license-key
- Optionally the path to a license key file is specified. Customers with a Commercial License receive the license key file from SOS in .pem or .crt format.
- For details see JS7 - How to apply a JS7 License Key.
- This option is an alternative to specifying the license key file with the
joc_install.xml
response file, see--response-dir
option.
--license-bin
- Optionally the path to the
js7-license.jar
binary file is specified that includes code that is available for use with a Commercial License only, see JS7 - How to apply a JS7 License Key. - Should this argument be omitted and a license key file be specified with the
--license-key
option then the binary file is downloaded from the SOS Web Site, see JS7 - Download. - This option is an alternative to specifying the license key file with the
joc_install.xml
response file, see--respons-dir
option. If the response files specifies a license key then the binary file for licensed code is automatically installed.
- Optionally the path to the
--backup-dir
- If a backup directory is specified then an existing JOC Cockpit's installation directory will be added to a .tar.gz file in this directory.
- File names are created according to the pattern:
backup_js7_joc.<hostname>.<release>.<yyyy>-<MM>-<dd>T<hh>-<mm>-<ss>.tar.gz
- For example:
backup_js7_joc.centostest_primary.2.3.1.2022-03-19T20-50-45.tar.gz
--log-dir
- If a log directory is specified then the installer script JOC Cockpit Installation Script logs information about processing steps to a log file in this directory.
- File names are created like this:
install_js7_joc.<hostname>.<yyyy>-<MM>-<dd>T<hh>-<mm>-<ss>.log
- For example:
install_js7_joc.centostest_primary.2022-03-19T20-50-45.log
--exec-start
- This option can be used should JOC Cockpit be started after installation. For example, when using systemd then the option
--exec-start=
"StartService"
will start the JOC Cockpit service provided that the related systemd service has been created manually or by use of the--make-service
switch. Alternatively users can specify individual commands, for example--exec-start="sudo systemctl start js7_joc"
. - For systemd service files see the JS7 - systemd Service Files for automated Startup and Shutdown with Unix Systems article.
- This option is an alternative for use of the
-restart
switch that starts the JOC Cockpit from its Start Script. If specified this option overrules the--restart
switch.
- This option can be used should JOC Cockpit be started after installation. For example, when using systemd then the option
--exec-stop
- This option can be used should JOC Cockpit be stopped before installation. For example, when using systemd then the option
--exec-stop="StopService"
will stop the JOC Cockpit service provided that the related systemd service has been created manually or by use of the--make-service
switch. Alternatively users can specify individual commands, for example--exec-stop="sudo systemctl stop js7_joc"
. - For systemd service files see the JS7 - systemd Service Files for automated Startup and Shutdown with Unix Systems article.
- This option is an alternative to use of the
-restart
switch that stops the JOC Cockpit from its Start Script. If specified this option overrules the--restart
switch.
- This option can be used should JOC Cockpit be stopped before installation. For example, when using systemd then the option
--return-values
- Optionally specifies the path to a file which return values will be added to in the format
<name>=<key>
. For example:log_file=install_js7_joc.centostest_primary.2022-03-20T04-54-31.log
backup_file=backup_js7_joc.centostest_primary.2.3.1.2022-03-20T04-54-31.tar.gz
- An existing file will be overwritten. It is recommended that a unique file name such as
/tmp/return.$$.$RANDOM.properties
is used. - A value from the file can be retrieved like this:
backup=$(cat /tmp/return.$$.$RANDOM.properties | grep "backup_file" | cut -d'=' -f2)
- Optionally specifies the path to a file which return values will be added to in the format
...
--deploy-dir
- Specifies the path to a deployment directory that holds configuration files and sub-directories that will be copied to the
<config>
folder. A deployment directory allows to manage central copies of configuration files such ashibernate.cfg.xml
,log4j2.xml
etc. - Use of a deployment directory has lower precedence as files can be overwritten by individual options such as
--properties
etc.
- Specifies the path to a deployment directory that holds configuration files and sub-directories that will be copied to the
--properties
- Specifies the path to a
joc.properties
file that will be copied to theJETTY_BASE/resources/joc
directory. While any file name can be used for the source file the target file name will bejoc.properties
.
- Specifies the path to a
--ini
- Specifies one or more *.ini files that include settings for the Jetty Servlet Container, for example http.ini, https.ini, ssl.ini. The files will be copied to the JOC Cockpit
JETTY_BASE/start.d
directory. For use with HTTPS connections the following settings in thessl.ini
file have to be adjusted:jetty.sslContext.keyStorePath
jetty.sslContext.keyStorePassword
jetty.sslContext.keyManagerPassword
jetty.sslContext.trustStorePath
jetty.sslContext.trustStorePassword
- The option takes a number of files as arguments that are separated by comma, for example:
--ini="/js7-deployment/ssl.ini,/js7-deployement/https.ini"
.
- Specifies one or more *.ini files that include settings for the Jetty Servlet Container, for example http.ini, https.ini, ssl.ini. The files will be copied to the JOC Cockpit
--title
- The title of the JOC Cockpit instance is displayed with its dashboard. It serves to distinguish JOC Cockpit instances operated as a cluster.
- This option has precedence over the respective setting specified in the
joc_install.xml
response file with the<entry key="jocTitle" value="..."/>
element.
--security-level
- The JOC Cockpit is operated in one of the security levels
low
,medium
,high
, see JS7 - Security Architecture. By default thelow
security level is used. - This option has precedence over the respective setting specified in the
joc_install.xml
response file with the<entry key="securityLevel" value="..."/>
element.
- The JOC Cockpit is operated in one of the security levels
--dbms-config
- Optionally specifies the path to a Hibernate configuration file that includes settings to access the JS7 - Database.
- This option has precedence over the respective setting specified in the
joc_install.xml
response file with the<entry key="hibernateConfFile" value="..."/>
element.
--dbms-driver
- Optionally specifies the path to a JDBC Driver .jar file that is used for access to the DBMS. See JS7 - Database to identify JDBC Drivers that ship with JS7.
- This option has precedence over the respective setting specified in the
joc_install.xml
response file with the<entry key="connector" value="..."/>
element.
--dbms-init
- Optionally specifies the point in time when database objects will be created:
byInstaller
: Database objects will be created during installation of JOC Cockpit.byJoc
: Database objects will be created on start-up of JOC Cockpit, for example when used for Containers.off
: Database objects will not be created. This assumes that users create database objects on their own before running JOC Cockpit. The JOC Cockpit installation tarball includes thedb
sub-directory that holds *.sql files for the respective DBMS that can be used to populate the JS7 - Database independently from installing JOC Cockpit.
- Optionally specifies the point in time when database objects will be created:
--http-port
- Specifies the HTTP port that the JOC Cockpit is operated for. This argument takes precedence over the port setting in the
joc_install.xml
response file. - Users are discouraged to enable both HTTP and HTTPS protocols as it undermines security to operate JOC Cockpit for both protocols.
- The port can be prefixed by the network interface, for example
joc.example.com:4446
. - When used with the
--restart
switch, the HTTP port is used to determine if JOC Cockpit is running.
- Specifies the HTTP port that the JOC Cockpit is operated for. This argument takes precedence over the port setting in the
--https-port
- Specifies the HTTPS port that the JOC Cockpit is operated for. This argument takes precedence over the port setting in the
joc_install.xml
response file. - Users are discouraged to enable both HTTP and HTTPS protocols as it undermines security to operate JOC Cockpit for both protocols.
- The port can be prefixed by the network interface, for example
joc.example.com:4448
. - Use of HTTPS connections requires additional settings, see
--ini
,--keystore
and--truststore
options. - When used with the
--restart
switch, the HTTPS port is used to determine if JOC Cockpit is running.
- Specifies the HTTPS port that the JOC Cockpit is operated for. This argument takes precedence over the port setting in the
--keystore
- Specifies the path to a PKCS12 keystore file that holds the private key and certificate for HTTPS connections to JOC Cockpit.
- Users are free to specify any file name, typically the name
https-keystore.p12
is used. The keystore file will be copied to the<home>/jetty_base/resources/joc
directory. - If a keystore file is made available then the JOC Cockpit's
<home>/jetty_base/start.d/ssl.ini
file has to hold a reference to the keystore location and optionally the keystore password. It is therefore recommended to use the--ini
option to deploy an individualssl.ini
file. The following settings are automatically updated in thessl.ini
file:jetty.ssl.host
: optionally specifies the network interface that is available from the--http-port
option provided that the port is prefixed with the network interface, for examplejoc.example.com:4446
.jetty.ssl.port
: specifies the HTTPS port that is automatically updated from the--http-port
option.jetty.sslContext.keyStorePath
: specifies the path to the keystore relative to the<home>/jetty_base/resources/joc
directory.
- Further settings in the
ssl.ini
file such as the keystore password have to be deployed from a copy of the file using the--ini
option. - Assigning a keystore for HTTPS connections disables HTTP access and enables HTTPS access only to JOC Cockpit. The same port is alternatively used for HTTP and HTTPS connections.
- For automating the creation of keystores see JS7 - How to add SSL TLS Certificates to Keystore and Truststore.
--keystore-password
- Specifies the password for access to the keystore. Use of a keystore password is required.
--keystore-alias
- If a keystore holds more than one private key, for example if separate pairs of private keys/certificates for server authentication and client authentication exist, then it is not determined which private key/certificate will be used. The alias name of a given private key/certificate is specified when the entry is added to the keystore. The alias name allows to indicate a specific private key/certificate to be used.
--truststore
- Specifies the path to a PKCS12 truststore file that holds the certificate(s) for HTTPS connections from JOC Cockpit to a Controller instance, LDAP server etc.
- Users are free to specify any file name, typically the name
https-truststore.p12
is used. The truststore file will be copied to the<home>/jetty_base/resources/joc
directory. - If a truststore file is made available then the JOC Cockpit's
<home>/jetty_base/start.d/ssl.ini
file has to hold a reference to the truststore location and optionally the truststore password. It is therefore recommended to use the--ini
option to deploy an individualssl.ini
file. The following settings are automatically updated in thessl.ini
file:jetty.sslContext.trustStorePath
: specifies the path to the truststore relative to the<home>/jetty_base/resources/joc
directory.
- Further settings in the
ssl.ini
file such as the truststore password have to be deployed from a copy of the file using the--ini
option. - For automating the creation of truststores see JS7 - How to add SSL TLS Certificates to Keystore and Truststore.
--truststore-password
- Specifies the password for access to the truststore. Use of a password is recommended as it is not primarily intended to protect access to the truststore. The password is intended to allow verification that truststore entries have been added using the same password.
--java-home
- Specifies the Java home directory that will be made available to JOC Cockpit from the
JAVA_HOME
environment variable.
- Specifies the Java home directory that will be made available to JOC Cockpit from the
--java-options
- Specifies the Java options that will be made available to JOC Cockpit from the
JAVA_OPTIONS
environment variable. - Java options can be used for example to specify Java heap space settings for JOC Cockpit.
- If more than one Java option is used then the value has to be quoted, for example
--java-options="-Xms256m -Xmx512m"
.
- Specifies the Java options that will be made available to JOC Cockpit from the
--service-dir
- Specifies the systemd service directory to which the JOC Cockpit's service file will be copied if the
--make-service
switch is used. - By default the
a/usr/lib/systemd/system
will be used. Users can specify an alternative location.
- Specifies the systemd service directory to which the JOC Cockpit's service file will be copied if the
--service-file
- Specifies the path to a systemd service file that acts as a template and that is copied to the JOC Cockpit's
<home>/jetty/bin
directory. - Users are free to choose any file name as a template for the service file. The resulting service file name will be
joc.service
. - The JOC Cockpit Installer Installation Script will perform replacements in the service file to update paths to be used.
- Specifies the path to a systemd service file that acts as a template and that is copied to the JOC Cockpit's
--service-name
- Specifies the name of the systemd service that will be created if the
--make-service
switch is used. - By default the service name
js7_joc
will be used.
- Specifies the name of the systemd service that will be created if the
...
Replacements
The JOC Cockpit Installer Installation Script performs replacements of settings in configuration files by option values, for details see chapter Replacements.
...
Anchor | ||||
---|---|---|---|---|
|
The JOC Cockpit Installer Installation Script performs replacements of settings in installation files and configuration files by option values.
...
Automation
The JOC Cockpit Installer Installation Script can be executed from a job for automated updating and upgrading of JS7 JOC Cockpit instances.
...