Server Administration on RIA Docs

Server Administration

Mon, 01 Jan 0001 00:00:00 +0000

The installation directory contains several subdirectories which are important for managing DIH. These directories store configuration files, logs, scripts, and other resources required for the server.

For more details on these files and their configurations, see Installation guide.

Starting/Stopping

Mon, 01 Jan 0001 00:00:00 +0000

The bin directory has the following main scripts for encryption, starting and stopping the server:

encrypt

To securely encrypt the DB connection password stored in ria-boot.properties or user passwords stored in users.json, run the encryption utility:

./encrypt

This will prompt you to specify the type of password and allows you to encrypt it securely.

A user id does not need to exist in the users.json for its password to be encrypted, the encrypt utility will automatically add a user if it does not exist.

startws

To start the webserver, run:

Web Server Configuration

Mon, 01 Jan 0001 00:00:00 +0000

Overview

The config directory contains the configuration files for the conversion tool. The following files can be reviewed and modified as needed.

ria.boot.properties

This file specifies the following information:

Web server host address and port
Database connection properties (can be encrypted with encrypt)
OUAF service information

users.json

The users.json file defines the user ids that are permitted to login to the web application. The user ids and passwords can be manually edited in this file or the encrypted using the encrypt utility.

Runtime Server Configuration

Mon, 01 Jan 0001 00:00:00 +0000

The runtime server can be clustered to scale using Hazelcast In-Memory Data Grid (IMDG) framework. This clustering configuration can be adjusted and modified as needed.

hazelcast.xml

The Hazelcast cluster configuration is defined in this file.

The default cluster name is ria-conv-dev, which assumes that the first installation will be on a development environment. Each cluster must have a unique name. If separate environments (e.g., the system testing environment) require different clusters, their names must be unique to prevent runtime server JVMs from joining the wrong cluster.