Table of Contents

Introduction

The JOC Cockpit can be installed on Linux and Windows systems without the use of a graphical installer by running the JOC Cockpit installer in headless mode

...

. See the JS7 - JOC Cockpit -

...

Installation Using the Graphical Installer for Linux and Windows article for instructions on the use of a graphical installer.

Prerequisites

The following requirements have to be met before the JOC Cockpit can be installed and operated:

A Java Runtime Environment starting from in version 1.8 or newer is required. Starting from Release 2.5.0 the minimum Java version is Java 11. For details see see the Which Java versions is JobScheduler available for? article.
It is necessary that a time service is operated on the server that hosts JOC Cockpit in order to synchronize the system clock's time.
Technically the JOC Cockpit can be operated for in any Unix environments, however, the JS7 - Platforms limit support for JOC Cockpit operation to Linux.environment. However, support for operation of the JOC Cockpit is limited to Linux systems as described in the JS7 - Platforms article.
The JOC Cockpit requires access to a database to store inventory and status information, status information and as well as workflow related logs , - see the JS7 - Database article.
- A schema has to be created in the database prior to installation.
- A user account has to be created that is granted full privileges to for the schema.
- If you intend to use different accounts and privilege sets for setup and for operation of the JOC Cockpit then consider switching Hibernate configuration files after setup (see below) to use an account with limited privileges to select, insert, update, delete and execute permissions for schema objects.
Installation of the JOC Cockpit requires administrative privileges in the following situations:
- for Unix systems:
  - Root permissions are required if the JOC Cockpit is to be installed including the Jetty servlet container.To install JOC Cockpit without root permissions the setup script can be executed with the -u argument, otherwise the sudo prompt will ask for the root passwordinstaller cannot be executed from the root account but can be executed from a user account that makes use of sudo to acquire privileges:
    - to make the root account owner of the installation directory, for example, in /opt
    - to make the user account owner of the configuration directory, for example, in /var
  - administrative privileges are not required for installation with a user account that owns the installation and configuration directories.
- for Windows systems:
  - The the setup requires administrative privileges.

Download

Download the JOC Cockpit installer archive for your target environment from the JS7 - Download page.
- For Unix systems:
  - A .tar.gz archive including the installer is available that which can be used to run the installer.
    - js7_joc_linux.<release>.tar.gz
- For Windows systems:
  - A .zip archive including the installer is available that available which can be used to run the installer.
    - js7_joc_windows.<release>.zip
The .tar.gz/.zip archives can be used to install JOC Cockpit with the graphical installer or for to carry out headless installation.

Installation

...

Video

This video explains the installation.

Widget Connector

url	https://www.youtube.com/watch?v=Q6Ib9YRAGxg&ab_channel=JobScheduler

Installation in Headless Mode

Installation

The installer is available for Windows and Unix systems.

To run the installer

Installation

The installer is available for Windows and Unix systems.

To run the installer in graphical mode see JS7 - JOC Cockpit - Use of Installation Using the Graphical Installer for Linux and Windows.
To run the installer Installation in headless mode consider the is described below information.

Installer Archive

Extract the JOC Cockpit archive to a suitable directory such as /home/<user-account> on Unix systems or C:\user\<user-account> on Windows systems.

The extracted installer directory layout looks like this:

db (not required for installation: directory for DBMS SQL scripts that can be used in case that database objects should be created before installation, see the JS7 - Database article)
- mssql.sql
- mysql.sql
- oracle.sql
- pgsql.sql

hibernate-examples (directory for DBMS Hibernate connection sample files, see the JS7 - Database article)

hibernate-examples (directory for DBMS connection sample files, for details see JS7 - Database)

hibernate-integrated-security-mssql.cfg.xml
hibernate-maria-mysql.cfg.xml
hibernate-oracle12c.cfg.xml
hibernate-postgres.cfg.xml

install-joc.txt (installation notes)
joc.<release>.jar (installer library for a given release)
joc_install.xml (installer response file)
license.gpl (copy of GPLv3 (General Public License) )
license.html, license.txt (copy of JS7 JobScheduler Commercial License Agreement)
setup.sh|, setup.cmd (installer script for Unix, Windows)

Database Connection

Prior to installation the The database connection has to be ready prior to installation:

Create a schema and user account in your preferred database. For supported DBMS versions see see the JS7 - Database article.
Specify connection information for the JOC Cockpit setup:
- you can specify general connection information during the installation procedure or
- you can prepare a Hibernate configuration file to store connection information.
  - Pick up one of the above Hibernate example files and listed above which matches your DBMS and copy the file to the installer directory, e.g. with the name hibernate.cfg.xml.
  - Apply your changes to the Hibernate file as explained from in the JS7 - Database article.

Installer Response File

The JOC Cockpit makes use of the joc_install.xml file that which includes installer options such as the installation directory, ports etc.
Customers with a commercial license should choose the relevant license option and specify the location of the license key file with the installer response file.

The joc_install.xml file is explained with the code listing below. The joc_install.xml file is explained with the code listing below. The comments included are intended to be self-explanatory.
Download: joc_install.xml

Code Block

language	xml
title	Configuration of the joc_install.xml file
linenumbers	true
collapse	true

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!-- 
XML configuration file for JOC Cockpit setup

The JS7 JOC Cockpit is available with a dual license model:
- GNU GPL v3.0 License, see https://www.gnu.org/licenses/gpl-3.0.en.html
- JS7 Commercial License, see license.txt

The setup asks you for the desired license model,
see below <entry key="licenseOption" .../>

If you run the installer and do not specify a commercial license key
then at the same time you accept the terms of the
license agreement under the GNU GPL v3.0 License.
-->
<AutomatedInstallation langpack="eng">
    <com.izforge.izpack.panels.UserInputPanel id="home">
        <userInput/>
    </com.izforge.izpack.panels.UserInputPanel>
    <com.izforge.izpack.panels.UserInputPanel id="licenses">
        <userInput>
        
            <!-- Select the license model (GPL or Commercial) -->
            <entry key="licenseOption" value="GPL"/>
            
            <!-- If you select GPL as license model than the 'licenseFile' must be empty.
                 Otherwise please enter the path to the license file if available.
                 It is also possible to add the license file later. -->
            <entry key="licenseFile" value=""/>
            
        </userInput>
    </com.izforge.izpack.panels.UserInputPanel>
    <com.izforge.izpack.panels.HTMLLicencePanel id="gpl_license"/>
    <com.izforge.izpack.panels.HTMLLicencePanel id="commercial_license"/>
    <com.izforge.izpack.panels.TargetPanel id="target">
        
        <!-- SELECT THE INSTALLATION PATH
             The path must be absolute! 
             For example:
             /opt/sos-berlin.com/js7/joc on Unix
             C:\Program Files\sos-berlin.com\js7\joc on Windows -->
        <installpath>[:choose absolute installation path of JOC Cockpit:]</installpath>
        
    </com.izforge.izpack.panels.TargetPanel>
    <com.izforge.izpack.panels.UserInputPanel id="jetty">
        <userInput>
            
            <!-- JOC Cockpit requires a servlet container such as Jetty. 
                 If a servlet container is already installed then you can use it. 
                 Otherwise a Jetty will be installed if withJettyInstall=yes.
                 You need root permissions to install JOC Cockpit with Jetty. -->
            <entry key="withJettyInstall" value="yes"/>
            <entry key="jettyPort" value="4446"/>
            <!-- Specify the name of the Windows Service or Unix Daemon (default: joc).
                 Required only for multiple instances of JOC Cockpit on the same server. 
                 The name has to be unique per server. This entry is deactivated by a comment because it
                 MUST NOT BE MODIFIED DURING RE-INSTALLATION! -->
            <!--
            <entry key="jettyServiceName" value="joc"/>
            -->
            <!-- Required for Windows only -->
            <entry key="jettyStopPort" value="40446"/>
            <!-- Available for Unix only (root permissions required) -->
            <entry key="withJocInstallAsDaemon" value="yes"/>
            <!-- Enter a user account for running JOC Cockpit (default=current user).
                 For Unix only (root permissions required)!!! -->
            <entry key="runningUser" value=""/>
            <!-- Path to Jetty base directory 
                 For example:
                 /home/[user]/sos-berlin.com/js7/joc on Unix
                 C:\ProgramData\sos-berlin.com\js7\joc on Windows -->
            <entry key="jettyBaseDir" value=""/>
            <!-- Choose 'yes' or 'no' whether the JOC Cockpit's Jetty should be (re)started after installation -->
            <entry key="launchJetty" value="yes"/>
            
            <!-- Java options for Jetty -->
            <!-- Initial memory pool (-Xms) in MB -->
            <entry key="jettyOptionXms" value="128"/>
            <!-- Maximum memory pool (-Xmx) in MB -->
            <entry key="jettyOptionXmx" value="512"/>
            <!-- Thread stack size (-Xss) in KB -->
            <entry key="jettyOptionXss" value="4000"/>
            <!-- Further Java options -->
            <entry key="jettyOptions" value=""/>
            
        </userInput>
    </com.izforge.izpack.panels.UserInputPanel>
    <com.izforge.izpack.panels.UserInputPanel id="joc">
        <userInput>
            
            <!-- JOC Cockpit can be installed in a cluster. Please type a unique title to identify the cluster node, 
                 e.g. 'Primary' or 'Secondary' (default = hostname). Max. length is 30 characters. -->
            <entry key="jocTitle" value=""/>
            
            <!-- Choose 'yes' if JOC Cockpit is operated as a standby instance in a cluster -->
            <entry key="isStandby" value="no"/>
            
            <!-- Security Level for the deployment signing mechanism: possible values are 'LOW', 'MEDIUM' and 'HIGH':
                 HIGH:
                    RSA/ECDSA certificates are stored for verification per user,
                    signing is performed externally outside of JOC Cockpit.
                 MEDIUM:
                    RSA/ECDSA private keys and certificates are stored for signing per user,
                    signing is performed automatically with the user's private key.
                 LOW:
                    a single RSA/ECDSA private key and certificate are stored with the root account,
                    signing is performed automatically with the root account's private key for all users. -->
            <entry key="securityLevel" value="LOW"/>
            
        </userInput>
    </com.izforge.izpack.panels.UserInputPanel>
    <com.izforge.izpack.panels.UserInputPanel id="database">
        <userInput>
            <!-- Reporting Database Configuration -->
            
            <!-- Database connection settings can be specified with subsequent entries such as
                 databaseHost, databasePort, ... or by a Hibernate configuration file.
                 or you choose the embedded H2 database (for evaluation only) without further configuration.
                 Possible values are 'withoutHibernateFile', 'withHibernateFile' and 'h2'. -->
            <entry key="databaseConfigurationMethod" value="withoutHibernateFile"/>
                 
            <!-- Choose the database management system. 
                 Supported values are 'mysql' for MySQL, 'oracle' for Oracle, 
                 'mssql' for Microsoft SQL Server, 'pgsql' for PostgreSQL.
                 Used only if databaseConfigurationMethod=withoutHibernateFile -->
            <entry key="databaseDbms" value="mysql"/>
            
            <!-- Path to a Hibernate configuration file if databaseConfigurationMethod=withHibernateFile -->
            <entry key="hibernateConfFile" value=""/>
            
            <!-- You can choose between 'byInstaller', 'byJoc' or 'off' to create the database objects.
                 Data of an already existing installation remain unchanged. 
                 This entry should be 'off' only when you are certain that all objects have already been created.
                 'byJoc' creates or updates database object the next time JOC Cockpit is started. 'byInstaller' is recommended.
                 If databaseConfigurationMethod=h2 then the objects will be created when JOC Cockpit starts and 
                 this value will be ignored -->
            <entry key="databaseCreateTables" value="byInstaller"/>
            
        </userInput>
    </com.izforge.izpack.panels.UserInputPanel>
    <com.izforge.izpack.panels.UserInputPanel id="dbconnection">
        <userInput>
            <!-- Database configuration if databaseConfigurationMethod=withoutHibernateFile -->
                 
            <!-- Enter the hostname or ip address of the database host.
                 This entry can also be used to configure the URL(s) for Oracle RAC databases.
                 For example:
                 <entry key="databaseHost" value="(DESCRIPTION=(ADDRESS_LIST=(LOAD_BALANCE=OFF)(FAILOVER=ON)
                    (ADDRESS=(PROTOCOL=TCP)(HOST=tst-db1.myco.com)(PORT=1604))
                    (ADDRESS=(PROTOCOL=TCP)(HOST=tst-db2.myco.com)(PORT=1604)))
                    (CONNECT_DATA=(SERVICE_NAME=mydb1.myco.com)(SERVER=DEDICATED)))"/>
                 The "databaseSchema" and "databasePort" entries should be left empty. -->
            <entry key="databaseHost" value=""/>
            
            <!-- Enter the port number for the database instance. Default ports are for MySQL 3306, 
                 Oracle 1521, Microsoft SQL Server 1433, PostgreSQL 5432. -->
            <entry key="databasePort" value=""/>
            
            <!-- Enter the database schema -->
            <entry key="databaseSchema" value=""/>
            
            <!-- Enter the user account for database access -->
            <entry key="databaseUser" value=""/>
            
            <!-- Enter the password for database access -->
            <entry key="databasePassword" value=""/>
            
        </userInput>
    </com.izforge.izpack.panels.UserInputPanel>
    <com.izforge.izpack.panels.UserInputPanel id="jdbc">
        <userInput>
            <!-- Database configuration if databaseConfigurationMethod != h2 -->
            
            <!-- You can specify an external JDBC Driver, in this case set internalConnector=no
                 For license reasons MySQL and Microsoft SQL Server JDBC drivers are not included. 
                 Alternatively you can use the MariaDB JDBC Driver for MySQL that is included. 
                 For Microsoft SQL Server you have to specify an external JDBC Driver. 
                 An Oracle ojdbc8 JDBC driver is included. -->
                 
            <!-- You can choose between 'yes' or 'no' for using the internal JDBC Driver -->
            <entry key="internalConnector" value="yes"/>
                 
            <!-- Select the path to the JDBC Driver file (*.jar) -->
            <entry key="connector" value=""/>
            
        </userInput>
    </com.izforge.izpack.panels.UserInputPanel>
    <com.izforge.izpack.panels.UserInputPanel id="end">
        <userInput/>
    </com.izforge.izpack.panels.UserInputPanel>
    <com.izforge.izpack.panels.InstallPanel id="install"/>
    <com.izforge.izpack.panels.ProcessPanel id="process"/>
    <com.izforge.izpack.panels.FinishPanel id="finish"/>
</AutomatedInstallation>

Running the Installer

Headless installation is performed by opening a terminal or command console window and navigating to the folder containing the setup.sh| or setup.cmd file.

Performing headless installation of JOC Cockpit on Unix systems with without root permissions:

Code Block

language	text
title	Starting headless installation of the JOC Cockpit on Unix systems with without root permissions

/home/<user-account>/joc.<release> # login as the user account (not as root)
./setup.sh -u joc_install.xml

All files in the installation and configuration directories will be owned by the user account

Performing headless installation of JOC Cockpit on Unix systems without root permissionsfrom a user account that can acquire root permissions:

Code Block

language	text
title	Starting headless installation of the JOC Cockpit on Unix systems without with root permissions

/home/<user-account>/joc.<release> # login as the user account (not as root)
./setup.sh -u joc_install.xml

The installer will use sudo to acquire root permissions. Execution of the above command by the root account is denied.
Files in the installation directory will be owned by the root account, files in the data directory will be owned by the user account as described below.

Performing headless installation of JOC Cockpit on Windows systems requires administrative privileges:

Code Block

language	text
title	Starting headless installation of the JOC Cockpit on Windows systems

C:\users\<user-account>\joc.<release> @rem login with an account that can acquire elevated privileges for administrative tasks
setup.cmd joc_install.xml

Directory Layout

Note: Do not omit specifying the joc_install.xml response file as a command line argument when executing setup.sh or setup.cmd. If the response file is not specified, the graphical installer will be invoked as described in the JS7 Installation: How to install the JS7 JOC Cockpit on premises using the Graphical Installer article.

Directory Layout

By default the installation is added:If the Jetty servlet container included with JOC Cockpit is installed then files will be added by default

for Unix to the:
- installation directory: /opt/sos-berlin.com/js7/joc
- configuration data directory: /var/sos-berlin.com/js7/joc
for Windows to the:
- installation directory: Program Files\sos-berlin.com\js7\joc
- configuration data directory: ProgramData\sos-berlin.com\js7\joc

The following listing explains shows the directory layout after installation of the JOC Cockpit:

/opt (Unix installation directory), Program Files (Windows installation directory)

sos-berlin.com
- js7
  - joc (installation directory)
/var (Unix), ProgramData (Windows)
- sos-berlin.com
  - js7
    - joc
      - jetty_base (configuration directory)
        archive (directory for JOC Cockpit versions before applying patches, remains in place after uninstall)
        lib (directory for Java libraries, remains in place after uninstall)
        logs (directory for log files files, remains in place after uninstall)
        patches (directory for patch files (*.zip), remains in place after uninstall)
        resources (directory for configuration files, remains in place after uninstall)
        joc (directory for configuration files, remains in place after uninstallinstall)
        license (directory for license certificate files, remains in place after uninstall)
        xsd (directory for XSD schemas, remains in place after uninstall)
        hibernate.cfg.xml (Hibernate configuration file for database access, remains in place after uninstall if modified)
        joc.properties (JOC Cockpit configuration file, remains in place after uninstall)
        log4j2.xml (log configuration file, remains in place after uninstall if modified)
        shiro.ini.active (Shiro configuration file reporting the currently active configuration, remains in place after uninstall)
        shiro.ini-example (Shiro example configuration file)
      - temp (directory for temporary files, remains in place after uninstall)
      - webapps (directory for JOC Cockpit files that are extracted from the deployed joc.war file)
      - start.ini (Jetty servlet container configuration file, remains in place after uninstall)

Directory Layout if the Jetty Servlet Container is not Installed

If the Jetty servlet container included with JOC Cockpit is not installed and no previous configuration files are found in the Program Files\sos-berlin.com\js7\joc directory then by default files will be added to the Program Files\sos-berlin.com\js7\joc directories only.

If configuration files are found in Program Files\sos-berlin.com\js7\joc directory then files will be added to the ProgramData\sos-berlin.com\js7joc and Program Files\sos-berlin.com\js7\joc directories as explained above.

Update

Preparation

Stop the JS7 JOC Cockpit instance.

Running the Update

The update of the JS7 JOC Cockpit is performed from the same download archive as used for any fresh installation.
Use the joc_install.xml file created while the installation. The default location of the joc_install.xml file from a previous installation is:
- C:\Program Files\sos-berlin.com\js7\joc\ for Windows
- /opt/sos-berlin.com/js7/joc for Unix systems
Perform the same step to run the installer as explained above.

Installation Log Files

The JOC Cockpit configuration and installation log information is written to a new log file each time an installation or update is carried out. These log files can be found in the logs sub-directory of the jetty_base directory.

Installation log files use names according to the pattern Install_V<release>_<date-time>_....log where <release> is the release number and <date-time> refers to the point in time of installation.
For further information about logging see JS7 - Logging.

Installation for alternative Servlet Containers

The JOC Cockpit installation procedure contains the option to install the Jetty servlet container included with the JOC Cockpit installer archive. An alternative servlet container capable of handling Java web applications, such as Tomcat, can be used, however, support by SOS is limited to the JOC Cockpit application and does not include support for individually installed servlet containers.

If the Jetty servlet container included with JOC Cockpit is not to be installed, then the installer will check if a jetty_base symlink from a previous installation is found in the jetty_home directory. Particularly relevant for system administrators is the shiro.ini.active file (containing authentication and authorization settings) and the joc.properties file (containing JOC Cockpit installation settings).

If configuration files are found then they will not be overwritten or removed.
Default configuration files will be written to the file system in the joc_home directory.
System administrators can move the configuration files to the appropriate directory of their servlet container as required.

Location of the `resources/joc` directory after fresh installation

With a fresh installation the installer will not find an existing Jetty servlet container and will store the resources directory for the joc application by default to the following location:

for Unix systems:
- /opt/sos-berlin.com/js7/joc/resources/joc
for Windows systems:
- C:\Program Files\sos-berlin.com\js7\joc\resources\joc

Location of the `resources/joc` directory after update

If JOC Cockpit is updated without the Jetty servlet container but on top of an existing installation that includes the Jetty servlet container then the resources\joc directory will not be moved from its location. Practically this means that the "new" resources directory after the update will be found with the following directories (assuming the original installation was carried out for the default directories):

for Unix systems:
- /opt/sos-berlin.com/js7/joc/resources/joc
for Windows systems:
- C:\Program Files\sos-berlin.com\js7\joc\resources\joc

In this situation

the shiro.ini and joc.properties files from an earlier installation will not be overwritten.
an existing hibernate.cfg.xml database configuration file will be considered during update and the settings will be suggested as default values. This file will be deleted and a new version of the file will be stored to the joc_home directory.
an update of JOC Cockpit will not overwrite any existing configuration files. However new versions of the joc.properties and shiro.ini files with the names joc.properties-example and shiro.ini-example will be stored to the resources\joc folder, alongside the original files.

Initial Operation

Operation

Having completed the installation or update of the JS7 JOC Cockpit you can start the JOC Cockpit either manually or from its Unix daemon/Windows Service, see JS7 - JOC Cockpit Command Line Operation.

Login to JOC Cockpit User Interface

Note that a working servlet container - either the Jetty provided with the JOC Cockpit or some other product - is required before the JOC Cockpit can be operated.

...

In your browser navigate to the JOC Cockpit URL and enter the User Account and Password. Typically the URL includes the hostname and port that JOC Cockpit has been installed for:

For example, http://myhost:4446. Please check that the JOC Cockpit port is accessible which might include to add firewall rules to allow access to this port from the computer that you operate the browser for.
After initial installation of JOC Cockpit the default User Account and Password of root:root will be available if no changes have been made to the shiro.ini configuration file.

...

Note that the root user is assigned the all role in the default configuration that includes any available permissions.
See the Authentication and Authorization - Configuration article for information about the configuration of other user profiles and authentication methods.

- - - - .jocinstallinformation (installation response file, remains in place after uninstall)
      - jetty_base (symbolic link to data directory)
      - license.gpl (copy of GPLv3 (General Public License) used for the Open Source JS7 - License)
      - license.html (HTML format of license terms for the commercial JS7 - License)
      - license.txt (plain text format of license terms for the commercial JS7 - License)
      - sbom.json (JS7 - Software Bill of Materials)
      - ThirdParty.txt (lists the the 3rd party components and licenses used by JS7)
      - db (directory for DBMS *.sql scripts to populate the database)
        h2
        mssql
        mysql
        oracle
        pgsql
      - install (directory with Jetty installer scripts)
        install_jetty_base.sh|.cmd (used by installer)
        install_jetty_service.sh (used by installer for Unix)
        joc_install_tables.sh,|.cmd (creates or updates database objects, used for JS7 - Rescue in case of lost access to JOC Cockpit)
        joc_manage_identity_service.sh|.cmd (see JS7 - Shiro Identity Service Migration)
        uninstall_jetty_service.sh (used by installer for Unix)
        update_jetty_base.sh|.cmd (used by installer)
      - jetty (directory for Jetty binary files and scripts)
        bin
        anonymize-logs.sh|.cmd (used to anonymize log files, see JS7 - Log Anonymization)
        jetty.sh (start script for JOC Cockpit Unix daemon)
        joc.service (sample file for use with JS7 - systemd Service Files for automated Startup and Shutdown with Unix Systems)
      - lib (directory for user specific configurations)
        log4j2.xml (used for based console logging to stdout, see JS7 - Logging)
        patches (used for JS7 - Patches for JOC Cockpit, the directory is cleaned up when running the installer)
        user_lib (used for individual .jar files such as JDBC Drivers, see JS7 - Database)
      - service (directory for operation as a Windows Service)
        install_jetty_windows_service.cmd (used by installer)
        js7_joc.exe, js7_jocw.exe (used for start-up and configuration of the service, see JS7 - How To - Apply Java Options)
        set_java_home_for_jetty_windows_service.cmd (see JS7 - JOC Cockpit Windows Service does not start)
        start_jetty_windows_service.cmd (used by installer)
        uninstall_jetty_windows_service.cmd (used by installer)
      - Uninstaller (Uninstaller directory, the empty directory remains in place after uninstall)
        joc_install.xml (installer response file, remains in place after uninstall)
        uninstaller.jar (binary file of the uninstaller)
        uninstall.sh|cmd (script to invoke uninstaller)
/var (Unix data directory), ProgramData (Windows data directory)
- sos-berlin.com
  - js7
    - joc
      - jetty_base (configuration directory)
        joc_home (symbolic link to installation directory)
        start.ini (Jetty servlet container configuration file, remains in place after uninstall. This file is migrated to the start.d folder starting from Release 2.5.0)
        archive (directory for JOC Cockpit versions before applying patches, remains in place after uninstall)
        lib (directory for Java libraries, remains in place after uninstall)
        logs (directory for log files files, remains in place after uninstall)
        resources (directory for configuration files, remains in place after uninstall)
        joc (directory for configuration files, remains in place after uninstall)
        hibernate.cfg.xml (Hibernate configuration file for database access, remains in place after uninstall if modified)
        joc.properties (JOC Cockpit configuration file, remains in place after uninstall)
        log4j2.xml (log configuration file, remains in place after uninstall if modified, see JS7 - Logging)
        shiro.ini.active (Shiro configuration file if the JS7 - Shiro Identity Service is used. This file reports the currently active configuration, remains in place after uninstall)
        shiro.ini-example (Shiro example configuration file if the JS7 - Shiro Identity Service is used)
        lib (optional directory for JDBC Drivers and licensed binary code)
        license (optional directory for license certificate files, remains in place after uninstall)
        xsd (directory for XSD schema files, remains in place after uninstall)
        start.d (starting from Releases 2.5 (in progress) that introduces Jetty 11 this directory holds *.ini files for settings previously available with start.ini)
        temp (directory for temporary files, remains in place after uninstall)
        webapps (directory for JOC Cockpit installation)
        joc (directory for JOC Cockpit GUI files and patches)
        WEB-INF
        classes (directory for resource files and JS7 - Patches for JOC Cockpit)
        lib (Java binary files)
        root
/home/<user-account> (Unix home directory)
- .jocrc (user profile script applied on start-up of JOC Cockpit)

Directory Layout if the Jetty Servlet Container is not Installed

If the Jetty servlet container included with JOC Cockpit is not installed and if no previous configuration files are found in the Program Files\sos-berlin.com\js7\joc directory then by default files will only be added to the Program Files\sos-berlin.com\js7\joc directories.

If configuration files are found in Program Files\sos-berlin.com\js7\joc directory then files will be added to the ProgramData\sos-berlin.com\js7joc and Program Files\sos-berlin.com\js7\joc directories as explained above.

Update and Upgrade

Detailed instructions for updating and upgrading can be found in the JS7 - Update and Patch Management article.

Preparation

Stop the JS7 JOC Cockpit instance.

Running the Update

The update of the JS7 JOC Cockpit is performed from a similar download archive to that used for a fresh installation.
Use the joc_install.xml file created during the installation. The default location of the joc_install.xml file from a previous installation is:
- C:\Program Files\sos-berlin.com\js7\joc\ for Windows and
- /opt/sos-berlin.com/js7/joc for Unix systems.
Perform the same steps to run the installer as explained above.
- The update will replace existing files and will update database objects as required.
- The update will not remove configuration files or settings in such files.

Installation Log Files

The JOC Cockpit configuration and installation log information is written to a new log file each time an installation or update is carried out. These log files can be found in the logs sub-directory of the jetty_base directory.

Installation log files use names according to the pattern Install_V<release>_<date-time>_....log where <release> is the release number and <date-time> refers to the point in time of installation.
For further information about logging see the JS7 - Logging article

...

Register Controller and Agents

After successful login to JOC Cockpit a dialog window appears. This window asks to register a Controller. You will find the same dialog later on from the User -> Manage Controllers/Agents menu item.

You have a choice to register a Standalone Controller (n scope of the JS7 Open Source License) or a Controller Cluster for high availability (requires a JS7 Commercial License, see JS7 - Licensing).

Register Standalone Controller

...

The title added for the Controller will be visible in the JS7 - Dashboard view.
The URL for JOC Cockpit is the hostname and port of the Controller as seen by JOC Cockpit. This URL is used by JOC Cockpit to connect to a Controller.
Consider that the Controller's port is accessible which might include to add firewall rules to allow access to this port from the server that JOC Cockpit is operated for.

Register Controller Cluster

A Controller Cluster implements high availability for automated fail-over should a Controller instance be terminated or become unavailable.

Note that high availability by clustering is subject to JS7 - Licensing. Without a license fail-over/switch-over will not take place between Controller cluster members.

Image Removed

Explanation

This dialog allows to specify the Primary Controller instance, the Secondary Controller instance and an Agent Cluster Watcher.
The title added for each Controller instance will be visible in the JS7 - Dashboard view.
Primary and Secondary Controller instances require a URL as seen from JOC Cockpit. This URL is used by JOC Cockpit to connect to the Controller instances respectively.
The URL of the Controller typically includes the hostname and port that the Controller instance is operated for.
The Agent Cluster Watcher is required for operation of a Controller Cluster. The Agent is contacted by both Controller Cluster members to verify the cluster status should no direct connection between Controller Cluster members be available.
- The Agent is assigned an Agent ID which is a unique identifier for this Agent that cannot be modified during lifetime of an Agent. Change of the Agent ID requires to remove and to add the Agent with JOC Cockpit, it is not required to uninstall/reinstall an Agent.
- The Agent Name is a unique identifier that is used for example in the Configuration view to assign Agents to jobs. The Agent Name can be modified later on.
- The Agent URL is the hostname and port for which the Agent is operated.
Consider that the following connections should be accessible which might include to add firewall rules to allow access to the ports:
- JOC Cockpit connection to the Primary Controller host and port.
- JOC Cockpit connection to the Secondary Controller host and port.
- Primary Controller connection to the Secondary Controller host and port.
- Secondary Controller connection to the Primary Controller host and port.
- Primary Controller connection to the Cluster Watcher Agent host and port.
- Secondary Controller connection to the Cluster Watcher Agent host and port.

Register Agents

After the connection between JOC Cockpit and the Controller is established you can add Agents. To register an Agent switch to the Manage Controller/Agents view from the user menu. Click on the Action Menu of the Controller for which an Agent should be registered and select Add Agent.

Image Removed

Explanation:

The Agent is assigned an Agent ID which is a unique identifier for this Agent that cannot be modified during the lifetime of an Agent. Change of the Agent ID requires to remove and to add the Agent with JOC Cockpit, it is not required to uninstall/reinstall an Agent.
The Agent Name is a unique identifier that is used for example in the Configuration view to assign Agents to jobs. The Agent Name can be modified later on
In addition, you can add Agent Alias Names to make the same Agent available by different names.
The Agent URL is the hostname and port for which the Agent is operated.

Configuration

...

.

Deinstallation

The JOC Cockpit can be uninstalled using the uninstall.cmd sh and uninstall.shcmd scripts available from the following locations:

For Unix systems:
- /opt/sos-berlin.com/js7/joc/Uninstaller
For Windows systems:
- C:\Program Files\sos-berlin.com\js7\joc\Uninstaller

Unix Systems

...

The uninstall script on Unix systems runs in headless mode. The uninstall script will start the Uninstaller and will remove the installation directory, data directory and sub-folders.

Windows Systems

Starting the uninstaller will display the following window on Windows systems:

Selecting the "Force the deletion of C:\Program Files\ ...." checkbox will cause the uninstall script to remove boththe program and the configuration files and folders.

If the checkbox is not selected, configuration files will be left in both the JOC Cockpit installation folder and the Jetty servlet container installation folder (if installed with the JOC Cockpit).

Unix systems

The uninstall script on Unix systems runs in headless mode. The uninstall script will start the Uninstaller and remove both the program files, configuration files and respective folders.

Cluster Operation

Please consider that operating a JOC Cockpit cluster for high availability requires a commercial license, see JS7 - Licensing.

A number of JOC Cockpit instances can be operated as a passive cluster with the first JOC Cockpit instance started acting as the primary cluster member and any additional JOC Cockpit instances acting as standby cluster members. The role of the primary cluster member is decided by the order by which JOC Cockpit instances are started.

The installation of JOC Cockpit instances follows the standard operating procedures explained above, there is no difference in installation considering the roles of primary cluster member and standby cluster members.

Automated Start-up and Shutdown

For Unix systems, the start-up and shutdown configurations apply that are executed by root, e.g. in /etc/init.d or corresponding locations and by use of systemd.

The JOC Cockpit will start for the user account that is specified during installation. The JOC Cockpit start script jetty.sh|cmd will switch to this account independently from the fact that the start script is executed e.g. by the root account.
For use with systemd find a sample service file from ./bin/joc.service-example file.

For Windows systems operation of the JOC Cockpit by a Windows Service is recommended as such services can be configured to start/stop automatically on server start-up and shutdown.

Further References

Automated Start-up and Shutdown

For Unix systems a start-up and shutdown configuration can be used that is executed by systemd running with the root account.

For details see the JS7 - systemd Service Files for automated Startup and Shutdown with Unix Systems article.

For Windows systems operation of the JOC Cockpit by a Windows Service is recommended as such services can be configured to start/stop automatically on server start-up and shutdown.

Consider assigning a service account to the JOC Cockpit service with the Windows Service Panel.
Consider allowing the JOC Cockpit service to be automatically started on server start-up.

Initial Operation

Having completed the installation or update of the JS7 JOC Cockpit you can start the JOC Cockpit either manually or from its Unix daemon/Windows Service, see the JS7 - JOC Cockpit Command Line Operation article.

Should users face problems starting the JOC Cockpit then please refer to the JS7 - Troubleshooting - JOC Cockpit section.

A number of JOC Cockpit instances can be operated as a passive cluster with the first JOC Cockpit instance started acting as the primary cluster member and any additional JOC Cockpit instances acting as standby cluster members. The role of the primary cluster member is decided by the order by which JOC Cockpit instances are started.

Info

Note that operating a JOC Cockpit cluster for high availability requires a commercial license, see JS7 - License.
The installation of JOC Cockpit Cluster instances follows the standard operating procedures explained above. There is no difference in installation for the roles of primary cluster member and standby cluster members.
Note the following information about initial cluster operation:
- JS7 - Initial Operation for JOC Cockpit Cluster

Further References

Installation
JS7 - JOC Cockpit - Installation Using the Graphical Installer for Linux and Windows
JS7 - JOC Cockpit - Installation using alternative Servlet Containers
OperationJS7 - JOC Cockpit - Use of Graphical Installer
JS7 - JOC Cockpit - Command Line Operation
JS7 - Initial Operation for JOC Cockpit Cluster
Configuration
JS7 - JOC Cockpit Configuration Items
JS7 - Authentication
and Authorization
Authentication and JS7 - Authorization - ConfigurationAuthentication and Authorization
JS7 - Permissions JOC Cockpit -
Security
Secure Operation
JS7 - JOC Cockpit
-
HTTPS
Authentication

Installation with other servlet containers:

- - Connections
Troubleshooting
JS7 - Troubleshooting - JOC Cockpit
Tips from a user for Installation with Tomcat

Space shortcuts

Page tree

Page History

Versions Compared

Old Version 18

New Version Current

Key

Introduction

Prerequisites

Download

Installation

Video

Installation in Headless Mode

Installation

Installation

Installer Archive

Database Connection

Installer Response File

Running the Installer

Directory Layout

Directory Layout

Update

Preparation

Running the Update

Installation Log Files

Installation for alternative Servlet Containers

Location of the resources/joc directory after fresh installation

Location of the resources/joc directory after update

Initial Operation

Operation

Login to JOC Cockpit User Interface

Update and Upgrade

Preparation

Running the Update

Installation Log Files

Register Controller and Agents

Register Standalone Controller

Register Controller Cluster

Register Agents

Configuration

Deinstallation

Unix Systems

Windows Systems

Unix systems

Cluster Operation

Automated Start-up and Shutdown

Further References

Automated Start-up and Shutdown

Initial Operation

Further References

Location of the `resources/joc` directory after fresh installation

Location of the `resources/joc` directory after update