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.
We recommend using the standalone deployment mode. Both JBoss and Wildfly deployment types are deprecated and will be removed in future releases.
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 configuration files are located here: /var/opt/nevislogrend/<instance>/conf
The following configuration files control the behavior of nevisLogRend in the standalone deployment type:
| Configuration file | Remarks |
|---|
env.conf
Administration command and process environment:
- JAVA_HOME (optional): Use specified JRE/JDKAll 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 on expressions Standalone - logrend.properties expression usage.
log4j.xml
Logging configuration
logrend.properties
Application configuration
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(required) | <instance> | Name of the server. Give each server a unique name, for the sake of identification. This name will also be logged. | |
| server.protocol(optional) | https | https | Enumeration: https, http(info) Set this property to "https", if you would like to use TLS. |
| server.port(optional) | 8988 | 8988 | Configures the port where the server will listen for incoming requests. |
| server.host(optional) | localhost | localhost | Configures the address on which the server will listen for incoming requests. |
| server.tls.keystore(required if server.protocol = "https") | /var/opt/keybox/default/node_keystore.jks | Keystore object used for the TLS. | |
| server.tls.keystore-passphrase(required if server.protocol = "https") | keystorepassword | ||
| server.tls.truststore(required if server.protocol = "https") | /var/opt/keybox/default/truststore.jks | Truststore object used for the TLS. | |
| server.tls.truststore-passphrase(required if server.protocol = "https") | 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 property server.tls.verify-hostnameto "false". Instead, enable the client-side hostname verification in the HttpsConnectorServlet 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(optional) | 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(optional) | 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(optional) | 200 | 200 | Number of threads used to process incoming requests. |
| server.max-http-header-size(optional) | 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(optional) | 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 (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 chapter 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 the IP only, 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