Linux/MacOS Configuration

Owned by Phillip Warner
Last updated: Feb 24, 2015
1 min read

OpenCDS should run as an unprivileged user, hence either a no-login account should be created, or the account under which the container will run should be used for placement of configuration files.  This will be the $HOME that is referenced below.

Externalized OpenCDS configuration options should be typically stored in the location below:

  • $HOME/.opencds/opencds.properties

    NOTE: If installed as a service started at boot, the configuration must live under the $HOME (as defined in /etc/passwd) of the user that starts the container.  E.g., if OpenCDS is running on tomcat as run by the system init scripts, and is run by the tomcat user, the properties must live under the tomcat $HOME as defined in /etc/passwd, which is typically /home/tomcat or something similar.

This file must contain the first three lines below.  The fourth and fifth lines are optional.

knowledge-repository.type=<repository type>
knowledge-repository.path=<repository path>
config.security=<path to security config file>
log4j.logfile=<full path to log file>
km.threads=4

  • knowledge-repository.type may be one of the three following values:

    • STORE

    • SIMPLE_FILE

    • CLASSPATH

  • knowledge-repository.path is the absolute or relative path to the configuration, depending upon which type is chosen (above).
    • Example configurations for SIMPLE_FILE may include:
      • /var/lib/opencds/resources_v1.1/
      • /home/opencds/config/resources_v1.1/
      • $HOME/.opencds/config/resources_v1.1/
      • etc.
    • The path for the CLASSPATH type is relative to the classpath of the running JVM (e.g., Tomcat).
      • resources_v1.1/
  • config.security is the location of the security configuration for the REST services.
  • log4j.logfile is the location used by OpenCDS to write the logs.  This line is optional.  Typical values may include:
    • /var/log/opencds/opencds.log
    • $HOME/.opencds/logs/opencds.log
  • km.threads is the number of threads per knowledge module.
    • This can increase throughput of the system, depending upon the number of rules being run for each request. 
    • Best practice shows that the number of km.threads should be kept to the same number of CPUs (or CPU cores).