Deployment Types

nevisLogRend supports multiple deployment types and multiple instances. The deployment type can be defined per instance. nevisLogRend instances can be conveniently created using the administrative command-line interface.

Instance creation example

nevislogrend inst create <instance> LOGREND_DEPLOY_TYPE=<selectedDeploymentType>

Deployment type requirements and recommendations

• The standalone deployment type requires OpenJDK 1.8.0. The standalone deployment type is available on Red Hat Enterprise Linux 7, SUSE Linux Enterprise Server 12 and the nevisAppliance.
• The JBoss 5 deployment type requires adnjboss 5.1.6.1 and adnjdk18. The JBoss 5 deployment type is available on all supported operating systems.
• The WildFly 10 deployment type requires adnwildfly. The WildFly 10 deployment type is available on Red Hat Enterprise Linux 7, SUSE Linux Enterprise Server 12 and the nevisAppliance.

Recommendations
We recommend using the standalone deployment mode. The WildFly 10 deployment type is considered as experimental.

Standalone

The standalone deployment type uses an embedded container. There is no need to install a separate container.

The standalone deployment type is the default deployment type for nevisLogRend. That is, if LOGREND_DEPLOY_TYPE is not set during instance creation, the instance will be set up based on the standalone deployment type. To explicitly specify the usage of the standalone deployment type during instance creation (or handover), you may set the LOGREND_DEPLOY_TYPE variable to LOGREND_DEPLOY_TYPE=standalone.

The following configuration files control the behavior of nevisLogRend in the standalone deployment type:

Configuration file	Deployment type	Remarks
log4j.xml	all	Logging configuration
logrend.properties	all	Application configuration Server configuration:
env.conf	all	Administration command and process environment: *JAVA_HOME (optional): Use specified JRE/JDK.All other parameters should not be changed. * JAVA_OPTS: JVM command-line options. The JAVA_OPTS environment variable can be an expression that will be replaced.

Example 1 - using single quotes:

JAVA_OPTS=(
'-server'
'-Djavax.net.ssl.keyStorePassword=${exec:cat /var/opt/pwd.txt}'
)

Example 2 - using double quotes:

JAVA_OPTS=(
"-server"
"-Djavax.net.ssl.keyStorePassword=\${exec:cat /var/opt/pwd.txt}"
)

Old string syntax:(info) The old string syntax cannot handle spaces in JVM arguments and inline comments.

JAVA_OPTS="-server \
-Djavax.net.ssl.keyStorePassword=\${exec:cat /var/opt/pwd.txt}"

Important: If you use double quotes the $ must be escaped.

For more information on expressions, see the table Standalone - logrend.properties expression usage.

info

The configuration files are located here:

• /var/opt/nevislogrend/<instance>/conf

Environment configuration

As the first priority, nevisLogRend uses the Java installation defined in the file env.conf using the configuration property JAVA_HOME. If the JAVA_HOME property is not defined in the file env.conf, the Java version as defined in the PATH environment variable is used.

To define the usage of a specific Java installation, we recommend setting the configuration property to JAVA_HOME in the file env.conf:

Example

JAVA_HOME=/etc/alternatives/jre_1.8.0

Server configuration properties

You can configure the server settings of the standalone deployment type through the properties in the file logrend.properties (see the following table).

Name	Example value	Default value	Remarks
server.name	<instance>		Name of the server. Give each server a unique name, for the sake of identification. This name will also be logged.
server.protocol	https	https	Enumeration: https, http(info) Set this property to "https", if you would like to use TLS.
server.port	8988	8988	Configures the port where the server will listen for incoming requests.
server.host	localhost		Configures the hostname on which the server will listen for incoming requests.
server.tls.keystore	/var/opt/keybox/default/node_keystore.jks		Keystore object used for the TLS.
server.tls.keystore-passphrase	keystorepassword
server.tls.truststore	/var/opt/keybox/default/truststore.jks		Truststore object used for the TLS.
server.tls.truststore-passphrase	truststorepassword
server.tls.client-auth(optional)	required	disabled	Enumeration: required, requested, disabled"required" is the successor of theserver.tls.require-client-auth: truesetting. It means that client authentication is required. "requested" allows client authentication if the client certificate is sent. In case the client certificate was not sent, no client authentication will be performed. "disabled" is the successor of theserver.tls.require-client-auth: false*setting.
server.tls.verify-hostname(optional)	true	false	If set to "true" and a two-way TLS connection is required, the server verifies that the IP address in the certificate presented by the client matches the IP address of the client. (info) The IP address is specified in the Subject Alternative Names field of the certificate.(info) A required two-way TLS connection corresponds with the following setting: server.tls.client-auth="required"In the TLS connection setups of Nevis, nevisProxy acts as a client whereas nevisLogRend acts as a server. Hostname verification is a client-side feature by design, which allows for a stricter verification of the server identity. On the server side, there is not enough information: You can verify the IP address only, because the hostname is not available. Therefore, to use the hostname verification feature in a Nevis TLS setup, the client (that is, nevisProxy) needs a fixIP address. Alternatively, regenerate the certificates each time the IP address changes.It is recommended leaving this configuration disabled, that is, setting the propertyserver.tls.verify-hostnameto "false". Instead, enable the client-side hostname verification in theHttpsConnectorServlet of nevisProxy. For more information, see the chapter HttpsConnectorServlet in the nevisProxy reference guide.If you set this property to "true", you may need to regenerate the client certificates used to connect to nevisLogRend. See the section Creating Self-Signed Certificates with Subject Alternative Names] is not included in the certificates by default.
server.tls.supported-protocols	TLSv1.2	TLSv1.2	Provides a list of protocols that are accepted by the client when trying to initiate a connection with TLS
server.tls.cipher-suites	TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384	TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,TLS_DHE_RSA_WITH_AES_256_GCM_SHA384	Provides a list of ciphers that are accepted by the client when trying to initiate a connection with TLS.The cipher name format is the one used in the Java Cryptography Architecture Oracle Providers Documentation for JDK 8.
server.max-threads	200	200	Number of threads used to process incoming requests.
server.max-http-header-size	16384	8192 (8 kilobytes)	Defines the maximum size in bytes of the request and response HTTP headers. (info) Larger headers allow for more and/or larger cookies as well as larger form content encoded in a URL. However, larger headers also consume more memory and can make a server more vulnerable to denial of service attacks.
management.server.port	8997	8997	The port where the server exposes the liveness endpoint used by Kubernetes. Currently, only HTTP is supported. This property is experimental and can change in future releases.
management.healthchecks.enabled	false	false	Shows whether the [health endpoints] (readiness and liveness) are enabled or not. This property is experimental and can change in future releases.

The server configuration property values in the file logrend.properties can be expressions that will be replaced. The next table shows the available syntax:

Syntax	Example	Remarks
${exec:command}	server.tls.keystore-passphrase: ${exec:/var/opt/keys/own/instance/keypass.sh}server.host: ${exec:hostname -f}	Executes the given command and uses its output as value.
${env:variablename}	server.host: ${env:HOSTNAME}	Uses the value of the specified environment variable.

Standalone server command-line interface

For standalone deployments, the standalone command-line interface (CLI) provides a low level interface to run the server process. It can be used by higher level tools like the administrative CLI (see The administrative command-line interface) or by the user directly.

You can use the standalone CLI to start nevisLogRend without involvement of other system components like for example systemd.

You find the standalone script at /opt/nevislogrend/bin/nevislogrend-server. It provides the following command line options:

Command line argument	Remarks	Default
-c, --config PATH	Required. Path to the configuration file nevislogrend.properties.	No default.
-n, --name NAME	Unique name for that Nevis component node.Overrides the value of the property server.name (in the logrend.properties file).	See the server.name property in the logrend.properties file.
-p, --port PORT	The HTTP/S port to listen on. TLS must be configured in the config file and not as an argument.Overrides the value of the property server.port (in the logrend.properties file).	See the server.port property in the logrend.properties file.
-H, --host HOST	The HTTP/S host to bind on. By default binds on all IPv4 and IPv6 interfaces.Overrides the value of the property server.host (in the logrend.properties file).	See the server.host property in the logrend.properties file.
--log-config PATH	Log configuration file to be used.If a log configuration is provided, nevisLogRend will use the given configuration file to determine how logging should behave. If no configuration file is provided, nevisLogRend will log to the console by default.	Not set.
-V, --version	Display version and exit with status code 0.
-h, --help	Shows complete and detailed usage and exit with status code 0.

Command-line arguments always prevail over properties in the logrend.properties file!

Example usage of the standalone CLI

To start an existing nevisLogRend instance named "default" without using systemd to manage the service, execute the following commands:

# set working directory
cd /var/opt/nevislogrend/default
  
/opt/nevislogrend/bin/nevislogrend-server --config /var/opt/nevislogrend/default/conf/logrend.properties --log-config /var/opt/nevislogrend/default/conf/log4j.xml

Creating Self-Signed Certificates with Subject Alternative Names (SAN)

The commands in the following code block generate certificates that you can use in a test environment including a nevisLogRend instance with two-way client authentication and hostname verification.

The neviskeybox command creates a keystore with two Subject Alternative Names (SANs): One of type DNS, and the other of type IP. You can use this keystore in nevisProxy to connect to nevisLogRend.

Note that nevisLogRend uses the DNS name in the SAN to verify only the IP, not the client identity.

The following code sample shows the correct syntax:

neviskeybox certreq -slot default -label node -subject 'cn=siven.ch,ou=auth,o=o=nevis-security,dc=com' -subjectAltName 'DNS:siven.ch,IP:10.0.0.1'
neviskeybox sign -ca testCA -out /tmp/node_new_cert.pem -file /var/opt/keybox/default/node_request.pem
neviskeybox import -file /tmp/node_new_cert.pem
neviskeybox access -slot default -label node -group nvbgroup -user nvpuser
neviskeybox passwd -keep -slot default -label node

JBoss 5

The JBoss 5 deployment type uses an adnjboss container. You specify the usage of a JBoss 5 deployment type during instance creation (or handover), by setting the LOGREND_DEPLOY_TYPE variable to LOGREND_DEPLOY_TYPE=adnjboss.

The following configuration files control the behavior of nevisLogRend in the JBoss 5 deployment type:

Configuration file	Deployment type	Remarks
env.conf	all	Administration command and process environment: JAVA_HOME (optional): Use specified JRE/JDK All other parameters should not be changed.File location:/var/opt/adnjboss/<instance>/conf/env.conf*
vmargs.conf	all	JVM environment (JVM command-line options): Heap size Garbage collector JSSE configuration properties JNDI configuration properties
server.xml	JavaEE (tomcat5)	Server configuration: Scaling (concurrency with worker threads) Network adapters (called connectors in tomcat, i.e., HTTP or HTTPS) Located at/var/opt/adnjboss/<instance>/conf/server.xml* (part of JBoss)
log4j.xml	all	Logging configuration
logrend.properties	all	Application configuration

info

The configuration files are located here:

• /opt/nevislogrend/template/conf (default configuration for JBoss and WildFly setup)
• /var/opt/nevislogrend/<instance>/conf (instance configuration)

WildFly 10

Deployments based on WildFly 10 are considered as experimental.

The WildFly 10 deployment type uses an adnwildfly container. You may specify the usage of the adnwildfly container during instance creation (or handover), by setting the LOGREND_DEPLOY_TYPE variable to LOGREND_DEPLOY_TYPE=adnwildfly.

The following configuration files control the behavior of nevisLogRend in the WildFly deployment type:

Configuration file	Deployment type	Remarks
env.conf	all	Administration command and process environment: JAVA_HOME (optional): Use specified JRE/JDKAll other parameters should not be changed. File location:/var/opt/adnwildfly/instances/<instance>/standalone/configuration/env.conf*
vmargs.conf	all	JVM environment (JVM command-line options): Heap size Garbage collector JSSE configuration properties JNDI configuration properties
standalone.xml	all	Part of adnwildfly. Used for the configuration of application server parameters such as extensions, profiles and subsystems, paths, interfaces, socket bindings and socket binding groups, system properties, etc.
log4j.xml	all	Logging configuration
logrend.properties	all	Application configuration

WildFly - Configuration files

info

The configuration files are located here:

• /var/opt/nevislogrend/<instance>/conf (instance configuration)
• /var/opt/adnwildfly/instances/<instance>/standalone/configuration (server configuration)