- Configuration in a database
- Requirements
- Initiating
- EMG startup
- Starting fresh
- Updating
- EMG watchdog
- Schema
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:
- EMG will look for the most recent timestamp in “updated” columns in the cfg_* tables.
- EMG will try to create the directory
$EMGDIR/dbconfig/<timestamp>
, where timestamp is the current time formatted asYYYY-MM-DD_HH:MM:SS
- 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
- If the directory already exists EMG will instead start up from the configuration in the directory pointed to by symbolic link
$EMGDIR/dbconfig/lastok
.
- 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.