Database based configuration

Configuration in a database

EMG 7 can read connector configuration from a database. EMG will then bootstrap by reading server.cfg to find the database information and then the rest of the configuration options will be read from the database. General configuration, connectors, plugins and sat pools will be read from the database. Database profiles must be configured in server.cfg. Any configuration options found in the database will be merged to the options present in the bootstrap server.cfg.

Requirements

The following information must be present in the general section of the server.cfg file.

  • A database profile, using MySQL
  • The keyword DBPROFILE, pointing to that profile
  • The keyword DBCONFIG

Initiating

If you already have a working configuration in server.cfg you can run “emgd --initdbconfig” to import it into the database. This will import all configuration sections from server.cfg to the database except for the general keywords and any db section. After importing the configuration you should remove the connector, plugin and sat pool configuration sections from server.cfg.

You can also start with empty tables.

A minimal server.cfg for bootstrapping a DBCONFIG setup. It includes a mgp-in1 connector to enable cli management even if db config is cleared.

ROTATELOGS=100M:5
ROTATELOGS_DEBUG=100M:20
#DEBUG
PDULOG
ROUTELOGDB
PERSISTFILES
DBPROFILE=emg
DBCONFIG

# If you have multiple EMG nodes using the same database, assign each one a unique NODEID.
# NODEID=1

# Database profile
DB emg <
HOST=127.0.0.1
PORT=3306
USERNAME=emguser
PASSWORD=secret
DBNAME=emg
TYPE=MYSQL
INSTANCES=4
>

# Accept incoming connections via MGP
CONNECTOR mgp-in1 <
TYPE=INCOMING
PROTOCOL=MGP
ADDRESS=127.0.0.1:7185
INSTANCES=5
USERS=users
>

EMG startup

When emgd is started and DBCONFIG is present, the following will take place:

  1. EMG will look for the most recent timestamp in “updated” columns in the cfg_* tables.
  2. EMG will try to create the directory $EMGDIR/dbconfig/<timestamp>, where timestamp is the current time formatted as YYYY-MM-DD_HH:MM:SS
    1. If successful, EMG will create configuration files using the data in the configuration tables in the database and try to start up using the newly created configuration files
    2. If the directory already exists EMG will instead start up from the  configuration in the directory pointed to by symbolic link $EMGDIR/dbconfig/lastok.
  3. If the startup fails, EMG will exit. If successful, the timestamp will be written to the table emgsystem with keyname = “dbconfig_lastok” and value = “<timestamp>”. This enables applications such as EMG Portal to see which configuration is running. The symbolic link $EMGDIR/dbconfig/lastok will then be updated to point to the dbconfig directory in use.

If EMG startup fails using a new configuration, on subsequent startup tries (manual or by watchdog) EMG will fallback on “lastok” configuration.

Starting fresh

If you want to start over with the configuration from scratch you can stop emgd, delete all entries from the cfg_* tables and remove the dbconfig directory.

Updating

The configuration in the database can be updated freely (remember to set the “updated” column of the entries changed, EMG Portal of course does this). When the configuration is complete, restart emgd or run “emgd -reload“.

EMG watchdog

With EMG 7 a watchdog for EMG is introduced. The watchdog is a small perl script that runs as a daemon and monitors the emgd process and the available disk space on the server. E-mail notifications will be sent if problems are detected. It also features an integrated web server enabling external applications to restart the emgd process using a simple http request. It should be run on the same server as emgd runs and under the same user.

EMG Portal 2 includes support for communicating with the watchdog, and thereby more EMG administration tasks can be performed without the need to use the cli.

Schema

CREATE TABLE cfg_connectors
(
id INTEGER NOT NULL AUTO_INCREMENT,
name VARCHAR (60),
connector_order INTEGER,
PRIMARY KEY(id),
UNIQUE unique_connector_name (name)
);
 
CREATE TABLE cfg_connectoroptions
(
id INTEGER NOT NULL AUTO_INCREMENT,
connectorid INTEGER NOT NULL,
keyorder INTEGER,
keyname VARCHAR (255) NOT NULL,
value VARCHAR (255),
PRIMARY KEY(id)
);
 
CREATE TABLE cfg_general
(
id INTEGER NOT NULL AUTO_INCREMENT,
keyorder INTEGER,
keyname VARCHAR (255) NOT NULL,
value VARCHAR (255),
PRIMARY KEY(id)
);
 
CREATE TABLE cfg_plugins
(
id INTEGER NOT NULL AUTO_INCREMENT,
name VARCHAR (60),
updated DATETIME NOT NULL,
instances INTEGER default 0,
offset INTEGER default 0,
library VARCHAR (1024),
config VARCHAR (1024),
PRIMARY KEY(id),
UNIQUE unique_plugin_name (name)
);
 
CREATE TABLE cfg_satpools
(
id INTEGER NOT NULL AUTO_INCREMENT,
name VARCHAR (60),
updated DATETIME NOT NULL,
threaded SMALLINT,
quoted_reply SMALLINT,
ignore_destaddr SMALLINT,
random SMALLINT,
expire INTEGER,
addressrange VARCHAR (1024),
PRIMARY KEY(id),
UNIQUE unique_satpool_name (name)
);

2 Replies to “Database based configuration”

Comments are closed.