mc_icinga_web / icinga_web functions

when it is written that “each key will be treated as a parameter”, if you add keys in dictionary, they will be added in the configuration file with

<ae:paremeter name="{{key}}">{{value}}</ae:parameter>

when it is written that “foo must be replace with foo value”, you can add as many sub-dictionaries as you want. All sub-dictionaries must have the same structure. It is to avoid a list but in templates it is treated as if there was a list of dictionaries.

I have prefered

'foo': {
    'n1': {
        'param1': "v1",
    },
    'n2': {
        'param1': "v2",
    },
},

instead of

'foo': [
    {'name': "n1",
     'param1': "v1",
    },
    {'name': "n2",
     'param1': "v2",
    },
]

When a real list is kept, It is precised below. Generally it is when the content is not structures but simple values.

The template of xml configuration files use a lot of loops in order to add content easily but it is not the case with the ini files where directives are limited and always the same.

The “nginx” and “phpfpm” sub-dictionaries are given to macros in **kwargs parameter. If you add a key in, you can access in the nginx configuration template or in phpfpm configuration template. In ngin x subdictionary, the “icinga_cgi” and “icinga_web” keys store values used to fill the template.

Otherwise, the first level of subdictionaries is for distinguish configuration files. There is one subdictionary per configuration file. The key used for subdictionary correspond to the name of the file but the ”.” is replaced with a “_”

I have not found dtd/xsd files in order to verify grammar of xml files.

Only the hashed password and the salt for the root account for icinga-web interface are stored in settings. The hashed password is not computed automatically from an other value with the clear password (settings dictionary doesn’t contains the clear password)

I should add a state to compute the hash from clear password but I don’t have successfully done this.

The keys “has_pgsql” and “has_mysql” determine if a local postgresql or mysql instance must be installed. The default value is computed from default database parameters If the connection is made through a unix pipe or with the localhost hostname, the booleans are set to True.

The default parameters for icinga_ido database connection are get from icinga settings.

In the templates, I didn’t perform a lot of check. For example if a value must be set only if a other directive has a precise value, I didn’t add a if statement. It is possible to create invalid configuration files.

If in a list, each value must be unique, I tried to have the elements of the list as dictionary keys.

For optional values which don’t have a default value, I didn’t set them in the default dictionary but in the templates, I have done:

{% if data.get('foo', None) %}
foo={{data.foo}}
{% endif %}

Theses optional values corresponds to commented keys in the default dictionary.

mc_states.modules.mc_icinga_web.settings()

icinga_web settings

location
installation directory
package
list of packages to install icinga-web
configuration_directory
directory where configuration files are located
has_pgsql
install and configure a postgresql service in order to store icinga-web data (no ido2db data)
has_mysql
install and configure a mysql service in order to store icinga-web data (no ido2db data)
modules
nagvis
enable
enable the nagvis module which add link to nagvis in icinga-web
cronks_xml
dictionary to store the cronks. The content is added in cronks.xml. The structure is the same that ‘cronks_xml’ subdictionary.
pnp4nagios
enable
enable the pnp4nagios module which add links to graphs in icinga-web
package
package to install for pnp4nagios integration
cronks_extensions-templates
dictionary in which, each key is the name of an extension template and the content of the dictionary contains the values to fill the template each ‘key’: “value” produce a “<parameter name={{key}}>{{value}}</parameter>”. The key “parameter” or “parameter_*” produce a “<parameter></parameter>” tag. Each subdictionary add sub parameters tags.
root_account

Dictionary to store root account information. It is the account created on first installation of icinga_web

login
login for root login on web interface
hashed_password
password for root login on web interface
salt
salt used to hash the password
databases

dictionary to store databases connections parameters

ido2db

dictionary to store ido2db database connection parameters

type
type of sgbd used “pgsql” or “mysql”
host
host used for connection
port
port used for connection
user
user used for connection
password
password used for connection
name
database name
prefix
prefix used in table’s names
web

dictionary to store icinga-web database connection parameters

type
type of sgbd used “pgsql” or “mysql”
host
host used for connection
port
port used for connection
user
user used for connection
password
password used for connection
name
database name
nginx

dictionary to store values of nginx configuration

domain
name of virtualhost created to serve webpages
doc_root
root location of virtualhost
vh_content_source
template file for nginx content file
vh_top_source
template file for nginx top file
icinga_web

dictionary to store values used in templates given in vh_content_source and vh_top_source

web_directory
location under which webpages of icinga-web will be available
images_dir
directory where images used by icinga-web are stored
styles_dir
directory where css used by icinga-web are stored
bpaddon_dir
directory where bpaddon scripts are located
ext3_dir
directory where ext3 scripts are located
fastcgi_pass
socket used to contact fastcgi server in order to interpret php files
phpfpm

dictionary to store values of phpfpm configuration

open_basedir
paths to add to open_basedir
extensions_package
additional packages to install (such as php5-pgsql or php5-mysql for php database connection)
doc_root
root location for php-fpm
session_auto_start
must be 0 to run icinga-web