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