NEP distribution logic¶
A NetEye Extension Pack (NEP) is essentially a way to create objects inside NetEye. It consists of several configuration items that describe the creation process for each object. These objects are not created during the installation and configuration of the NEP itself: the end user must decide when to create or update the related NetEye objects. This will prevent collateral damage due to automated setup/upgrade processes, allowing the end user to prepare for the upgrade process.
An NEP can be imported immediately, or it may depend on one or more NEPs, which means that it may require one or more other NEPs to be installed first. After being imported, all the provided objects are available for use almost out of the box (in general, only minimal or zero configuration is required).
As stated above, an NEP may require one or more other NEP Packages to be installed before being installable. In fact, all packages create a tree-like structure where each NEP extends that tree with its own objects. This structure reduces the number of unused objects to a minimum, resulting in a smaller footprint for the whole design.
What can be shipped with an NEP¶
The latest revision of the NEP Package provides support for:
Definitions of Monitoring Objects (in the form of Director Objects)
Although not officially supported, NEPs can still provide other kinds of objects.
An NEP Package is a method of distribution. It is versioned, and each version has a specific structure, allowing specific extension contents to be distributed. While a number of extension contents are supported by a specific package version, the package itself can contain objects that are originally not expected as custom (optional) contents. The package can also contain optional scripts to run before and after the main setup phase. Each NEP is packed inside one or more RPM files available through Wuerth Phoenix Repositories.
Latest Pack structure¶
Here is the structure for the latest version of the NEP Package:
Package v0.1 ├───prerequisites.txt ├───prerequisites.ini ├───baskets │ ├───import │ └───import_once ├───plugins ├───custom_files │ ├───system_root │ ├───neteye_local_root │ └───neteye_shared_root │ └───icinga2 │ ├───conf │ └───data ├───itoa ├───doc └───setup_scripts ├───pre └───post
The current version can accommodate:
Configuration files for NetEye (Shared and Local)
Optional pre-setup scripts
Optional post-setup scripts
NEP contents logic¶
Objects imported from NEPs are supposed to be immutable: in general, they should not be edited or changed. Of course some exceptions are allowed, but the fundamental idea is that what has been imported from an NEP can be changed only by the NEP itself. If an object coming from a NEP has to be edited, it must be cloned into a new one.
This approach supports an easy update procedure in case a newer version of the same NEP is released. Also, in the case of unrecoverable changes, all NEP objects can be recreated without fear of losing their customizations.