6. Configuration Framework

The CE provides a configuration framework for consistent and easy to use low level settings management. A basic usage of the configuration framework only needs two actions already used in previous chapters:

Low level management of the configuration framework might be required by advanced users though. This chapter explains the architecture and usage of the NGCP configuration framework. If the basic usage explained above fits your needs, feel free to skip this chapter and return to it when your requirements change.

A more detailed workflow of the configuration framework for creating a configuration file consists of 6 steps:

6.1. Configuration templates

The CE provides configuration file templates for most of the services it runs. These templates are stored in the directory /etc/ngcp-config/templates.

Example: Template files for /etc/sems/sems.conf are stored in /etc/ngcp-config/templates/etc/sems/.

There are different types of files in this template framework, which are described below.

.tt2 and .customtt.tt2 files

These files are the main template files that will be used to generate the final configuration file for the running service. They contain all the configuration options needed for a running CE system. The configuration framework will combine these files with the values provided by config.yml and constants.yml to generate the appropriate configuration file.

Example: In the installation chapter we’ve changed the parameter networkingeaddress from the default 127.0.0.1 to our public IP address 1.2.3.4. This parameter will for example change kamailio’s listen address, when the configuration file is generated. A quick look to the template file under /etc/ngcp-config/templates/etc/kamailio/kamailio.cfg.tt2 will show a line like this:

listen=udp:[% networking.eaddress %]:[% kamailio.port %]

After applying the changes with the ngcpcfg apply command, a new configuration file will be created under /etc/kamailio/kamailio.cfg with the proper values taken from the main configuration file:

listen=udp:1.2.3.4:5060

All the low-level configuration is provided by these .tt2 template files and the corresponding config.yml file. Anyways, advanced users might require a more particular configuration.

Instead of editing .tt2 files, the configuration framework recognises .customtt.tt2 files. These files are the same as .tt2, but they have higher priority when the configuration framework creates the final configuration files. An advanced user should create a .customtt.tt2 file from a copy of the corresponding .tt2 template and leave the .tt2 template untouched. This way, the user will have his personalized configuration and the system will continue providing a working, updated configuration template in .tt2 format.

Example: We’ll create /etc/ngcp-config/templates/etc/kamailio.cfg.customtt.tt2 and use it for our personalized configuration. In this example, we’ll just append a comment at the end of the template.

cd /etc/ngcp-config/templates/etc/kamailio
cp kamailio.cfg.tt2 kamailio.cfg.customtt.tt2
echo '# This is my last line comment' >> kamailio.cfg.customtt.tt2
ngcpcfg apply

The ngcpcfg command will generate /etc/kamailio/kamailio.cfg from our custom template instead of the general one.

tail -1 /etc/kamailio/kamailio.cfg
# This is my last line comment
[Tip]

The tt2 files use the Template Toolkit language. Therefore you can use all the feature this excellent toolkit provides within ngcpcfg’s template files (all the ones with the .tt2 suffix).

.prebuild and .postbuild files

After creating the configuration files, the configuration framework can execute some commands before and after placing that file in its target directory. These commands usually are used for changing the file’s owner, groups, or any other attributes. There are some rules these commands need to match:

  • They have to be placed in a .prebuild or .postbuild file in the same path as the original .tt2 file.
  • The file name must be the same as the configuration file, but having the mentioned suffixes.
  • The commands must be bash compatible.
  • The commands must return 0 if successful.
  • The target configuration file is matched by the environment variable output_file.

Example: We need www-data as owner of the configuration file /etc/ngcp-ossbss/provisioning.conf. The configuration framework will by default create the configuration files with root:root as owner:group and with the same permissions (rwx) as the original template. For this particular example, we will change the owner of the generated file using the .postbuild mechanism.

echo 'chgrp www-data ${output_file}' \
  > /etc/ngcp-config/templates/etc/ngcp-ossbss/provisioning.conf.postbuild

.services files

.services files are pretty similar and might contain commands that will be executed after the build process. There are two types of .services files:

  • The particular one, with the same name as the configuration file it is associated to. Example: /etc/ngcp-config/templates/etc/asterisk/sip.conf.services is associated to /etc/asterisk/sip.conf
  • The general one, named ngcpcfg.services wich is associated to every file in its target directory. Example: /etc/ngcp-config/templates/etc/asterisk/ngcpcfg.services is associated to every file under /etc/asterisk/

When the services step is triggered all .services files associated to a changed configuration file will be executed. In case of the general file, any change to any of the configuration files in the directory will trigger the execution of the commands.

[Tip]

If the service script has the execute flags set (chmod +x $file) it will be invoked directly. If it doesn’t have execute flags set it will be invoked under bash. Make sure the script is bash compatible if you do not set execute permissions on the service file.

These commands are usually service reload/restarts to ensure the new configuration has been loaded by running services.

[Note]

The configuration files mentioned in the following example usually already exist on the platform. Please make sure you don’t overwrite any existing files if following this example.

Example:

echo '/etc/init.d/mysql restart' \
  > /etc/ngcpcfg-config/templates/etc/mysql/my.cnf.services
echo '/etc/init.d/asterisk restart' \
  > /etc/ngcpcfg-config/templates/etc/asterisk/ngcpcfg.services

In this example we created two .services files. Now, each time we trigger a change to /etc/mysql.my.cnf or to /etc/asterisk/* we’ll see that MySQL or Asterisk services will be restarted by the ngcpcfg system.

6.2. config.yml and constants.yml files

The /etc/ngcp-config/config.yml file contains all the user-configurable options, using the YAML (YAML Ain’t Markup Language) syntax.

The /etc/ngcp-config/constants.yml file provides configuration options for the platform that aren’t supposed to be edited by the user. Do not manually edit this file unless you really know what you’re doing.

The /etc/ngcp-config/ngcpcfg.cfg file is the main configuration file for ngcpcfg itself. Do not manually edit this file unless you really know what you’re doing.

6.3. ngcpcfg and its command line options

The ngcpcfg utility supports the following command line options:

apply

The apply option is a short-cut for the options "build && services && commit" and also executes etckeeper to record any modified files inside /etc. It is the recommended option to use the ngcpcfg framework unless you want to execute any specific commands as documented below.

build

The build option generates (and therefore also updates) configuration files based on their configuration (config.yml) and template files (.tt2). Before the configuration file is generated a present .prebuild will be executed, after generation of the configuration file the according .postbuild script (if present) will be executed. If a file or directory is specified as argument the build will generate only the specified configuration file/directory instead of running through all present templates.

Example: to generate only the file /etc/apache2/sites-available/ngcp-www-admin you can execute:

ngcpcfg build /etc/apache2/sites-available/ngcp-www-admin

Example: to generate all the files located inside the directory /etc/apache2/ you can execute:

ngcpcfg build /etc/apache2/

commit

The commit option records any changes done to the configuration tree inside /etc/ngcp-config. The commit option should be executed when you’ve modified anything inside the configuration tree.

help

The help options displays ngcpcfg’s help screen and then exits without any further actions.

initialise

The initialise option sets up the ngcpcfg framework. This option is automatically executed by the installer for you, so you shouldn’t have to use this option in normal operations mode.

services

The services option executes the service handlers for any modified configuration file(s)/directory.

status

The status option provides a human readable interface to check the state of the configuration tree. If you are unsure what should be done as next step or if want to check the current state of the configuration tree just invoke ngcpcfg status.

If everything is OK and nothing needs to be done the output should look like:

# ngcpcfg status
Checking state of ngcpcfg:
OK:   has been initialised already (without shared storage)
Checking state of configuration files:
OK:   nothing to commit.
Checking state of /etc files
OK:   nothing to commit.

If the output doesn’t say "OK" just follow the instructions provided by the output of ngcpcfg status.