Introduction
Installation, updates and upgrades are performed using the .tar.gz/.zip archives provided for the initial installation of newer releases.
- JS7 - Installation instructions apply.
- For environments with a larger number of Agents the installation, 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 Agent Installer Script that is described in this article either standalone or in combination with such tools.
Security
Secure rollout of JS7 components is critical. It is therefore recommended that the solution described here is adjusted to suit specific security needs.
- Rollout of JS7 Agents is considered critical as the software allows jobs to be executed on a larger number of servers.
- Integrity of the sources for downloads of JS7 components deserves attention.
- This includes intermediate devices to which JS7 software installers are stored in a user's environment.
- It is an option to run the Agent Installer Script from
sudo
and to use the digest functionality that compares the script to a hash value stored with thesudoers
file.
- The solution provided for updating, upgrading and patching JS7 Agents is based on shell scripting by design:
- to provide readability and to rely on OS commands only,
- to deny the use of any 3rd-party components and additional dependencies that require code to be executed on the machines that run Agents.
- The Agent Installer Script can be integrated in a number of ways:
- by running one's own SSH scripts on top of the Agent Installer Script,
- by use with 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 set up for deployment purposes, for details see JS7 - Deployment.
- Access to the Controller and Agent for rollout should be securely managed.
- JS7 Agents can be rolled out from a Controller to which the Agents are not registered.
Agent Installer Script
The Agent Installer Script is provided for download and can be used to automate updates, upgrades and patches of JS7 Agents.
- The script is available for Linux, MacOS®, AIX® and Solaris® using bash, dash, ksh and zsh POSIX-compatible shells. For AIX® and Solaris® automated installation is supported, automated configuration is not.
- The script can be used to install, update or patch an Agent using the installation options. In addition it can be used to configure an Agent, for example in case of certificate renewal.
- The script creates
- the
agent_<http-port>.sh
Instance Start Script in the Agent'sbin
directory if no such file exists, - the
agent_<http-port>.service
systemd Service File in the Agent'sbin
directory, see JS7 - systemd Service Files for automated Startup and Shutdown with Unix Systems.
- the
- The script terminates with exit code 0 to signal success, with exit code 1 for command line argument errors and with exit code 2 for non-recoverable errors.
- The script is intended as a baseline example for customization by JS7 users and by SOS within the scope of professional services.
- See the information in the JS7 - Agent Command Line Operation article.
Download
Find the Agent Installer Script for download from JS7 - Download.
Usage
Invoking the Agent Installer Script without arguments displays the usage clause:
Usage: js7_install_agent.sh [Options] [Switches] Installation Options: --home=<directory> | required: directory to which the Agent will be installed --data=<directory> | optional: directory for Agent data files, default: <home>/var_4445 --config=<directory> | optional: directory from which the Agent reads configuration files, default: <data>/config --logs=<directory> | optional: directory to which the Agent writes log files, default: <data>/logs --work=<directory> | optional: working directory of the Agent, default: <data> --user=<account> | optional: user account for Agent daemon, default: $USER --release=<release-number> | optional: release number such as 2.5.0 for download if --tarball is not used --tarball=<tar-gz-archive> | optional: the path to a .tar.gz archive that holds the Agent tarball, | if not specified the Agent tarball will be downloaded from the SOS web site --patch=<issue-key> | optional: identifies a patch for an existing Agent installation --instance-script=<file> | optional: path to the Instance Start Script that will be copied to the Agent, default <home>/bin/<instance-script> --backup-dir=<directory> | optional: backup directory for existing Agent home directory --log-dir=<directory> | optional: log directory for log output of this script --exec-start=<command> | optional: command to start the Agent, e.g. 'StartService' --exec-stop=<command> | optional: command to stop the Agent, e.g. 'StopService' --return-values=<file> | optional: path to a file that holds return values such as the path to a log file Configuration Options: --deploy-dir=<dir>[,<dir>] | optional: deployment directory from which configuration files are copied to the Agent --agent-conf=<file> | optional: path to a configuration file that will be copied to <config>/agent.conf --private-conf=<file> | optional: path to a configuration file that will be copied to <config>/private/private.conf --http-port=<port> | optional: specifies the http port the Agent will be operated for, default: 4445 port can be prefixed by network interface, e.g. localhost:4445 --https-port=<port> | optional: specifies the https port the Agent will be operated for port can be prefixed by network interface, e.g. batch.example.com:4445 --pid-file-dir=<directory> | optional: directory to which the Agent writes its PID file, default: <data>/logs --pid-file-name=<file-name> | optional: file name used by the Agent to write its PID file, default: agent.pid --controller-id=<identifier> | optional: Controller ID, default: controller --controller-primary-cert=<file> | optional: path to Primary/Standalone Controller certificate file --controller-secondary-cert=<file> | optional: path to Secondary Controller certificate file --keystore=<file> | optional: path to a PKCS12 keystore file that will be copied to <config>/private/ --keystore-password=<password> | optional: password for access to keystore --keystore-alias=<alias-name> | optional: alias name for keystore entry --truststore=<file> | optional: path to a PKCS12 truststore file that will be copied to <config>/private/ --truststore-password=<password> | optional: password for truststore password --java-home=<directory> | optional: Java Home directory for use with the Instance Start Script --java-options=<options> | optional: Java Options for use with the Instance Start Script --service-dir=<directory> | optional: systemd service directory, default: /usr/lib/systemd/system --service-file=<file> | optional: path to a systemd service file that will be copied to <home>/bin/<file> --service-name=<identifier> | optional: name of the systemd service to be created, default js7_agent_<http-port> Switches: -h | --help | displays usage --show-logs | shows log output of the script --make-dirs | creates the specified directories if they do not exist --make-service | creates the systemd service for the Agent --move-libs | moves an existing Agent's lib directory instead of removing the directory --remove-journal | removes an existing Agent's state directory that holds the journal files --restart | stops a running Agent and starts the Agent after installation --abort | aborts a running Agent if used with the --restart switch --kill | kills a running Agent if used with the --restart switch
Installation Options
--home
- Specifies the directory in which the Agent should be installed.
--data
- Specifies the directory in which Agent data such as configuration files should be stored.
- By default the
<home>/var_<http-port>
directory is used, see options--home
and--http-port
.
--config
- Specifies the directory from which the Agent reads configuration files.
- By default the
<data>/config
directory is used, see option--data
.
--logs
- Specifies the directory to which the Agent stores log files.
- By default the
<data>/logs
directory is used, see option--data
.
--work
- Specifies the working directory of the Agent.
- By default the
<data>
directory is used, see option--data
.
--user
- Specifies the user account for the Agent daemon.
- By default the account of the user running the Agent Installer Script is used.
--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 Agent 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
that considershttp_proxy
andhttps_proxy
environment variables and respective settings from a.curlrc
file.
- Optionally specifies the path to a .tar.gz file that holds the Agent 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
--patch
- A patch is identified by an issue key in the Change Management System, for example JS-1984.
- Patches are downloaded from the SOS web site if the
--tarball
option is not used. - Patches are added to the Agent's
<home>/lib/patches
directory. Note that thepatches
sub-directory will be emptied when updating a Controller installation later on. - If a backup directory is specified then an Agent's existing installation directory will be added in a .tar.gz file in this directory.
--instance-script
- Specifies the path to an Instance Start Script that acts as a template and that is copied to the
bin
directory. Typically the nameagent_<http-port>.sh
. is used. Users are free to choose any name for the Instance Start Script. The script has to be executable for the Agent daemon, see--user
option. Permissions of the script are not changed by the Agent Installer Script. - The Agent Installer Script will perform replacements in the Instance Start Script template for known placeholders such as
<JS7_AGENT_USER>
, for details see./bin/agent_instance.sh-example
.
- Specifies the path to an Instance Start Script that acts as a template and that is copied to the
--backup-dir
- If a backup directory is specified then an Agent's existing installation directory will be added to a .tar.gz file in this directory.
- File names are created according to the pattern:
backup_js7_agent.<hostname>.<release>.<yyyy>-<MM>-<dd>T<hh>-<mm>-<ss>.tar.gz
- For example:
backup_js7_agent.centostest_primary.2.3.1.2022-03-19T20-50-45.tar.gz
--log-dir
- If a log directory is specified then the installer script will log information about processing steps in a log file in this directory.
- File names are created according to the pattern:
install_js7_agent.<hostname>.<yyyy>-<MM>-<dd>T<hh>-<mm>-<ss>.log
- For example:
install_js7_agent.centostest_primary.2022-03-19T20-50-45.log
--exec-start
- This option can be used should the Agent be started after installation. For example, when using systemd then the option
--exec-start=
"StartService"
will start the Agent 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_agent_4445"
. - 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 the use of the
--restart
switch which will start the Agent from its Instance Start Script. If specified this option overrules the--restart
switch.
- This option can be used should the Agent be started after installation. For example, when using systemd then the option
--exec-stop
- This option can be used should the Agent be stopped before installation. For example, when using systemd then the option
--exec-stop="StopService"
will stop the Agent 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_agent_4445"
. - 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 the use of the -
-restart
switch which stops the Agent from its Instance Start Script. If specified this option overrules the--restart
switch.
- This option can be used should the Agent be stopped before installation. For example, when using systemd then the option
--return-values
- Optionally specifies the path to a file to which return values will be added in the format
<name>=<key>
. For example:log_file=install_js7_agent.centostest_primary.2022-03-20T04-54-31.log
backup_file=backup_js7_agent.centostest_primary.2.3.1.2022-03-20T04-54-31.tar.gz
- An existing file will be overwritten. It is recommended to use a unique file name such as
/tmp/return.$$.$RANDOM.properties
. - 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 to which return values will be added in the format
Configuration Options
--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 asagent.conf
,private.conf
,log4j2.xml
etc. - Use of a deployment directory has lower precedence as files can be overwritten by individual options such as
--agent.conf
,--private-conf
etc.
- Specifies the path to a deployment directory that holds configuration files and sub-directories that will be copied to the
--agent-conf
- Specifies the path to a configuration file for global JS7 - Agent Configuration Items. The file will be copied to the
<config>/agent.conf
file. - Any file name can be used as a value of this option, however, the target file name
agent.conf
will be used.
- Specifies the path to a configuration file for global JS7 - Agent Configuration Items. The file will be copied to the
--private-conf
- Specifies the path to a configuration file for private JS7 - Agent Configuration Items. The file will be copied to the
<config>/private/private.conf
file. - Any file name can be used as a value of this option, however, the target file name
private.conf
will be used.
- Specifies the path to a configuration file for private JS7 - Agent Configuration Items. The file will be copied to the
--controller-id
- Specifies the Controller ID, a unique identifier of the Controller installation. Agents will be dedicated to the Controller with the given Controller ID.
- The Controller ID is used in the Agent's
private.conf
file to specify which Controller can access a given Agent.
--controller-primary-cert
- Specifies the path to the SSL/TLS certificate of the Primary Controller Instance. The Agent Installer Script extracts the distinguished name from the given certificate and adds it to the Agent's
private.conf
file to allow HTTPS connections from the given Controller using mutual authentication without the need for passwords.
- Specifies the path to the SSL/TLS certificate of the Primary Controller Instance. The Agent Installer Script extracts the distinguished name from the given certificate and adds it to the Agent's
--controller-secondary-cert
- Corresponds to the
--controller-primary-cert
setting and is used for the Secondary Controller Instance.
- Corresponds to the
--http-port
- Specifies the HTTP port that the Agent is operated for. The default value is 4445. The Agent by default makes use of a configuration directory
./var_<http-port>
that will be excluded from a backup taken with the--backup-dir
option. In addition the HTTP port is used to identify the Agent Instance Start Script typically available from./bin/agent_<http-port>.sh
. and to specify the value of theJS7_AGENT_HTTP_PORT
environment variable in the script. - The port can be prefixed by the network interface, for example
localhost:4445
. - When used with the
--restart
switch the HTTP port is used to identify whether the Agent is running.
- Specifies the HTTP port that the Agent is operated for. The default value is 4445. The Agent by default makes use of a configuration directory
--https-port
- Specifies the HTTPS port that the Agent is operated for. The HTTPS port is specified in the Agent Instance Start Script typically available from
./bin/agent_<http-port>.sh
. with the environment variableJS7_AGENT_HTTPS_PORT
. Use of HTTPS requires a keystore and truststore to be present, see--keystore
and--truststore
options. - The port can be prefixed by the network interface, for example
batch.example.com:4445
.
- Specifies the HTTPS port that the Agent is operated for. The HTTPS port is specified in the Agent Instance Start Script typically available from
--pid-file-dir
- Specifies the directory to which the Agent stores its PID file. By default the
<data>/logs
directory is used. - When using SELinux then it is recommended to specify the
/var/run
directory, see JS7 - How to install for SELinux.
- Specifies the directory to which the Agent stores its PID file. By default the
--pid-file-name
- Specifies the name of the PID file. By default the file name
agent.pid
is used. - The PID file is created in the directory specified by the
--pid-file-dir
option.
- Specifies the name of the PID file. By default the file name
--keystore
- Specifies the path to a PKCS12 keystore file that holds the private key and certificate for HTTPS connections to the Agent.
- Users are free to specify any file name, typically the name
https-keystore.p12
is used. The keystore file will be copied to the<config>/private
directory. - If a keystore file is made available then the Agent's
<config>/private/private.conf
file has to hold a reference to the keystore location and optionally the keystore password. It is therefore recommended to use the--private-conf
option to deploy an individualprivate.conf
file that holds settings related to a keystore. - 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 to the Agent using mutual authentication .
- Users are free to specify any file name, typically the name
https-truststore.p12
is used. The truststore file will be copied to the<config>/private
directory. - If a truststore file is made available then the Agent's
<config>/private/private.conf
file has to hold a reference to the truststore location and optionally the truststore password. It is therefore recommended to use the--private-conf
option to deploy an individualprivate.conf
file that holds settings related to a truststore. - 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 the Agent from the
JAVA_HOME
environment variable specified with the Agent Instance Start Script typically available from./bin/agent_<http-port>.sh
.
- Specifies the Java home directory that will be made available to the Agent from the
--java-options
- Specifies the Java options that will be made available to the Agent from the
JAVA_OPTIONS
environment variable specified with the Agent Instance Start Script typically available from./bin/agent_<http-port>.sh
. - Java options can be used for example to specify Java heap space settings for the Agent.
- 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 the Agent from the
--service-dir
- Specifies the systemd service directory to which the Agent'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 Agent'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 will be copied to the Agent's
<home>/bin
directory. Users are free to choose any file name as a template for the service file. The resulting service file name will beagent_<http-port>.service
. - The Agent Installer Script will perform replacements in the service file to update paths and the port to be used, for details see
./bin/agent.service-example
.
- Specifies the path to a systemd service file that acts as a template and that will be copied to the Agent'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_agent_<http-port>
will be used.
- Specifies the name of the systemd service that will be created if the
Switches
-h | --help
- Displays usage.
--show-logs
- Displays the log output created by the script if the
--log-dir
option is used.
- Displays the log output created by the script if the
--make-dirs
- If directories are missing that are indicated with the
--home
,--backup-dir
or--log-dir
options then they will be created.
- If directories are missing that are indicated with the
--make-service
- Specifies that a systemd service should be created for the Agent. The service will be created from the
--service-name
option or its default value.
- Specifies that a systemd service should be created for the Agent. The service will be created from the
--move-libs
- For an existing Agent installation the
lib
sub-directory includes .jar files that carry the release number in their file names. If replaced by a newer version thelib
directory has to be moved or removed. This switch tries to move the directory to a previous version number as indicated from the.version
file in the Agent's home directory, for example to renamelib
tolib.2.3.1
. - Files in the
lib/user_lib
sub-directory are preserved.
- For an existing Agent installation the
--remove-journal
- If Agents have been installed for the wrong operating mode (standalone, clustered) then the Agent's journal in the
JS7_AGENT_DATA/state
directory can be removed. This operation removes any orders submitted to an Agent and requires the Agent to be re-registered to a Controller.
- If Agents have been installed for the wrong operating mode (standalone, clustered) then the Agent's journal in the
--restart
- Stops a running Agent before installation and starts the Agent after installation using the Agent's Instance Start Script. This switch can be used with the
--abort
and--kill
switches to control the way how the Agent is terminated. This switch is ignored if the--exec-start
and--exec-stop
options are used.
- Stops a running Agent before installation and starts the Agent after installation using the Agent's Instance Start Script. This switch can be used with the
--abort
- Aborts a running Agent and kills any running tasks including child processes if used with the
--restart
switch. Aborting an Agent includes to terminate the Agent in an orderly manner that allows to close files consistently.
- Aborts a running Agent and kills any running tasks including child processes if used with the
--kill
- Kills a running Agent and any running tasks if used with the
--restart
switch. This includes killing child processes of running tasks.
- Kills a running Agent and any running tasks if used with the
Exit Codes
1
: argument errors2
: non-recoverable errors3
: this exit code is returned when used with the--restart
switch and if it cannot be identified whether an Agent is running4
: this exit code is returned if no--tarball
option is used and download of the tarball reports errors5
: this exit code is returned when used with the--restart
switch and if the Agent cannot be started6
: this exit code is returned when used with the--restart
switch and if the Agent cannot be stopped7
: this exit code indicates that the Agent systemd service could not be started or stopped when using the--exec-start="StartService"
or--exec-stop="StopService"
options.
Replacements
The Agent Installer Script performs replacements of placeholders in installation files and configuration files by option values, for details see chapter Replacements.
Examples
The following examples illustrate typical use cases. Users should consider to specify current releases, see JS7 - Download.
Install or Update from Download
./js7_install_agent.sh \ --home=/home/sos/agent \ --release=2.3.1 \ --make-dirs # downloads the indicated Agent release and extracts the tarball to the specified Agent home directory # the home directory is created if it does not exist
Install or Update from Tarball
./js7_install_agent.sh \ --home=/home/sos/agent \ --tarball=/mnt/releases/js7/js7_agent_unix.2.3.1.tar.gz # extracts the indicated tarball to the specified Agent home directory
Install or Update and Stop/Start using systemd
./js7_install_agent.sh \ --home=/home/sos/agent \ --tarball=/mnt/releases/js7/js7_agent_unix.2.3.1.tar.gz \ --exec-start="sudo systemctl start js7_agent" \ --exec-stop="sudo systemctl stop js7_agent" # extracts the indicated tarball to the specified Agent home directory # the Agent is started and stopped by use of systemd commands
Install or Update and Restart
./js7_install_agent.sh \ --home=/home/sos/agent \ --tarball=/mnt/releases/js7/js7_agent_unix.2.3.1.tar.gz \ --restart # extracts the indicated tarball to the specified Agent home directory # the Agent is stopped and started from its instance start script
Install or Update with Return Values
retval=/tmp/js7_install_agent.$$.tmp ./js7_install_agent.sh \ --home=/home/sos/agent \ --tarball=/mnt/releases/js7/js7_agent_unix.2.3.1.tar.gz \ --backup-dir=/tmp/backups \ --log-dir=/tmp/logs \ --return-values=$retval log_file=$(cat $retval | grep "log_file" | cut -d'=' -f2) backup_file=$(cat $retval | grep "backup_file" | cut -d'=' -f2) # extracts the indicated tarball to the specified Agent home directory, creates a log file and a backup file # return values include the path to the log file and to the backup file
Install or Update with Fallback
retval=/tmp/js7_install_agent.$$.tmp ./js7_install_agent.sh \ --home=/home/sos/agent \ --tarball=/mnt/releases/js7/js7_agent_unix.2.3.1.tar.gz \ --backup-dir=/tmp/backups \ --log-dir=/tmp/logs \ --return-values=$retval \ --restart \ --show-logs \ --make-dirs \ || ( backup=$(cat $retval | grep "backup_file" | cut -d'=' -f2 ) \ && ( test -e "$backup" ) && \ ./js7_install_agent.sh \ --home=/home/sos/agent \ --tarball=$backup \ --log-dir=/tmp/logs \ --restart \ --show-logs ) log_file=$(cat $retval | grep "log_file" | cut -d'=' -f2) backup_file=$(cat $retval | grep "backup_file" | cut -d'=' -f2) # extracts the indicated tarball to the specified Agent home directory, creates a backup file and a log file and restarts the Agent # should installation fail then it is reverted from the backup file
Install or Update and Apply Certificates
./js7_install_agent.sh \ --home=/home/sos/agent \ --tarball=/mnt/releases/js7/js7_agent_unix.2.3.1.tar.gz \ --http-port=localhost:4445 \ --https-port=batch.example.com:4445 \ --java-options="-Xms64m -Xmx256m" \ --agent-conf=/home/sos/agent-deployment/agent.conf \ --private-conf=/home/sos/agent-deployment/private.conf \ --keystore=/home/sos/agent-deployment/https-keystore.p12 \ --truststore=/home/sos/agent-deployment/https-truststore.p12 \ --make-dirs # extracts the indicated tarball to the specified Agent home directory # runs the Agent for HTTP port 4445 on the localhost network interface and the same HTTPS port on the server network interface # deploys global and private Agent configuration files that hold references to keystore and truststore # deploys keystore and truststore files
Patch from Download
./js7_install_agent.sh \ --home=/home/sos/agent \ --release=2.3.1 \ --patch=JS-1984 # downloads the indicated Agent patch and extracts the tarball to the specified Agent home directory # the patch is stored to the Agent's lib/patches sub-directory
Patch from Tarball
./js7_install_agent.sh \ --home=/home/sos/agent \ --tarball=/mnt/releases/js7/js7_agent_unix.2.3.1.JS-1984.tar.gz \ --patch=JS-1984 # extracts the indicated patch tarball to the specified Agent home directory # the patch is stored to the Agent's lib/patches sub-directory
Replacements
The Agent Installer Script performs replacements of placeholders in installation files and configuration files by option values.
Installation files
<home>/bin/agent_<http-port>.sh
Replacements are performed for the following placeholders used for environment variables by respective option values:
Placeholder Option Value JS7_AGENT_HOME
--home
JS7_AGENT_DATA
--data
JS7_AGENT_USER
--user
JS7_AGENT_HTTP_PORT
--http-port
JS7_AGENT_HTTPS_PORT
--https-port
JS7_AGENT_CONFIG_DIR
--config
JS7_AGENT_LOGS
--logs
JS7_AGENT_WORK_DIR
--work
JS7_AGENT_PID_FILE_DIR
--pid-file-dir
JS7_AGENT_PID_FILE_NAME
--pid-file-name
JAVA_HOME
--java-home
JAVA_OPTIONS
--java-options
<home>/bin/agent_<http-port>.service
Replacements are performed for the following placeholders by respective option values:
Placeholder Option Value <JS7_AGENT_HTTP_PORT>
--http-port
PIDFile=
--pid-file-dir
User=
--user
ExecStart=, ExecStop=, ExecReload=
--home
Configuration files
<config>/private/private.conf
Replacements are performed for the following placeholders by respective option values:
Placeholder Option Value {{controller-id}}
--controller-id
{{controller-primary-distinguished-name}}
--controller-primary-cert
{{controller-secondary-distinguished-name}}
--controller-secondary-cert
{{keystore-file}}
--keystore
{{keystore-password}}
--keystore-password
{{keystore-alias}}
--keystore-alias
{{truststore-file}}
--truststore
{{truststore-password}}
--truststore-password
Find a template for a
private.conf
file using placeholders for HTTPS mutual authentication:
Automation from a Job
The Agent Installer Script can be executed from a job for automated update and upgrade of JS7 Agents.
Add Workflow from Example
Download Workflow (upload .json): pdUpdateAgent.workflow.json
When uploading the example the workflow should look like this:
Explanation:
- The above sample can be uploaded to create the workflow including the job
- Alternatively a new workflow can be created and the Wizard, which can be started using a button in the upper right hand corner of the screenshot, can be used.
Add SSHJob from Wizard
Invoking the Wizard brings forward the following popup window:
When selecting the SSHJob and using the Next button the following popup window is displayed that provides a list of available arguments:
Explanation:
- The job basically makes use of the following arguments:
- Connection
- host: specifies the host name or IP address of the remote host.
- port: specifies the SSH port on the remote host, defaults to 22.
- Authentication
- user: specifies the user account used to login with the remote host.
- auth_method: is one of
password
orpublickey
. - auth_file: specifies the path to identify the file that holds the private key for use with the
publickey
authentication method. A relative path is specified, see the descriptions below.
- Command Execution
- command_script_file: specifies the path to the Agent Installer Script that should be executed on the remote host.
- The indicated path
./config/js7_install_agent.sh
starts from the Agents working directory that holds theconfig
sub-directory. The working directory by defaults uses the namevar_<port>
, for examplevar_4445
, for the HTTP port for which the Agent is operated. This directory can be specified during JS7 - Agent Installation On Premises and JS7 - Agent Installation for Docker Containers. - The SSHJob transfers the Agent Installer Script to the remote host.
- The indicated path
- command_script_param: specifies the arguments used when invoking the Agent Installer Script.
- A typical parameterization can look like this:
--home=/home/sos/agent --tarball=/mnt/releases/js7/js7_agent_unix.2.3.1.tar.gz --log-dir=/tmp/logs --show-logs --make-dirs
- A typical parameterization can look like this:
- command_script_file: specifies the path to the Agent Installer Script that should be executed on the remote host.
- Connection
- More information about parameterization of the job can be found in the JS7 - JITL SSHJob article.
Automation for Mass-rollout
Users who operate larger numbers of Agents can extend the above solution to use a single workflow to perform mass-rollout of Agents.
Add Workflow from Example
Download Workflow (upload .json): pdUpdateAgents.workflow.json
When uploading the example the workflow should look like this:
Explanation:
- The example makes use of the JS7 - ForkList-Join Instruction that allows specification of a single branch with any number of jobs and additional instructions. Orders can carry variable sets that are used to parameterize the ForkList Instruction. For each variable set the ForkList Instruction dynamically creates a new branch at run-time. This allows parallelism for updates and upgrades of Agents.
- The workflow declares the variable set from the example above as follows:
- Name of List Variable: the name
agent
is used and the datatypelist
is selected to indicate a Variable Set. - Name of Variable: Additional variables are added such as
agent_name
,host
,port
that will be populated when adding an order to the workflow.- Later on the variables are assigned the SSHJob to connect to the relevant host and port.
- One of the variables declared must hold a unique value, for example the
agent_name
, that allows identification of a Variable Set.
- Name of List Variable: the name
When clicking the ForkList Instruction then the instruction's properties are displayed as shown in this screenshot:
Explanation:
- The ForkList Instruction is assigned the List Variable that is declared with the workflow.
- One of the elements of the List Variable is selected and is used to create a unique branch for each Variable Set carried by the order.
Add SSHJob
Basically the same explanations apply for the SSHJob as stated in the Add SSHJob from Wizard section above.
The difference lies in the use of different hosts and ports when connecting to remote machines to update or to upgrade Agents:
Explanation:
- The following job arguments use variables instead of constant values:
- host: specifies the host name or IP address of the remote host. The argument is assigned the
$host
variable from the Variable Set. - port: specifies the SSH port on the remote host, defaults to 22. The argument is assigned the
$port
variable from the Variable Set.
- host: specifies the host name or IP address of the remote host. The argument is assigned the
- The assumptions in this example include:
- the same user account and private key can be used for connections to any hosts on which Agents are to be updated or upgraded,
- the same parameterization can be used - for example, the same location of the Agent's home directory - for the Agent Installer Script on any host.
- Users to whom these assumptions do not apply should consider adding relevant variables for the auth_file and command_script_param arguments to their Variable Set.
The Job Options tab of the job property window should be used to allow parallelism of job execution:
- Users should specify the maximum number of parallel executions. Running updates for 100 and more Agents at the same time is a typical use case.
- Resource consumption of the SSHJob preferably is about main memory as the job runs within an Agent's Java Virtual Machine.
- It is safe to assume a maximum of 24 MB main memory consumption per instance of the SSHJob.
- Should more memory be required then heap space settings have to be increased when starting the Agent, see JS7 - How To - Apply Java Options for more information.
Add Schedule
A Schedule is created for automated execution of the workflow.
- The Schedule specifies:
- the Workflow from the example above to which an order should be added,
- any number of Variable Sets that carry variables for the hosts on which Agents are to be updated and upgraded,
- the point in time when the order should be started.
- For details see the JS7 - Schedules article.
Explanation:
- The Schedule allows the addition of any number of Variable Sets to a single order.
- The Variable Set is declared from the Workflow and is considered by the Schedule.
- Note that both checkboxes should not be selected:
- Plan Order automatically,
- Submit Order to Controller when planned.
- Users often do not want to update or upgrade Agents at regular intervals according to a calendar. Instead, this Schedule is intended to be used for manually adding an order to update or upgrade Agents at a given date.
- A number of Schedules can be used to manage groups of Agents that are to be updated or upgraded at a common point in time.
When operating a larger number of JS7 Agents then it is an option to automate the management of Schedules.
- The JS7 - REST Web Service API allows creation and population of Schedules.
- This can also be achieved using the JS7 - PowerShell Module which allows generation and management of schedules with a few lines of script code.
Add Order from Schedule to Daily Plan
Starting from the fact that the previously introduced Schedule is not automatically applied by the JS7 - Daily Plan Service this Schedule is used to manually create Daily Plan entries.
- In the JS7 - Daily Plan view the button Create Daily Plan can be used to add orders from a Schedule for the date selected with the calendar.
- In the popup window that is brought forward when clicking the Create Daily Plan button users should select the Schedule as shown here:
From the previously introduced Schedule a single order is created that carries a number of Variable Sets for hosts on which to update or upgrade Agents.
Control Order Execution
The Workflows view allows monitoring and control of orders for updating or upgrading Agents:
- From the screenshot a single parent order is visible in yellow-greenish color.
- A child order is created for each Variable Set of the parent order. Child orders run in parallel in individual branches that are dynamically created by the ForkList Instruction.
Further Resources
- JS7 - Automated Update of Controller
- JS7 - Automated Update of JOC Cockpit
- JS7 - How to create self-signed Certificates
- JS7 - How to add SSL TLS Certificates to Keystore and Truststore
- JS7 - ForkList-Join Instruction