Architecture

Application components

The NConf application consists of a PHP part and a Perl part. All GUI specific functionality is implemented in PHP. Authentication modules and install/update functionality is also implemented in PHP.
Background functionality such as import and export of Nagios configuration files is implemented in Perl. Any command-line scripts, which use the database API, are also programmed in Perl.
The database is a MySQL DB which uses InnoDB for referential integrity checking.

The components of the NConf application

The classes

The complete NConf domain model: all classes and their relationships

NConf consists of 15 default classes that roughly represent the configuration objects available in Nagios. Some proprietary classes were introduced to facilitate the handling and to allow inheritance of certain properties.

Each class has multiple attributes. Most of the attributes are Nagios specific. Some proprietary attributes were added to allow additional functionality.

The GUI offers the possibility to add additional attributes and classes, or modify existing ones. This is usually not necessary, since NConf already comes with a schema that covers all necessary Nagios features. Small modifications to the default values of attributes, to their description or their ordering within the GUI might be useful.

Warning

Users are strictly discouraged from changing attribute names, attribute datatypes, the “naming attr” flag, from modifying classes in any way and from any other changes, which are not ordinary data mutations. No support will be given in any way, should a user decide to tamper with the standard schema!

The web-frontend

As already addressed, the web interface is implemented in PHP. All views and forms are implemented as dynamically as possible, so that no changes to the PHP code are necessary, if Nagios configuration attributes change.

Each HTML form is generated dynamically based on the information in the ConfigAttrs table. This allows us to drastically reduce the amount of code required for general functionality (add/modify/delete). Some exceptions exist for host and service items.

The database

To guarantee maximum flexibility towards future changes to the Nagios software, we chose to implement a very abstract data model (EAV data model) that would allow us to reproduce any objects available within Nagios. You will not find any classic tables in the database such as “host”, “service” etc. Instead, we abstracted each object type to a so called “configuration item”. Each item is linked to a certain “class” and has multiple “attributes” assigned to it. A class roughly represents a Nagios config file. Attribute values are stored separately from attributes, so that attributes only need to be defined once. Items can be linked with each other.

An example:

  • Item “12” is of class “host” and has an attribute called “host_name” assigned to it.
  • Its value is “myhost-01”. Item “12” is linked to item “14” which is of class “hostgroup”.
  • Item “14” has an attribute called “hostgroup_description”.
  • Its value is “hostgroup-01”.
Entity-relationship diagram of the NConf DB

An example query to replace values in the DB

/* Replace a string in all host's "address" attributes */
UPDATE ConfigValues, ConfigAttrs, ConfigClasses
  SET ConfigValues.attr_value = REPLACE(attr_value,'192.168.1.','10.110.1.')
  WHERE ConfigValues.fk_id_attr=ConfigAttrs.id_attr
    AND ConfigAttrs.fk_id_class=ConfigClasses.id_class
    AND ConfigClasses.config_class="host"
    AND ConfigAttrs.attr_name="address";

More information regarding configuration attributes:

The “ConfigAttrs” table is the most complex table in the database. It holds the individual configuration items that the Nagios config files consist of. It is also used to influence the appearance of the web interface. Each attribute is linked to a class. The PHP logic of the web interface simply selects all attributes linked to a certain class and generates HTML forms based on the parameters defined in the ConfigAttrs table: Is an attribute visible, how many characters can it hold, does it have a default value, is it mandatory, what is the ordering?

The most important information is the attribute’s “datatype”.
The following types exist:

  • text
    an attribute that can hold a max text value of 1024 characters
  • password
    an attribute that can hold a max text value of 1024 characters and is handled as a password
  • select
    an attribute that allows the user to select one value from a predefined list of values
  • assign_one
    an attribute that allows the user to assign an item to another item

Other important attribute parameters are the following:

  • “naming_attr” defines if an attribute is the “naming attribute” of a certain class. Naming attributes are used to display items within menus. The naming_attr of the “host” class for instance would be the hostname. Each class can only have one naming_attr. The naming_attr is always a mandatory parameter.
  • “link_as_child” is set to “no” by default. It is necessary where the items displayed in a menu should be linked to another item as its children. For example, if the user is adding a hostgroup and he selects hosts that should be assigned to that hostgroup, then the items selected will become the hostgroup’s children. Otherwise items selected in a menu will always be linked as parent items.
  • “fk_show_class_items” defines which items to show in a drop-down / multi-select menu. It defines what class of items to link.
  • Linking of “assign_one”, “assign_many” and “assign_cust_order” attributes is done over the ItemLinks table. Child items are always stored in the “fk_id_item” column, parent items in the “fk_item_linked2” column. The attribute id from the ConfigAttrs table is also stored each time, to allow multiple links between the same classes.