Introduction
This article explains configuration items available for Standalone Agents, Director Agents and Subagents in a JS7 - Agent Cluster.
- An Agent makes use of two configuration files:
- the general configuration file
agent.conf
general configuration file which is available from found in the following locations:- Windows:
C:\ProgramData\sos-berlin.com\js7\agent\var\config\agent.conf
- Unix
/var/sos-berlin.com/js7/agent/var/config/agent.conf
- the security configuration file
private.conf
security configuration file which is available from found in the following locations:
- Windows:
C:\ProgramData\sos-berlin.com\js7\agent\var\config\private.conf
- Unix:
/var/sos-berlin.com/js7/agent/var/config/private/private.conf
- The configuration format makes use of Typesafe Config,
see file - For HTTPS configuration refer to the JS7 - Configuration Templates article.
Default Configuration
General Configuration File: agent.conf
Anchor |
---|
| js7-web-server-auth-public |
---|
| js7-web-server-auth-public |
---|
|
...
HTTP
...
Connections
By default the Agent configuration ships with HTTP communication connections enabled. It is recommended that public/private keys and certificates for secure HTTPS communication are created used and that HTTP communication is connections are disabled.
Code Block |
---|
language | text |
---|
title | Default configuration: enable HTTP communicationconnections |
---|
linenumbers | true |
---|
|
# Allow http connections without authentication
js7.web.server.auth.public = true
|
Security Configuration File: private.conf
...
js7 | web | server |
|
|
|
---|
|
|
| auth | public | true | false |
- This setting specifies public access to an Agent if incoming HTTP connections are to be used. If used with a value
true
then authentication is not applied. - Default:
true
Anchor |
---|
| js7-journal-cluster |
---|
| js7-journal-cluster |
---|
|
Director Agent Cluster ConfigurationIf a JS7 - Agent Cluster is used then the following configuration has to be applied for Director Agent instances:
Primary Director Agent Instance Configuration
The Agent requires X.509 certificates and/or PGP public keys to be in place. These are used to verify the signatures of signed workflows. Unsigned workflows are not accepted by an Agent, therefore a minimum of one X.509 certificate file or PGP public key file has to be present in the directories that are specified with the following configuration item:
Code Block |
---|
language | text |
---|
title | Primary Director Agent instance general configuration file example: agent.conf |
---|
linenumbers | true |
---|
collapse | true |
---|
|
# Cluster configuration: not required
|
- A Primary Director Agent instance does not require any configuration items for cluster operation.
Secondary Director Agent Instance Configuration
Code Block |
---|
language | text |
---|
title | Secondary Director Agent Instance general configuration file example: agent.confDefault configuration: assign directories for trusted certificates |
---|
linenumbers | true |
---|
collapse | true |
---|
|
# SecurityCluster configuration
js7.journal.cluster {
configurationnode {
#is-backup Locations= ofyes
certificates and public keys used for signature verification
trusted-signature-keys {
PGP=${js7.config-directory}"/private/trusted-pgp-keys"
X509=${js7.config-directory}"/private/trusted-x509-keys"
}
}
|
Explanation:
- The Agent verifies the signature of deployable objects such as workflows. This can be performed for PGP signatures and for X.509 signatures.
- The
trusted-signature-keys
setting specifies the location of PGP public keys and X.509 certificates. - If no PGP public keys are used or if no X.509 certificates are used then the respective setting should not be used as it expects the indicated directory to be populated with public keys or certificates respectively.
...
- A Secondary Director Agent instance specifies this setting to indicate that the instance starts as a standby node (Backup). When this setting is not in place, both instances of a Director Agent Cluster will start as standalone instances.
- This setting is relevant for initial operation only. It is independent of which Director Agent instance later on will be the active one and which instance will be the standby one.
- This setting has to be added before starting a Secondary Director Agent instance.
js7 | journal | cluster |
|
|
|
---|
|
|
| node |
|
|
|
|
|
| Primary | <url> |
|
|
|
| Backup | <url> |
|
|
|
| is-backup | yes|no |
- This setting is used for Director Agent instances in cluster mode only, it is not used for standalone Director Agent instances.
- The registration of Primary and Secondary Director Agent instances is performed by the JOC Cockpit during initial operation.
- Therefore the only setting required for cluster operation is:
js7.journal.cluster.node.is-backup=yes
: For a Secondary Director Agent instance this setting specifies that during initial operation the given instance will be the inactive standby node.
- Additional settings can be applied. However, we recommend that the JOC Cockpit is used instead.
nodes
Primary, Backup
: For a Primary Director Agent instance this setting specifies the URLs of the Primary
and Backup
(Secondary) instance. The URL includes specification of the http/https protocol, the hostname and port.
Security Configuration File: private.conf
Anchor |
---|
| js7-configuration-trusted-signature-keys |
---|
| js7-configuration-trusted-signature-keys |
---|
|
Directory for Trusted Certificates used to verify Signed Workflow SignaturesThe Agent requires X.509 certificates and/or PGP public keys to be in place. These are used to verify the signatures of signed workflows. Unsigned workflows are not accepted by an Agent and therefore a minimum of one X.509 certificate file or PGP public key file has to be present in the directories which are specified in the following configuration item:
Code Block |
---|
language | text |
---|
title | Default configuration: assign directories for trusted certificates |
---|
linenumbers | true |
---|
|
# Security configuration
js7 {
configuration |
The default Agent configuration allows job scripts to be executed from any location. Without this setting scripts are restricted to being executed from the config/executables
directory only.
Code Block |
---|
language | text |
---|
title | Default configuration: enable script execution from signed workflows |
---|
linenumbers | true |
---|
|
# Allow http connections without authentication
js7.job.execution.signed-script-injection-allowed = yes
|
Secure Configuration
It is essential that the connections between Controller and Agents are secured. This includes
- to use HTTPS connections that are secured by private keys and certificates,
- to apply mutual authentication between Controller and Agent.
Code Block |
---|
language | text |
---|
title | Secure configuration example: private.conf |
---|
linenumbers | true |
---|
collapse | true |
---|
|
# Security configuration
js7 {
auth {
# User accounts for https connections
users {
# Controller account for connections by primary/secondary Controller instance
Controller {
# Locations of certificates and public keys used for signature distinguished-names=[verification
trusted-signature-keys {
"DNQ=SOS CA, CN=controller-2-0-primary, OU=IT, O=SOS, L=Berlin, ST=Berlin, C=DE", PGP=${js7.config-directory}"/private/trusted-pgp-keys"
"DNQ=SOS CA, CN=controller-2-0-secondary, OU=IT, O=SOS, L=Berlin, ST=Berlin, C=DE"
X509=${js7.config-directory}"/private/trusted-x509-keys"
]
}
}
}
configuration {
# Locations of certificates and public keys used for signature verification
trusted-signature-keys {
PGP=${js7.config-directory}"/private/trusted-pgp-keys"
X509=${js7.config-directory}"/private/trusted-x509-keys"
}
}
job {
# Enable script execution from signed workflows
execution {
}
|
Explanation:
- The Agent verifies signatures of scheduling objects such as workflows during deployment. This can be performed for PGP and X.509 signatures.
- The
trusted-signature-keys
setting specifies the location of PGP public keys and X.509 certificates. - If no PGP public keys are used or if no X.509 certificates are used then this setting should not be used as it expects the indicated directory to be populated with public keys or certificates respectively.
Anchor |
---|
| js7-job-execution-signed-script-injection-allowed |
---|
| js7-job-execution-signed-script-injection-allowed |
---|
|
Script Execution from Signed WorkflowsThe default Agent configuration allows job scripts which include shell commands to be executed from any location. Without this setting scripts are restricted to being executed from the Agent's config/executables
directory only.
Code Block |
---|
language | text |
---|
title | Default configuration: enable script execution from signed workflows |
---|
linenumbers | true |
---|
|
# Allow jobs from signed workflows to execute shell commands
js7.job.execution.signed-script-injection-allowed = yes
|
Secure Configuration
It is essential that the connections between Controller and Agents and between Director Agents and Subagents are secured. This includes:
- using HTTPS connections which are secured by private keys and certificates,
- using authentication between JS7 products:
- Option 1 (recommended):
- applying TLS mutual authentication between Controller and Agent,
- applying TLS mutual authentication between Director Agent instances and Subagents in an Agent Cluster.
- Option 2:
- applying password authentication between JS7 products should mutual authentication not be in place.
Find examples of private.conf
files for Agent configuration for download:
- Standalone Agent
- Agent Cluster
Standalone Agent Configuration
Find an example for download: private.conf-example-standalone-agent
Client Authentication with Controller
Consider that client authentication is an alternative to Password Authentication with Controller.
Anchor |
---|
| js7-auth-users-Controller |
---|
| js7-auth-users-Controller |
---|
|
Controller Connections Code Block |
---|
language | yml |
---|
linenumbers | true |
---|
|
js7 {
auth {
}
}
web {
# Locations of keystore and truststore files for HTTPS connections
https {
keystore {
# Default: ${js7.config-directory}"/private/https-keystore.p12"
file=${js7.config-directory}"/private/https-keystore.p12"
key-password=jobscheduler
store-password=jobscheduler
}
truststores=[
{
# Default: ${js7.config-directory}"/private/https-truststore.p12"
# User accounts for https connections
file=${js7.config-directory}"/private/https-truststore.p12" users {
# Controller ID for connections by primary/secondary Controller store-password=jobschedulerinstance
Controller {
}
]
distinguished-names=[
}
}
}
|
Client Authentication
...
Code Block |
---|
language | yml |
---|
linenumbers | true |
---|
|
js7 {
auth {"DNQ=SOS CA, CN=controller-2-0-primary, OU=IT, O=SOS, L=Berlin, ST=Berlin, C=DE",
# User accounts for https connections
users {
"DNQ=SOS CA, CN=controller-2-0-secondary, OU=IT, O=SOS, L=Berlin, ST=Berlin, C=DE"
# Controller account for connections by primary/secondary Controller instance]
Controller {}
}
distinguished-names=[
"DNQ=SOS CA, CN=controller-2-0-primary, OU=IT, O=SOS, L=Berlin, ST=Berlin, C=DE",
"DNQ=SOS CA, CN=controller-2-0-secondary, OU=IT, O=SOS, L=Berlin, ST=Berlin, C=DE"
]
}
}
}
} |
Explanation:
- This setting applies to use of an Agent with a solo Controller or with a Controller Cluster.
- This setting specifies the distinguished name indicated with the Controller's Client Authentication certificate. The certificate acts as a replacement for a password.
- The Agent configuration specifies the distinguished names of any Controllers that access the Agent by use of a Client Authentication certificate.
- Consider that the common name (CN) setting in the distinguished name has to match the fully qualified domain name (FQDN) of a Controller's host.
Server Authentication
...
Explanation:
- This setting applies to the use of an Agent with a Standalone Controller or with a Controller Cluster.
- Note that the
Controller
element name is an example that has to be replaced by the Controller ID which is specified with the same value during installation of Controller instances. - The
distinguished-names
element identifies the Controller instance's Client Authentication certificate. The certificate acts as a replacement for a password.
Password Authentication with Controller
Consider that password authentication is an alternative to Client Authentication with Controller.
Anchor |
---|
| js7-auth-users-password-Controller |
---|
| js7-auth-users-password-Controller |
---|
|
Controller Connections Code Block |
---|
language | yml |
---|
linenumbers | true |
---|
|
js7 {
auth {
# User accounts for https connections
users {
# Controller ID for connections by primary/secondary Controller instance
Controller {
password="plain:secret"
# password="sha512:bd2b1aaf7ef4f09be9f52ce2d8d599674d81aa9d6a4421696dc4d93dd0619d682ce56b4d64a9ef097761ced99e0f67265b5f76085e5b0ee7ca4696b2ad6fe2b2" }
}
}
} |
Explanation:
- This setting applies to use of an Agent with a Standalone Controller or with a Controller Cluster.
- Note that the
Controller
element name is an example that has to be replaced by the Controller ID which is specified with the same value during installation of both cluster Controller instances. - This setting specifies the
password
indicated with the Controller instance's js7.auth.agents
configuration item. Passwords should be quoted.- The password can be specified as plain text preceded by
plain:
. - The password can be specified as a hashed value preceded by
sha512:
.- There are a number of ways to create sha512 hash values from passwords.
- One possible solution includes using:
echo -n "secret" | openssl dgst -sha512
Director Agent Configuration
The following configuration applies to use of a Director Agent in a JS7 - Agent Cluster.
A single Director Agent instance and a Director Agent Cluster of two instances can be used. For a single Director Agent instance the explanations provided for the Primary Director Agent apply, settings related to a Secondary Director Agent should be omitted.
Find examples for download:
Client Authentication with Controller
Consider that client authentication is an alternative to Password Authentication with Controller.
The same settings apply as explained for Standalone Agents, see Client Authentication with Controller.
Client Authentication with pairing Director Agent Instance
Consider that client authentication an alternative to Password Authentication with pairing Director Agent Instance.
Anchor |
---|
| js7-auth-users-Director |
---|
| js7-auth-users-Director |
---|
|
Director Agent Connections Code Block |
---|
language | yml |
---|
linenumbers | true |
---|
|
js7 {
auth {
# User accounts for https connections
users {
# Subagent ID of pairing Director Agent instance
subagent-id {
permissions = [ AgentDirector ]
distinguished-names=[
"DNQ=SOS CA, CN=director-2-0-secondary, OU=IT, O=SOS, L=Berlin, ST=Berlin, C=DE"
]
}
}
}
} |
Explanation:
- This setting applies to use of the Subagent component within a Director Agent instance in a JS7 - Agent Cluster.
- Note that the
subagent-id
element name is an example that has to be replaced by the Subagent ID of the pairing Director Agent instance which is specified during configuration of the Agent Cluster. This is not the Agent Cluster ID. For the private.conf
file of a Primary Director Agent instance this setting holds the Subagent ID of the Secondary Director Agent instance and vice versa. - The
permissions
element should be used as indicated. - The
distinguished-names
element identifies the pairing Director Agent instance's Client Authentication certificate. The certificate acts as a replacement for a password.
Password Authentication with Controller
Consider that password authentication is an alternative to Client Authentication with Controller.
The same settings apply as explained for Standalone Agents, see Password Authentication with Controller.
Password Authentication with pairing Director Agent Instance
Consider that password authentication is an alternative to Client Authentication with pairing Director Agent Instance.
Anchor |
---|
| js7-auth-users-password-Director |
---|
| js7-auth-users-password-Director |
---|
|
Director Agent Connections Code Block |
---|
language | yml |
---|
linenumbers | true |
---|
|
js7 {
auth {
# User accounts for https connections
users {
# Subagent ID of pairing Director Agent instance
subagent-id {
permissions = [ AgentDirector ]
password="plain:secret"
# password="sha512:bd2b1aaf7ef4f09be9f52ce2d8d599674d81aa9d6a4421696dc4d93dd0619d682ce56b4d64a9ef097761ced99e0f67265b5f76085e5b0ee7ca4696b2ad6fe2b2" }
}
}
} |
Explanation:
- This setting applies to use of a Subagent within a Director Agent instance in an JS7 - Agent Cluster.
- Note that the
subagent-id
element name is an example that has to be replaced by the Subagent ID of the pairing Director Agent instance which is specified during configuration of the Agent Cluster. This is not the Agent Cluster ID. For the private.conf
file of a Primary Director Agent instance this setting holds the Subagent ID of the Secondary Director Agent instance and vice versa. - The
permissions
element should be used as indicated. - The
password
element specifies the password indicated with the pairing Director Agent instance's js7.auth.subagents
configuration item. Passwords should be quoted.- The password can be specified as plain text preceded by
plain:
. - The password can be specified as a hashed value preceded by
sha512:
.- There are a number of ways to create sha512 hash values from passwords.
- One possible solution includes using:
echo -n "secret" | openssl dgst -sha512
Anchor |
---|
| js7-auth-users-password-Director |
---|
| js7-auth-users-password-Director |
---|
|
Subagent Connections Code Block |
---|
language | yml |
---|
linenumbers | true |
---|
|
js7 {
auth {
# for each Subagent specify the Subagent ID and password
subagents {
director-primary = "plain:secret-director-primary"
director-secondary = "plain:secret-director-secondary"
subagent-001 = "plain:secret-subagent-001"
subagent-002 = "plain:secret-subagent-002"
subagent-003 = "plain:secret-subagent-003"
}
}
} |
Explanation:
- This setting applies to connections to a Subagent of a pairing Director Agent instance in a JS7 - Agent Cluster and to connections to any Subagents.
- Note that the
director-primary
, director-secondary
element names are examples that have to be replaced by the Subagent ID of the pairing Director Agent instance which is specified during configuration of the Agent Cluster. This is not the Agent Cluster ID. - Note that the
subagent-001
, subagent-002, ...
element names are examples for Subagent IDs of connected Subagents. - The
password
element specifies the password indicated with the pairing Director Agent instance's and any Subagent's js7.auth.users.<subagent-id>.password
configuration item. Passwords should be quoted.
- The password must be specified as plain text preceded by
plain:
.
Subagent Configuration
The following configuration applies to use of Subagents in a JS7 - Agent Cluster.
Find an example for download: private.conf-example-subagent
Client Authentication with Director Agent Instances
Consider that client authentication an alternative to Password Authentication with Director Agent Instances.
Anchor |
---|
| js7-auth-users-Subagent |
---|
| js7-auth-users-Subagent |
---|
|
Director Agent Connections Code Block |
---|
language | yml |
---|
linenumbers | true |
---|
|
js7 {
auth {
# User accounts for https connections
users {
# Subagent ID of Primary Director Agent instance
director-primary {
permissions = [ AgentDirector ]
distinguished-names=[
"DNQ=SOS CA, CN=director-2-0-primary, OU=IT, O=SOS, L=Berlin, ST=Berlin, C=DE"
]
}
# Subagent ID of Secondary Director Agent instance
director-secondary {
permissions = [ AgentDirector ]
distinguished-names=[
"DNQ=SOS CA, CN=director-2-0-secondary, OU=IT, O=SOS, L=Berlin, ST=Berlin, C=DE"
]
}
}
}
} |
Explanation:
- This setting applies to connections from Director Agent instances to the current Subagent in a JS7 - Agent Cluster.
- Note that the
director-primary, director-secondary
element names are examples that have to be replaced by the Subagent ID of the respective Director Agent instance which is specified during configuration of the Agent Cluster. - The
permissions
element should be used as indicated. - The
distinguished-names
element identifies the Director Agent instance's Client Authentication certificate. The certificate acts as a replacement for a password.
Password Authentication with Director Agent Instances
Consider that password authentication is an alternative to Client Authentication with Director Agent Instances.
Anchor |
---|
| js7-auth-users-password-Subagent |
---|
| js7-auth-users-password-Subagent |
---|
|
Director Agent Connections Code Block |
---|
language | yml |
---|
linenumbers | true |
---|
|
js7 {
auth {
# User accounts for https connections
users {
# Subagent ID of Primary Director Agent instance
director-primary {
permissions = [ AgentDirector ]
password = "plain:secret-director-primary"
# password = "sha512:308769d726e2b1e69530ac631d8ac8f26c67ae6bda1dfca41b523ac8ab7b9745a2e62750f183c9e3046e45106b402fef1ad5746365a0ccc24004776ed74a9160" }
# Subagent ID of Secondary Director Agent instance
director-secondary {
permissions = [ AgentDirector ]
password = "plain:secret-director-secondary"
# password = "sha512:5419dfceee6a3081f4d3aee95a7e5cdddb078b6753db77bfbebba05e6b0140aeb11cfa59b56b07ac78389c0918652b57e3bc7aa333c94d74362d5ca7f7166888" }
}
}
} |
Explanation:
- This setting applies to the connection from Director Agent instances to the current Subagent in an JS7 - Agent Cluster.
- Note that the
director-primary, director-secondary
element names are examples that have to be replaced by the Subagent ID of the respective Director Agent instance which is specified during configuration of the Agent Cluster. - The
permissions
element should be used as indicated. - The
password
element specifies the password indicated with the respective Director Agent instance's js7.auth.subagents
configuration item. Passwords should be quoted.- The password can be specified as plain text preceded by
plain:
. - The password can be specified as a hashed value preceded by
sha512:
.- There are a number of ways to create sha512 hash values from passwords.
- One possible solution includes using:
echo -n "secret-director-primary" | openssl dgst -sha512
Keystore and Truststore
Settings in this section apply to any of Standalone Agents, Director Agent instances and Subagents.
Anchor |
---|
| js7-web-https-keystore |
---|
| js7-web-https-keystore |
---|
|
HTTPS Keystore and Truststore Access Code Block |
---|
language | yml |
---|
linenumbers | true |
---|
|
js7 {
web {
# keystore and truststore location for https connections
https {
client-keystore {
# Default: ${js7.config-directory}"/private/https-client-keystore.p12"
file=${js7.config-directory}"/private/https-client-keystore.p12"
key-password="jobscheduler"
store-password="jobscheduler"
}
keystore {
# Default: ${js7.config-directory}"/private/https-keystore.p12"
file=${js7.config-directory}"/private/https-keystore.p12"
key-password="jobscheduler"
store-password="jobscheduler"
# alias=
}
truststores=[
{
# Default: ${js7.config-directory}"/private/https-truststore.p12"
file=${js7.config-directory}"/private/https-truststore.p12"
store-password="jobscheduler"
# alias=
}
]
}
}
} |
Explanation:
- HTTPS keystore and truststores are used to hold private keys and certificates.
- Keystore and truststore settings accept the path to a file in PKCS12 format or in PEM format.
- The keystore holds the Agent's private key and certificate. This information is used:
- for Server Authentication with JOC Cockpit and
- for Client Authentication with Agents.
- The truststore holds the certificate(s) used to verify:
- Client Authentication certificates presented by a Controller and
- Server Authentication certificates challenged by pairing Controllers.
- A number of truststores can be specified.
- Optionally a separate HTTPS client keystore can be used:
- The client keystore is used for TLS mutual authentication and holds a private key and certificate created for
Client Auth
extended key usage. - When using TLS mutual authentication then:
- a single certificate can be used that is generated for both
Server Auth
and Client Auth
extended key use. In this case do not use the HTTPS client keystore but use the HTTPS keystore to hold the certificate. - separate certificates can be used with the certificate for
Server Auth
key usage being stored with the HTTPS keystore and the certificate for Client Auth
key use being stored with the HTTPS client keystore.
- For details see
Jira |
---|
server | SOS JIRA |
---|
columns | key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution |
---|
serverId | 6dc67751-9d67-34cd-985b-194a8cdc9602 |
---|
key | JS-1959 |
---|
|
- Keystore and Truststore locations are specified. In addition:
- a password for the private keys included in the keystore and a password for access to the keystore can be specified,
- for the truststore a password for access to the truststore can be specified.
- Passwords for keystore and truststore are not intended for security of the configuration, they are used to verify the integrity of certificate stores as the password used for creating and reading the certificate store must be the same.
- The
key-password
is used for access to a private key in a keystore. - The
store-password
setting is used for access to a keystore or to a truststore. - For PKCS12 keystores both settings have to use the same value. The settings can be omitted if no passwords are used.
- The
alias
setting can be used for example with a keystore that holds a number of private keys from which the relevant private key is selected by its alias name.
Summary of Configuration Items
General Configuration File: agent.conf
js7.web.server: Authentication Settings
js7 | web | server |
|
|
|
---|
|
|
| auth | public | true | false |
- This setting specifies public access to an Agent if incoming HTTP connections are to be used. If used with a value
true
then no authentication is applied. - Default:
true
js7.job.execution: Job Script Encoding
js7 | job | execution |
|
|
---|
|
|
| encoding | <MIME-Type > |
- This setting specifies the code page to be used if Agents are operated for Windows. For details see JS7 - Unicode Support.
The following code pages are automatically detected and used, they do not require the above setting:
Code Block |
---|
title | List of supported codepages |
---|
collapse | true |
---|
|
js7.windows.codepages {
37 = "IBM037" # IBM EBCDIC US-Canada
437 = "IBM437" # OEM United States
737 = "x-IBM737" # ibm737 OEM Greek (formerly 437G); Greek (DOS)
775 = "IBM775" # ibm775 OEM Baltic; Baltic (DOS)
850 = "IBM850" # ibm850 OEM Multilingual Latin 1; Western European (DOS)
852 = "IBM852" # ibm852 OEM Latin 2; Central European (DOS)
855 = "IBM855" # OEM Cyrillic (primarily Russian)
857 = "IBM857" # ibm857 OEM Turkish; Turkish (DOS)
858 = "IBM00858" # OEM Multilingual Latin 1 + Euro symbol
860 = "IBM860" # OEM Portuguese; Portuguese (DOS)
861 = "IBM861" # ibm861 OEM Icelandic; Icelandic (DOS)
862 = "IBM862" # DOS-862 OEM Hebrew; Hebrew (DOS)
863 = "IBM863" # OEM French Canadian; French Canadian (DOS)
864 = "IBM864" # OEM Arabic; Arabic (864)
865 = "IBM865" # OEM Nordic; Nordic (DOS)
866 = "IBM866" # cp866 OEM Russian; Cyrillic (DOS)
869 = "IBM869" # ibm869 OEM Modern Greek; Greek, Modern (DOS)
870 = "IBM870" # IBM EBCDIC Multilingual/ROECE (Latin 2); IBM EBCDIC Multilingual Latin 2
874 = "x-IBM874" # windows-874 Thai (Windows)
875 = "x-IBM875" # cp875 IBM EBCDIC Greek Modern
932 = "shift_jis" # shift_jis ANSI/OEM Japanese; Japanese (Shift-JIS)
949 = "x-windows-949" # ks_c_5601-1987 ANSI/OEM Korean (Unified Hangul Code)
950 = "x-windows-950" # big5 ANSI/OEM Traditional Chinese (Taiwan; Hong Kong SAR, PRC); Chinese Traditional (Big5)
1026 = "IBM1026" # IBM EBCDIC Turkish (Latin 5)
1047 = "IBM1047" # IBM EBCDIC Latin 1/Open System
1140 = "IBM01140" # IBM EBCDIC US-Canada (037 + Euro symbol); IBM EBCDIC (US-Canada-Euro)
1141 = "IBM01141" # IBM EBCDIC Germany (20273 + Euro symbol); IBM EBCDIC (Germany-Euro)
1142 = "IBM01142" # IBM EBCDIC Denmark-Norway (20277 + Euro symbol); IBM EBCDIC (Denmark-Norway-Euro)
1143 = "IBM01143" # IBM EBCDIC Finland-Sweden (20278 + Euro symbol); IBM EBCDIC (Finland-Sweden-Euro)
1144 = "IBM01144" # IBM EBCDIC Italy (20280 + Euro symbol); IBM EBCDIC (Italy-Euro)
1145 = "IBM01145" # IBM EBCDIC Latin America-Spain (20284 + Euro symbol); IBM EBCDIC (Spain-Euro)
1146 = "IBM01146" # IBM EBCDIC United Kingdom (20285 + Euro symbol); IBM EBCDIC (UK-Euro)
1147 = "IBM01147" # IBM EBCDIC France (20297 + Euro symbol); IBM EBCDIC (France-Euro)
1148 = "IBM01148" # IBM EBCDIC International (500 + Euro symbol); IBM EBCDIC (International-Euro)
1149 = "IBM01149" # IBM EBCDIC Icelandic (20871 + Euro symbol); IBM EBCDIC (Icelandic-Euro)
1200 = "UTF-16LE" # utf-16 Unicode UTF-16, little endian byte order (BMP of ISO 10646); available only to managed applications
1201 = "UTF-16BE" # unicodeFFFE Unicode UTF-16, big endian byte order; available only to managed applications
1250 = "windows-1250" # windows-1250 ANSI Central European; Central European (Windows)
1251 = "windows-1251" # windows-1251 ANSI Cyrillic; Cyrillic (Windows)
1252 = "windows-1252" # windows-1252 ANSI Latin 1; Western European (Windows)
1253 = "windows-1253" # windows-1253 ANSI Greek; Greek (Windows)
1254 = "windows-1254" # windows-1254 ANSI Turkish; Turkish (Windows)
1255 = "windows-1255" # windows-1255 ANSI Hebrew; Hebrew (Windows)
1256 = "windows-1256" # windows-1256 ANSI Arabic; Arabic (Windows)
1257 = "windows-1257" # windows-1257 ANSI Baltic; Baltic (Windows)
1258 = "windows-1258" # windows-1258 ANSI/OEM Vietnamese; Vietnamese (Windows)
12000 = "UTF-32LE" # utf-32 Unicode UTF-32, little endian byte order; available only to managed applications
12001 = "UTF-32BE" # utf-32BE Unicode UTF-32, big endian byte order; available only to managed applications
20127 = "US-ASCII" # us-ascii US-ASCII (7-bit)
20866 = "KOI8-R" # koi8-r Russian (KOI8-R); Cyrillic (KOI8-R)
20905 = "KOI8-U" # IBM EBCDIC Turkish
20932 = "EUC-JP" # EUC-JP Japanese (JIS 0208-1990 and 0212-1990)
21025 = "x-IBM1025" # cp1025 IBM EBCDIC Cyrillic Serbian-Bulgarian
28591 = "iso-8859-1" # iso-8859-1 ISO 8859-1 Latin 1; Western European (ISO)
28592 = "iso-8859-2" # iso-8859-2 ISO 8859-2 Central European; Central European (ISO)
28593 = "iso-8859-3" # iso-8859-3 ISO 8859-3 Latin 3
28594 = "iso-8859-4" # iso-8859-4 ISO 8859-4 Baltic
28595 = "iso-8859-5" # iso-8859-5 ISO 8859-5 Cyrillic
28596 = "iso-8859-6" # iso-8859-6 ISO 8859-6 Arabic
28597 = "iso-8859-7" # iso-8859-7 ISO 8859-7 Greek
28598 = "iso-8859-8" # iso-8859-8 ISO 8859-8 Hebrew; Hebrew (ISO-Visual)
28599 = "iso-8859-9" # iso-8859-9 ISO 8859-9 Turkish
28603 = "iso-8859-13" # iso-8859-13 ISO 8859-13 Estonian
28605 = "iso-8859-15" # iso-8859-15 ISO 8859-15 Latin 9
50220 = "iso-2022-jp" # iso-2022-jp ISO 2022 Japanese with no halfwidth Katakana; Japanese (JIS)
50222 = "iso-2022-jp" # iso-2022-jp ISO 2022 Japanese JIS X 0201-1989; Japanese (JIS-Allow 1 byte Kana - SO/SI)
50225 = "iso-2022-kr" # iso-2022-kr ISO 2022 Korean
65001 = "UTF-8" # utf-8 Unicode (UTF-8)
} |
The Agent detects and makes use of the code page used by the Windows OS
- for code pages from the above list,
- for code pages that are prefixed with
cp#
or CP#
with # being the number of the code page.
- Users can enforce use of a supported code page by adding a setting to the Agent's
JS7_AGENT_CONFIG_DIR/agent.conf
configuration file such as:js7.job.execution.encoding = "UTF-8"
- This setting specifies the MIME type not the numeric code page identifier, for example
UTF-8
instead of 65001
. - Default: the default code page of the Windows operating system is used, for example, 932 for Japan, 850 for Western Europe.
Security Configuration File: private.conf
js7.job.execution: Job Script Execution Permissions
js7 | job | execution |
|
|
---|
|
|
| signed-script-injection-allowed | yes|no |
- By default the Agent prevents any commands and scripts from being executed except for scripts located in specific directories. This setting allows any commands and scripts to be executed that the workflow has signed and where the signature has been verified.
js7.job.execution: Job Script Termination
The following settings can be used for releases prior to 2.7.2:
js7 | job | execution |
| Default |
---|
|
|
| kill-with-sigterm-command | "/bin/kill", "$pid" |
|
|
| kill-with-sigkill-command | "/bin/kill", "-KILL", "$pid" |
- The Agent can be instructed to terminate running jobs - see the JS7 - FAQ - How does JobScheduler terminate Jobs article.
- The following settings are in place to terminate running jobs by an Agent operated for a Unix OS:
- The setting
kill-with-sigterm-command
specifies the OS command executed by the Agent to forward a SIGTERM signal to the running job. - The setting
kill-with-sigkill-command
specifies the OS command executed by the Agent to forward a SIGKILL signal to the running job.
- Both settings are specified as an array of arguments, i.e.
"/bin/kill", "-KILL", "$pid"
translates to the command: /bin/kill -KILL 99,
provided that 99
is the Process ID of the running job. - This setting can be applied if the Agent is operated on an OS that makes use of a different syntax for the
kill
command
Code Block |
---|
language | yml |
---|
linenumbers | true |
---|
|
js7 {
web {
# keystore and truststore location for https connections
https {
keystore {
# Default: ${js7.config-directory}"/private/https-keystore.p12"
file=${js7.config-directory}"/private/https-keystore.p12"
key-password=jobscheduler
store-password=jobscheduler
}
truststores=[
{
# Default: ${js7.config-directory}"/private/https-truststore.p12"
file=${js7.config-directory}"/private/https-truststore.p12"
store-password=jobscheduler
}
]
}
}
} |
Explanation:
- HTTPS keystore and truststore are used to hold private keys and certificates
- The keystore holds the Controller instance's private key and certificate. This information is used for
- Server Authentication with JOC Cockpit and for
- Client Authentication with Agents.
- The truststore holds the certificate(s) used to verify
- Client Authentication certificates presented by JOC Cockpit and
- Server Authentication certificates presented by Agents.
- Keystore and Truststore locations are specified. In addition for
- the keystore a password for the private keys included and a password for access to the keystore can be specified
- the truststore a password for access to the truststore can be specified.
- Passwords for keystores and truststores have no tendency to improve security of the configuration: the passwords have to be specified as plain text and have to be in reach of the Controller. This mechanism is not too different from hiding the key under your doormat. In fact limiting ownership and access permissions for keystore and truststore files to the JS7 Controller's run-time account are more important than using a password.
- The
key-password
is used for access to a private key in keystore. - The
store-password
setting is used for access to a keystore or to a truststore. - For PKCS12 (*.p12) keystores both settings have to use the same value. The settings can be omitted if no passwords are used.
Configuration Items
General Configuration File: agent.conf
js7.web.server: Authentication Settings
...
- This setting specifies public access to an Agent if insecure incoming HTTP connections are to be used. If used with a value
true
then no authentication is applied. - Default:
false
Security Configuration File: private.conf
js7.job.execution: Script Execution Permissions
...
- By default the Agent prevents any commands and scripts from being executed except for scripts located in specific directories. This setting allows any commands and scripts to be executed that the workflow has signed and the signature has been verified.
js7.configuration: Trusted Signature Keys
js7 | configuration |
|
|
|
---|
|
| trusted-signature-keys |
|
|
|
|
| PGP | <directory> |
|
|
| X509 | <directory> |
- The Agent expects a signature receives signatures for any deployed objects such as workflows. Such signatures are created with a private key and are verified by the Agent according to the available certificates.
- When deploying objects with JOC Cockpit:
- for a Low low Security Level JOC Cockpit creates the signature from a single private key that is used for any JOC Cockpit user accounts allowed to deploy objects.
- for a Medium medium Security Level JOC Cockpit creates the signature from the private key of the JOC Cockpit user account that deploys objects.
- for a High high Security Level the user creates the signature outside of JOC Cockpit and uploads the signed files holding scheduling objects and signatures.
- The Agent supports PGP public keys and X.509 certificates. This setting expects a directory that holds a number of public key files or certificate files.
trusted-signature-keys
PGP
: specifies the directory from which PGP public keys are used to verify the signature signatures of deployed objects.X509
: specifies specifies the directory from which X.509 certificates are used to verify the signature signatures of deployed objects.
js7.auth
...
: HTTPS Authentication and Authorization
js7 | auth |
|
|
|
|
---|
|
| users | Controller |
|
|
|
|
|
| distinguished-names |
<distinguished-name>[,<distinguished-name]
<distinguished-name>[,<distinguished-name>] |
|
|
|
| password | plain:<password>
sha512:<password-hash>
|
|
|
| <subagent-id> |
|
|
|
|
|
| distinguished-names | <distinguished-name>[,<distinguished-name>] |
|
|
|
| password | plain:<password>
sha512:<password-hash>
|
|
| subagents | <subagent-id> | "plain:<password>" |
|
- An additional authentication mechanism is applied when using HTTPS certificates or public keys for incoming connections, see below: the client of the incoming connection, i.e. a Controller, is required to provide a Client Authentication Certificate. This includes two certificates that are in place for a secure HTTPS connection: the Agent's a Server Authentication Certificate and the Controller's a Client Authentication Certificate.
- The fact that a given certificate is to be used for Server Authentication and/or Client Authentication is specified with the key usage when the certificate is being created and signed.
- The distinguished name that is specified with the Agent's configuration has to match the Client Authentication Certificate's subject attribute of a Controller. This attribute specifies the hostname and additional information that is created when the certificate or public key is generated.
js7.auth.users.Controller
- Settings in this section are used for incoming HTTPS connections from Controller instances.
distinguished-names
: - Specifies the distinguished name as given with the subject of the Client Authentication Certificate for incoming HTTPS connections from a Controller.Any number of distinguished names can be specified allowing a number of incoming HTTPS connections from different Controllersfrom a Controller.
- One or two distinguished names can be specified allowing incoming HTTPS connections from a Standalone Controller or Controller Cluster.
password
- As an alternative to TLS mutual authentication a password can be specified.
js7.auth.subagents
- Settings in this section are used for outgoing HTTPS connections from Director Agent instances to Subagents.
js7.web.https: HTTPS Certificates
js7 | web | https |
|
|
|
---|
|
|
| keystore |
|
|
|
|
|
| file | <path> |
|
|
|
| key-password |
<text>
<password> |
|
|
|
| store-password | <password> |
|
|
|
| alias | <identifier> |
|
|
| client-keystore |
|
|
|
|
|
| file | <path> |
|
|
|
| key-password | <password> |
|
|
|
| store-password |
<text>
<password> |
|
|
|
| alias | <identifier> |
|
|
| truststores |
|
|
|
|
|
| file | <path> |
|
|
|
| store-password |
<text>
<password> |
|
|
|
| alias | <identifier> |
- This setting is used to specify the location of a keystore and any truststores used for HTTPS connections.
- Keystore and truststore files are expected in PKCS12 format or in PKCS#12 PEM format.
keystore
- The keystore includes the private key for the Agent's incoming HTTPS connections.
- Private key types RSA and ECDSA are supported.
file
: the full path to the location of the keystore file is expected.- Default:
${js7.config-directory}"/private/https-keystore.p12"
key-password
: Any keys included with the keystore are protected with a password. The same password has to be used for all private keys in the given keystore.store-password
: The keystore are protected with a password. The same password has to be used for all private keys in the given keystore.store-password
: The keystore file is protected by a passwordfile is protected by a password.alias
: can be used for example with a keystore that holds a number of private keys from which the relevant private key is selected by its alias name.
client-keystore
- Use of this setting is optional. It can be used if separate certificates for Server Authentication and Client Authentication are used.
- The Client Authentication private key and certificate can be added to this keystore.
- Included configuration items correspond to the
keystore
setting.
truststores
- A truststore contains the certificates or public keys for the Agent's incoming HTTPS connections.
- Certificates are signed by a Certificate Authority (CA) - alternatively a self-signed certificate can be used.
- It is recommended that certificates are used instead of public keys.
- Certificates of type X.509 are supported.
file
: the full path to the location of the truststore file is expected.- Default:
${js7.config-directory}"/private/https-truststore.p12"
store-password
: A truststore file is protected by a password.alias
: can be used for example with a truststore that holds a number of certificates from which the relevant certificate is selected by its alias name.- A number of truststores can be specified by repeating the
file
and store-password
settings.
js7.web.server: HTTPS Authentication
js7 | web | server |
|
|
|
---|
|
|
| auth |
|
|
|
|
|
| https-client-authentication |
<onoff>- This setting is used to specify the authentication type for HTTPS connections to an Agent.
https-client-authentication
- The value
on
(default) specifies that mutual authentication with certificates for Server Authentication and Client Authentication is used. - The value
off
specifies that only HTTP Basic Authentication only is used.
- By default JS7 makes use of mutual authentication including both Server and Client Authentication Certificates. This setting can be switched off to use Server Authentication Certificates only.
...