User Guide Functional Overview Requirements Architecture System Installation NetEye Additional Components Installation Setup The neteye Command Director NetEye Self Monitoring Tornado Business Service Monitoring IT Operation Analytics - Telemetry Geo Maps NagVis Audit Log Shutdown Manager Reporting ntopng Visual Monitoring with Alyvix Elastic Stack IT Operations (Command Orchestrator) Asset Management Service Level Management Cyber Threat Intelligence - SATAYO NetEye Update & Upgrade How To NetEye Extension Packs Troubleshooting Security Policy Glossary
module icon NetEye Update & Upgrade
Before you start Update Procedure Single Node Upgrade from 4.41 to 4.42 Cluster Upgrade from 4.41 to 4.42 Satellite Upgrade from 4.41 to 4.42 DPO machine Upgrade from 4.41 to 4.42 Create a mirror of the RPM repository Sprint Releases Feature Troubleshooting
NetEye Update & Upgrade How To NetEye Extension Packs Troubleshooting Security Policy Glossary Introduction to NetEye Monitoring Business Service Monitoring IT Operation Analytics Visualization Network Visibility Log Management & Security Orchestrated Datacenter Shutdown Application Performance Monitoring User Experience Service Management Service Level Management & Reporting Requirements for a Node Cluster Requirements and Best Practices NetEye Satellite Requirements TCP and UDP Ports Requirements Additional Software Installation Introduction Single Node Cluster NetEye Master Master-Satellite Architecture Underlying Operating System Acquiring NetEye ISO Image Installing ISO Image Single Nodes and Satellites Cluster Nodes Configuration of Tenants Satellite Nodes Only Nodes behind a Proxy Additional NetEye Components Single Node Cluster Node Satellites Nodes only Verify if a module is running correctly Accessing the New Module Cluster Satellite Security Identity and Access Management External Identity Providers Configure federated LDAP/AD Emergency Reset of Keycloak Configuration Advanced Configuration Authorization Resources Tuning Advanced Topics Basic Concepts & Usage Advanced Topics Monitoring Environment Templates Monitored Objects Import Monitored Objects Data Fields Deployment Icinga 2 Agents Configuration Baskets Dashboard Monitoring Status VMD Permissions Notifications Jobs API Configuring Icinga Monitoring Retention Policy NetEye Self Monitoring 3b Concepts Collecting Events Add a Filter Node WHERE Conditions Iterating over Event fields Retrieving Payload of an Event Extract Variables Create a Rule Tornado Actions Test your Configuration Export and Import Configuration Example Under the hood Development Retry Strategy Configuration Thread Pool Configuration API Reference Configure a new Business Process Create your first Business Process Node Importing Processes Operators The ITOA Module Configuring User Permissions Telegraf Metrics in NetEye Telegraf Configuration Telegraf on Monitored Hosts Visualizing Dashboards Customizing Performance Graph The NetEye Geo Map Visualizer Map Viewer Configuring Geo Maps NagVis 3b Audit Log 3b Overview Shutdown Manager user Shutdown Manager GUI Shutdown Commands Advanced Topics Overview User Role Management Cube Use Cases ntopng and NetEye Integration Permissions Retention Advanced Topics Overview User Roles Nodes Test Cases Dashboard Use Cases Overview Architecture Authorization Elasticsearch Overview Enabling El Proxy Sending custom logs to El Proxy Configuration files Commands Elasticsearch Templates and Retentions El Proxy DLQ Blockchain Verification Handling Blockchain Corruptions El Proxy Metrics El Proxy Security El Proxy REST Endpoints Agents Logstash Elastic APM Elastic RUM Log Manager - Deprecated Overview Authorization in the Command Orchestrator Module Configuring CLI Commands Executing Commands Overview Permissions Installation Single Tenancy Multitenancy Communication through a Satellite Asset collection methods Display asset information in monitoring host page Overview Customers Availability Event Adjustment Outages Resource Advanced Topics Introduction Getting Started SATAYO Items Settings Managed Service Mitre Attack Coverage Changelog Before you start Update Procedure Single Node Upgrade from 4.41 to 4.42 Cluster Upgrade from 4.41 to 4.42 Satellite Upgrade from 4.41 to 4.42 DPO machine Upgrade from 4.41 to 4.42 Create a mirror of the RPM repository Sprint Releases Feature Troubleshooting Tornado Networking Service Management - Incident Response IT Operation Analytics - Telemetry Identity Provider (IdP) Configuration Introduction to NEP Getting Started with NEPs Online Resources Obtaining NEP Insights Available Packages Advanced Topics Upgrade to NetEye 4.31 Setup Configure swappiness Restarting Stopped Services Enable stack traces in web UI How to access standard logs Director does not deploy when services assigned to a host have the same name How to enable/disable debug logging Activate Debug Logging for Tornado Modules/Services do not start Sync Rule fails when trying to recreate Icinga object How to disable InfluxDB query logging Managing an Elasticsearch Cluster with a Full Disk Some logs are not indexed in Elasticsearch Elasticsearch is not functioning properly Reporting: Error when opening a report Debugging Logstash file input filter Bugfix Policy Reporting Vulnerabilities Glossary 3b

Single Node Upgrade from 4.41 to 4.42

This guide will lead you through the steps specific for upgrading a NetEye Single Node installation from version 4.41 to 4.42.

Upgrading a NetEye Single Node takes a nontrivial amount of time. Granted the environment connectivity is seamless, the upgrade procedure may take up to 30 minutes.

Warning

Remember that you must upgrade sequentially without skipping versions, therefore an upgrade to 4.42 is possible only from 4.41; for example, if you have version 4.27, you must first upgrade to the 4.28, then 4.29, and so on.

Breaking Changes

NetEye SIEM feature module renaming

From NetEye 4.42 onwards, the SIEM feature module is now called Elastic Stack. This change better reflects the module’s functionalities, which encompass the entire Elastic Stack, including Observability and not only SIEM.

This change includes:

  1. In the User Guide, the feature module will be referred to as Elastic Stack instead of SIEM

  2. To install the feature module on systems without it, use the dnf group neteye-elastic-stack instead of neteye-siem, as explained :ref:here <neteye-modules>.

  3. If you have NetEye SIEM installed, upgrading to 4.42 will automatically install the dnf group neteye-elastic-stack.

To ensure a smooth transition, the old dnf group neteye-siem will remain installed after the upgrade but will be removed in future NetEye versions. Any custom integration or automation relying on the presence of the old neteye-siem dnf group will continue to function as before. However, you should update it to refer to the new neteye-elastic-stack dnf group to prepare for the removal of the old group in future versions.

MariaDB Galera Cluster

During the upgrade to NetEye 4.42, MariaDB will be migrated to a MariaDB Galera Cluster. This improvement will enhance the reliability of the database system on NetEye clusters since the service will be distributed across multiple nodes instead of relying on a single instance. This will not only enhance the general reliability of the database system but also improve and minimize the downtime of the database and all the services that rely on it in case of a node failure or a service restart. For system consistency, the MariaDB Galera migration will be performed also on NetEye single-node installations, where the MariaDB instance will be migrated to a single-node Galera Cluster.

Deprecated Settings

With the transition to MariaDB Galera Cluster in NetEye 4.42, several default settings and functionalities have been updated or deprecated. Please review the following changes to ensure compatibility and optimal performance:

Directory Location Change

With the migration to MariaDB Galera Cluster, the MariaDB directory has been moved from /neteye/shared/mysql to /neteye/local/mariadb. This is a breaking change that affects any custom backup scripts targeting the old location, monitoring configurations checking the old path, and custom integrations or automations accessing data/configuration in the old location.

All custom MariaDB configuration files placed in the my.cnf.d folder will be automatically migrated to the new directory during the upgrade process.

If you have any scripts, monitoring, or configurations that reference the old path, please update them to use the new location to ensure proper functionality after the upgrade.

User Privileges Management

In Galera Cluster, modifying user privileges requires the use of the GRANT statement. Directly inserting into the mysql.user table (e.g., INSERT INTO mysql.user ...) is not supported and will not propagate changes across the cluster. Always use GRANT to ensure consistent and reliable privilege updates.

Unsupported Locking Mechanisms

The following locking operations are not supported in Galera Cluster and may lead to errors or undefined behavior:

  • LOCK TABLES and UNLOCK TABLES

  • GET_LOCK and RELEASE_LOCK

If you have custom applications interacting with the MariaDB database, please ensure they do not perform these operations and consider using alternative methods for synchronization and locking, such as transactions or application-level locks.

More information about the differences between MariaDB and Galera Cluster can be found in the Official Galera documentation

Large Pages Support

If you have previously configured or wish to configure large pages for MariaDB performance optimization (using innodb_large_prefix setting), please note that with the migration to Galera Cluster, you will need to create a systemd drop-in file for the mariadb-galera.service to grant the necessary CAP_IPC_LOCK capability to the service. This configuration is not automatically migrated during the upgrade and requires manual intervention only if you need large pages support.

Galera volume on Single Node

In NetEye single node installations, the MariaDB folder that is usually placed in /neteye/shared/mysql will be automatically moved in the new path /neteye/local/mariadb/.

If your NetEye single-node installation uses a specific custom mounted volume for MariaDB that is different from the default one (where the /neteye/shared/mysql folder is part of the main /neteye volume), a manual step is needed before upgrading to 4.42. In order to grant a smooth upgrade, please follow these steps:

  1. Stop the MariaDB service

  2. Create the directory /neteye/local/mariadb/ if it does not exist

  3. Move your logical volume mounting it to the new path (/neteye/local/mariadb/)

    Here is an example of how to do this, but please adapt it to your environment depending on the paths and logical volumes you are using:

    umount /neteye/shared/mariadb
mount <your-lv> /neteye/local/mariadb/
  4. Ensure that the /neteye/shared/mysql/data directory is empty and /neteye/local/mariadb/ is mounted

    correctly and has the expected data.

  5. Launch the upgrade process

Prerequisites

Before starting the upgrade, you should read very carefully the latest release notes on NetEye’s blog and check out the features that will be changed or deprecated after the upgrade.

  1. All NetEye packages installed on a currently running version must be updated according to the update procedure prior to running the upgrade.

  2. NetEye must be up and running in a healthy state.

  3. Disk Space required:

    • 3GB for / and /var

    • 150MB for /boot

  4. If the NetEye Elastic Stack module is installed:

    • The rubygems.org domain should be reachable by the NetEye Master only during the update/upgrade procedure. This domain is needed to update additional Logstash plugins and thus is required only if you manually installed any Logstash plugin that is not present by default.

  5. We’ve deprecated the default option in Proxy IP Mode under Configuration / Modules / neteye / Configuration. You can check how to configure it here

  1. To prepare for the MariaDB Galera migration, ensure the following:

    • Port 3307 must be free and available on the NetEye node interface

    • As mentioned in the breaking changes section: If using a custom dedicated volume for the MySQL directory, the content of /neteye/shared/mysql must be manually migrated before the upgrade

    In order to grant a smooth upgrade, consider launching the command neteye node check-upgrade-prerequisites before the upgrade to check if the prerequisites are met.

1. Run the Upgrade

To perform the upgrade, run from the command line the following command:

neteye# (nohup neteye upgrade &) && tail --retry -f nohup.out

After the command was executed, the output will inform if the upgrade was successful or not:

  • In case of successful upgrade you might need to restart NetEye to properly apply the upgrades. If the reboot is not needed, please skip the next step.

  • In case the command fails refer to the troubleshooting section.

2. Reboot

Restart NetEye to apply the upgrades correctly.

neteye# neteye node reboot

3. Additional Tasks

Enabling of the Content-Security-Policy (CSP) header

With the upgrade to IcingaWeb2 2.12.x we allow you to enable the Content-Security-Policy (CSP) header for the NetEye web interface. The CSP header helps protect your NetEye installation from cross-site scripting (XSS) attacks. The toggle for this can be found in the NetEye web interface under Configuration > Application > Enable strict content security policy.

Warning

The strict CSP header feature must be enabled before upgrading to the next release of NetEye (4.43).

IcingaWeb2 modules migration

Please make sure that all third-party icingaweb2 modules installed on the system are compatible with the CSP policies before enabling this feature to avoid any issues.

To do it you can follow the steps below:

  1. Check and in case fix/upgrade a module.

  2. Enable the strict CSP flag from the IcingaWeb2 settings.

  3. Verify if everything is working.

  4. In case of problems:

    1. Disable the flag.

    2. Fix the incompatibilities.

    3. Repeat from step 1.

  5. Repeat the process for the next module.

SLM report styling under the Content-Security-Policy (CSP) header

With the introduction of the CSP headers, we had to make minor breaking changes to the way styling is handled in the SLM reports. SLM reports can no longer use the inline style attributes. If any were used in a custom template, they now need to be migrated to the html style elements and applied with classes. Furthermore, if any html style elements are used in the custom template, they will now need to be updated to include the icingaweb2 style nonce to be compliant with the CSP header. Please refer to the appropriate section in the customizing templates section of the documentation for more information.

Blog Online Demo Training
Contact Us
© 2025, Wuerth Phoenix S.r.l.
VAT ID 01054690217
Privacy Cookies