Configuration of the fleet to be supervised¶

The configuration of the fleet to be monitored is done through XML files. These files are stored in the directory pointed to by the " confdir " in " vigiconf " in the configuration file VigiConf . Sample files are installed when VigiConf is installed .

This chapter presents the configuration structure and the content of the different files.

For this chapter, all the file or folder locations indicated relate to the fleet configuration folder (by default, / etc / vigilo / vigiconf / conf.d / ).

Host Configuration¶

The “ hosts ” folder contains the definition files for the park's supervised hosts. All XML files in this folder are analyzed and must contain the definition of one or more hosts.

The tag at the root of this document is called “ hosts ” and can contain one or more “ host ” blocks , each corresponding to the definition of a host.

The following code fragment recalls the general structure of the file:

<? xml version = "1.0"?>
<hosts>
  <host name = "host1" attr1 = "..." attr2 = "..." attrN = "..." >
    ...
  </host>
  <host name = "host2" attr1 = "..." attr2 = "..." attrN = "..." >
    ...
  </host>
  ...
</hosts>

Definition of a host¶

A host is defined using a host tag having the following form :

<host name = "localhost" address = "127.0.0.1" ventilation = "PF" >
  ...
</host>

Host attributs¶

A host data block has the following attributes:

name
[ required ] Host name. It can be a fully qualified name (FQDN) or simply a short name used to identify the equipment within the fleet.

address
[ optional ] Address to communicate with the host. It can be an IP address (v4 or v6) or a fully qualified domain name (FQDN). If this attribute is omitted, the value of the name attribute is used.

ventilation
[ optional ] Name of the supervision group in which this host must be placed (broken down).

In general, it is not necessary to specify this attribute. VigiConf tries to deduce it automatically from the names of the groups to which the host is attached. This attribute is primarily used to resolve conflicts between groups. It can also be used to assign the host to a management group that has no relation to business groups.

Host tags¶

The host tag can contain the following tags

“ Class ” tag¶

Syntax:

< class > class name </class>

Indicates the class or classes of equipment to which the host belongs. Depending on these classes, specific tests may be available in order to obtain more precise information on the condition of the equipment.

“ Template ” tag¶

Syntax:

< template > name of the model </ template >

Specifies the name of the host model from which this host inherits some of its properties. The use of inheritance is practical when your fleet is composed of homogeneous elements (servers, routers, etc.). You can then define a template for each type of equipment with all the associated tests and then simply create a host definition for each equipment.

This tag can be used repeatedly. The parameters of the last loaded model overwrite those of the previous models. Values defined at a host level always overwrite values defined at a legacy model (in particular, test parameters).

“ Test ” tag¶

Syntax:

< test name = "test name" >
  < arg name = "nom_argument_1" > value argument 1 </arg>
  < arg name = "nom_argument_2" > value argument 2 </arg>
  ...
  < arg name = " nom_argument_n " > value argument n </arg>
  < nagios >
    < directive name = "nom_directive_1" > value directive 1 </directive>
    ...
    < directive name = " nom_directive_n " > value directive n </directive>
  </ nagios >
</test>

The test tag allows you to add a supervision test to the host. It has a mandatory name attribute which designates the supervision test to be applied (for example: “ CPU ” to supervise the processor state of an equipment).

A test accepts zero, one or more arguments, which must be passed in order when declaring the test, using the arg tag . Each argument has a name ( name attribute ) and a value (or list of values). To specify a list of values for an argument, the item subtag must be used, as in the following extract:

<test name = "ACL" >
    < arg name = "policy" > whitelist </ arg >
    <! -
        The " addresses " argument is a list of IP addresses,
        under -networks or hostnames.
    ->
    < arg name = "addresses" >
        <item> 127.0.0.1 </item>
        <item> localhost </item>
        <item> 192.168.0.0/24 </item>
    </arg>
</test>

Each argument has a type (specified in the test documentation). The recognized types are:

the strings;
the integers;
the relative numbers (floating);
the Boolean (use the value 1 , true , one or yes to the value True or 0 , false , off or no for the value False ).

You can also, optionally, define specific parameters for supervision using the nagios tag , which will contain one or more directives addressed to the Nagios supervision engine. See the section below for more information.

Remarks¶

Each host implicitly inherits a model called “ default ”. All the directives defined in the “ default ” model are therefore applied to the configuration of the different hosts, even if these hosts do not explicitly indicate that they are using this model, via the < template > tag . See the chapter Host Configuration for more information.

Host template configuration¶

The “ hosttemplates ” folder contains the definition files for host models. A host model is used to group a set of configuration elements common to several hosts. Hosts can then be declared as inheriting from this pattern. All XML files in this folder are analyzed and must contain the definition of one or more models.

The tag at the root of this document is called “ hosttemplates ” and can contain one or more “ hosttemplate ” blocks , each corresponding to the definition of a host.

The following code fragment recalls the general structure of the file:

<? xml version = "1.0"?>
< hosttemplates >
    < hosttemplate attr1 = "..." attr2 = "..." attrN = "..." > ... </ hosttemplate >
    < hosttemplate attr1 = "..." attr2 = "..." attrN = "..." > ... </ hosttemplate >
...
</ hosttemplates >

A hosttemplate data block has the following attributes:

name : Name of the model.

A hosttemplate data block contains the following blocks

“ Parent ” tag¶

A parent data block contains a simple character string, the name of the template from which this template inherits. It is possible to create as many levels of template inheritance as desired and each template can inherit from one or more templates (multiple inheritance).

Example:

< parent > generic </parent>

“ Class ” tag¶

A class data block contains a single character string.

Example :

<class> aix </class>

“ Test ” tag¶

A test data block has the following attribute:

name (exactly 1)

A test data block contains the following blocks, in order:

arg (0 or more)
nagios (0 or 1)

Refer to the documentation on configuring the tests of a host for more information on the attributes and blocks accepted by this tag.

Example :

<test name = "Proc" >
  < arg name = "label" > aixmibd </ arg >
  < arg name = " processname " > . * aixmibd . * </ arg >
  < nagios > ... </ nagios >
</test>

Using SNMPv3¶

Using SNMP version 3 requires a little more configuration than for SNMP version 1 or 2c. Indeed, in addition to the definition of the equipment community, it is necessary to specify the security elements making it possible to authenticate the connection to the equipment and / or to ensure the confidentiality of SNMP exchanges with the equipment. .

No special test is to be applied to use SNMPv3 in Vigilo. However, additional attributes must be defined in the configuration of the equipment working with SNMPv3.

The following listing shows an example configuration of a host to be queried using SNMPv 3:

< attribute name = " snmpVersion " > 3 </ attribute >
< attribute name = " snmpSeclevel " > authPriv </ attribute >
< attribute name = " snmpAuthproto " > MD5 </ attribute >
< attribute name = " snmpPrivproto " > DES </ attribute >
< attribute name = " snmpSecname " > snmpuser1 </ attribute >
<attribute name = " snmpAuthpass " > 12345678 </attribute>
<attribute name = " snmpPrivpass " > 12345678 </attribute>

Attribute names follow standard SNMPv3 terminology, except for the prefix “ snmp ” which is used only to prevent possible naming conflicts with other similar attributes.

The role of each of these attributes is explained below :

The attribute “ snmpVersion ” indicates that it is version 3 of the SNMP protocol which must be used to interrogate the equipment.

The “ snmpSeclevel ” attribute indicates the security constraints to be applied to communications with the equipment. The possible values are :
- “ NoAuthNoPriv ” (no authentication / no privacy ) : no authentication takes place and exchanges are not encrypted. This value corresponds to what is provided by SNMPv1 and SNMPv2c and does not offer any security . It is therefore recommended not to use this value (except in exceptional cases).
- “ AuthNoPriv ” ( authentication / no privacy ) : Vigilo will authenticate with the device with a dedicated username and password. Exchanges with the equipment will not be encrypted and communications can therefore be listened to by anyone with physical access to the network.
- “ AuthPriv ” ( authentication / privacy ) : Vigilo will authenticate with the device with a dedicated username and password. In addition, all exchanges will be encrypted. This value is the one offering the most security and is therefore recommended.

The “ snmpAuthproto ” attribute is mandatory when “ snmpSeclevel ” is equal to “ authNoPriv ” or “ authPriv ” and specifies the algorithm used to mask the password during transmissions with the equipment. The possible values are “ MD5 ” and “ SHA1 ”.

The “ snmpPrivproto ” attribute is mandatory when “ snmpSeclevel ” is “ authPriv ” and specifies the encryption algorithm used for exchanges with the equipment. The possible values are “ DES ” and “ AES ”.

The attribute “ snmpSecname ” is mandatory when “ snmpSeclevel ” equals “ authNoPriv ” or “ authPriv ” and indicates the user name with which Vigilo will authenticate with the device.

The attribute “ snmpAuthpass ” is mandatory when “ snmpSeclevel ” equals “ authNoPriv ” or “ authPriv ” and indicates the password to be used to authenticate with the device. It can be given in text form (as in the example above) or in the form of a hexadecimal character string by prefixing the value with “ 0x ”.

The “ snmpPrivpass ” attribute is mandatory when “ snmpSeclevel ” is equal to “ authPriv ” and specifies the encryption key used for exchanges with the equipment. It can be given in text form (as in the example above) or in the form of a hexadecimal character string by prefixing the value with “ 0x ”.

Display of known tests¶

VigiConf's known tests can be displayed with the “ vigiconf list -tests ” command .

The output displays two types of information, the available host classes, and the tests for each host class:

Host classes available :
    aix , alcatel , all, apc , as400, bigip , bigip_v11, bluecoat, cisco,
    cisco_ios , cisco_sensors , dell_openmanage , dell_openmanage_snmp ,
    dictao , eaton , expand, extremenetworks , liebert , linux , lmsensors ,
    netapp , netasq , netdata , netflow , netware , nokia , nortel470,
    nortel5510, nortel8310, nsclient , overland, packeteer , paloalto ,
    rapidcity , spectracom_netclock , spectracom_securesync , toip , ucd ,
    vmware , windows , xmperf .

Tests for the host class ' aix ':
    CPU, Errpt , Fans, Load, Power, Process, RAM, Temperature.

Tests for the host class ' alcatel ':
    CPU, Fans, RAM, Temperature .

The output of this command supports two formats, the text format, by default, is that of the example above, and the JSON format . This formatting can be changed by completing the command with “ --format = json ”.

Configuration deployment¶

Once the configuration of the various elements of the fleet is complete, you can deploy it on the various supervision machines using the “ vigiconf deploy ” command .

You can pass in argument the list of names of the supervision servers for which a new version of the configuration must be deployed.

Project

General

Profile

Wiki

Configuration of the fleet to be supervised¶

Host Configuration¶

Definition of a host¶

Host attributs¶

Host tags¶

“ Class ” tag¶

“ Template ” tag¶

“ Test ” tag¶

Remarks¶

Host template configuration¶

“ Parent ” tag¶

“ Class ” tag¶

“ Test ” tag¶

Using SNMPv3¶

Display of known tests¶

Configuration deployment¶