The configuration file
If you create a case using createcase.pl, a basic configuration file
will get created from template.conf. This page describes most of the
configuration possibilities you have using this file. The lines in the
configuration file always consist of a key/value pair. The key itself
can be a single string naming a configuration parameter, or can be a
colon separated value containing first the name of the module and/or
the name of the C++ class the configuration parameter is being set for.
This way it becomes possible to set a configuration parameter globally
and overrule it for one of several named modules.
logging
By default the open computer forensics architecture uses syslog for its
logging. It is however possible to load an alternative module for
logging, or to log to the console for debugging purposes. The
configuration parameter loglib can be used to change to another
logger. The log4c module is supplied as an alternative to syslog. If
absolutely no value is defined, the SimpleLogger is used. The
SimpleLogger logs either to files or to the console depending on the
value of daemonize. If the SimpleLogger is used and the system is
running daemonized, the logdir parameter defines the directory
that logfiles are written to. If the log4c logger is defined to be
loaded, the log4cxx.propertyfile parameter defines the log4c
propertyfile path this module should use (for more information consult
log4c documentation).
The syslog logger and simple logger share the config parameter syslog.
This parameter determines the minimal severity of a log action
for triggering the actual logging.
Logging added to the evidence metadata
Next to the global logging to files or syslog, the library also
provides the possibility to log to the evidence metadata xml. This is
quite convenient for debugging purposes of rulelists and modules. The
function used therefore, esyslog, is similar to the syslog
parameter, and pertains to the usage of logging to the evidence
metadata xml.
foreground or daemonize
Normally an ocfa module program will run as a daemon. However, for
debugging purposes running a program in the foreground is more
convenient. The parameter daemonize determines if the
processes runs as a daemon or stays in the foreground.
profiling
The evidence library has some simple module profiling possibilities.
The
profiling parameter can be used to turn this on.
xml formatting and checking
The evidence library makes use of an xml library that can be configured
to a large extent. One important configuration parameter is the
consistency check that the library can perform using an xml schema that
is provided with the open computer forensics architecture. The schemacheck
parameter determines whether the schema based xml consistency checks
should be performed or not. The schemadir parameter determines
where the schema can be found. This parameter should rarely need to be
changed.
Finally when producing xml output, the library can make the xml more
human readable if prettyprint is set to true.
Evidence failsafes
It is quite easy to make a far reaching mistake in a rulelist for the
router. Such a mistake could for example lead to evidence or derivation
running without an end in the open computer forensics architecture. The
parameter maxparents might help a bit to alleviate some of the
problems by only permitting an evidence to have a limited set of
ancestor evidences. A second tool in preventing some of the
consequences of bugs or configuration errors comes with the moduletwice
parameter. Logically, many modules should not ever be called twice
on the same evidence. For these modules, if this parameter is set the
module will throw an exception if the module is sent the same evidence
a second time. If during the processing of an evidence an exception is
thrown by the library or the module, than the parameter failfatal
determines if this exception is only logged, or if the module exits. It
is suggested to run new untested modules with this parameter set to
true in order to do early detection of problems in the code.
Filesystem abstraction
If the filesystem abstraction library is used on mounted
filesystems, the library will itself try to determine a suitable module
to use. It will ask the system what filesystem is running on the
mounted partition and will use the parameter FileSystemSelector:handler:<fstype>
to determine what module to use and the parameter FileSystemSelector:charset:<fstype>
to determine with what character set defined.
For some investigations owner acl and/or directory acl information is
not really relevant. The parameters ignoreowneracl and ignoredirexecacl
are provided.
Repository settings
The storeimpl parameter is used to determine what
implementation of the store library should be used by the library at
startup. At this moment there is only one implementation
available, but you should be free to write your own if it pleases you.
For the standard library that uses a postgress database, the parameters
storedbhost, storedbname , storedbuser , storedbpassword
tell the library how to connect to the database. The library also uses
the local filesystem. The repository parameter tells the
library what directory it can use to store its data.
Storage hacks
When using read only mounted filesystems, it may be desirable for local
storage efficiency not to make a copy of the data to the repository,
but use a symlink instead. This however means that some prerequisites
need to be met for the mounted filesystem. Most of these prerequisites
can be tested by the library itself, one however can not. The library
needs to be told if the mounted filesystems will remain available
during the full life of the case. If they are, than the parameter staticmounts
can be used to make this known to the library.
Messaging
A module normally works as a messaging client while an anycastrelay
normally works as a messaging server and a relay at the same time. This
is however not hard coded into these modules, but is configurable using
the msgLibrary and isRelay parameter. If a module is
configured as a messaging client then routerIP is used by the
client to determine what IP to connect to.
Router
The router will need to know where to find its rulelist. The rulelist
parameter defines the path of the rulelist file. If none of the lines in
the rulelist matches a certain evidence, a default action will be
triggered. The parameter defaultatype defines the default
action
type and the parameter defaultavalue defines the default action
target
value. Triggering the default action is seen as a badly implemented
rulelist. For this reason a warning will be logged.