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.Cloud Solution Monitoring Business Service Monitoring Asset Management ELK - Log Analytics SOC System Administrator SOC Attacker Centric Cyber Threat Intelligence - SATAYO NetEye Update & Upgrade Backup and Restore How To NetEye Extension Packs Troubleshooting Security Policy Glossary
module icon NetEye Update & Upgrade
Before you start Update Procedure Single Node Upgrade from 4.50 to 4.51 Cluster Upgrade from 4.50 to 4.51 Satellite Upgrade from 4.50 to 4.51 DPO machine Upgrade from 4.50 to 4.51 Create a mirror of the RPM repository Sprint Releases Feature Troubleshooting
NetEye Update & Upgrade Backup and Restore 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 Kubernetes Networking NetEye Satellite Requirements TCP and UDP Ports Requirements Additional Software Installation Introduction Single Node Cluster Kubernetes 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 Satellites Nodes only Verify if a module is running correctly Accessing the New Module Cluster Satellite Security Backup and Restore Identity and Access Management External Identity Providers Configure federated LDAP/AD Emergency Reset of Keycloak Configuration Keycloak Hostname Configuration Advanced Configuration Roles Single Page Application in NetEye Module Permissions and Single Sign On Within NetEye Importing User Federation Groups inside another Group Importing OIDC IdP Groups inside another Group Resource 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 Integration with Elasticsearch VMD Permissions Notifications Jobs API Configuring Icinga Monitoring Retention Policy NetEye Self Monitoring 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 Grafana The NetEye Geo Map Visualizer Map Viewer Configuring Geo Maps NagVis Audit Log 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 Install Alyvix Core Install Alyvix Service Nodes RDP Client Tutorial Overview Example: Windows Start Button Example: Open Windows Settings Example: Web Browser Test Case Example: Authentication Test Case Alyvix Tutorial Video Index Building Tools Editor: Interface Overview Editor: Script Building Editor: Managing Scripts Designer: Interface Overview Designer: Interface Options Designer: Component Tree Selector: Interface Overview Test Case Execution Test Case Format Test Case Management Dashboard Use Cases Overview Architecture Authorization Kibana Elasticsearch Cluster Elasticsearch Configuration Replicas on a Single Node Elasticsearch Performance tuning 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 Rsyslog Elastic APM Elastic RUM Multitenant OpenTelemetry Collector Elastic XDR Overview Authorization in the Command Orchestrator Module Configuring CLI Commands Executing Commands Overview Permissions Installation Plugins 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 The Intelligence We Produce Mitre Attack Coverage Getting Started Settings SATAYO Items Intelligence Requirements Managed Service Request Form FAQ Changelog SATAYO Community NetEye.Cloud as a SaaS solution NetEye.Cloud Subscription Base Concepts Authentication Options Authentication via IdP Group Claims for Authorization Management Authentication via Microsoft Entra ID Roles and Permissions Authorization Navigating the UI Monitoring with NetEye.Cloud Monitored Objects Finding and Filtering Hosts Exporting Monitoring Data Viewing Host and Service Details Organizing with Groups Tactical Overview Problems View Dashboard Typical Daily Interactions Scheduled Downtime Notifications and Alerts AutoDiscovery VMD Business Service Monitoring Business Process Logic Business Process View Asset Management in NetEye.Cloud Automatic Inventory Collection Software & License Management Contract & Supplier Management Change & Lifecycle Management Getting Started with ELK Analytics Overview Discover Dashboards Canvas Maps Machine Learning Graph Visualize Library Observability Overview Alerts Service Level Objectives (SLOs) Cases Logs Infrastructure Applications Synthetic Monitoring User Experience (RUM) SOC System Administrator (AdS) Access to NetEye and Elastic Elastic Dashboards Elastic Discover Elastic Alerts Elastic Rules Introduction to SOC Attacker Centric Service Description NetEye SIEM About SATAYO Getting Started Threat Intelligence and Security Operations How SATAYO works MITRE ATT&CK Coverage SATAYO Platform Dashboard SATAYO Findings SATAYO REST API SaaS & Managed Mode Settings SATAYO MCP Server Graph Exploration Pivot Exploration Before you start Update Procedure Single Node Upgrade from 4.50 to 4.51 Cluster Upgrade from 4.50 to 4.51 Satellite Upgrade from 4.50 to 4.51 DPO machine Upgrade from 4.50 to 4.51 Create a mirror of the RPM repository Sprint Releases Feature Troubleshooting Backup and Restore Tornado Networking Service Management - Incident Response IT Operation Analytics - Telemetry Identity Provider (IdP) Configuration NetEye Cluster on Microsoft Azure NetEye Cluster on AWS Introduction to NEP Getting Started with NEPs Online Resources Obtaining NEP Insights Available Packages Advanced Topics NEP Updates & Upgrades 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 Cyber Resilience Act Compliance Glossary

Single Node Upgrade from 4.50 to 4.51

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

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.51 is possible only from 4.50; 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 Kubernetes Operator

This release will introduce a brand new NetEye Operator which is the component responsible for managing the NetEye deployment in Kubernetes. All configuration and management is made by the standard NetEye CLI procedures such as neteye install and neteye upgrade, but you can configure and override the default configuration by editing the /etc/neteye-environment.yaml file. NetEye CLI procedures will automatically source this configuration file and apply desired changes to the Operator. This upgrade does not require users to update the configuration beforehand since default values will be applied. For the full list of configurable parameters, please refer to the /usr/share/neteye/setup/neteye-environment.yaml.tpl file. To apply the configuration changes during normal operation, you can use the neteye install --restrict-services-to neteye-operator command. This command will apply the configuration changes to the Operator without affecting the other services.

NetEye CA Trust Bundle for Kubernetes Workloads

To ensure that all Kubernetes workloads trust the various Certificate Authorities (CAs) used by external services, for example, when connecting to LDAP servers with Keycloak, users are now required to configure the NetEye CA Trust. To do so, a new configuration directory has been introduced at /neteye/local/rke2/conf/ca-trust/.

This is a breaking change: the workloads running on Kubernetes will no longer trust the CAs installed on the node (for example with update-ca-trust), but only the public CAs shipped with their image, the NetEye root CA and the CAs in this directory. If, before the upgrade, Keycloak relied on a CA added to the node to reach an LDAPS server or an external identity provider, that CA must be added to the directory, otherwise the connection will fail after the upgrade.

The directory is created by the latest updates of NetEye 4.50 and pre-populated with the NetEye root CA and the CAs trusted by the node, that is, the .crt and .pem files in /etc/pki/ca-trust/source/anchors/ and /usr/share/pki/ca-trust-source/anchors/, except for the NetEye root CA and the Icinga 2 master CA, which are already handled by NetEye. Before upgrading:

  1. Identify the private CAs of the services that Keycloak and the other workloads (OpenTelemetry Collector) connect to, including the CA that issued the certificate of the NetEye frontend domain, if it is not the NetEye root CA.

  2. Review /neteye/local/rke2/conf/ca-trust/ on every node of the installation: remove the pre-populated CAs that the workloads do not need and add the missing ones, in PEM format with the .crt or .pem extension. All the nodes must contain the same files. The directory and the files must be owned by root and not writable by their group or by others, and every .crt and .pem file must contain only valid certificates in PEM format (the files copied from the node may also be in other formats, such as DER). Otherwise the upgrade prerequisite checks will fail on that node and explain how to fix each file, or advise removing it if the workloads do not need that CA.

  3. Confirm it in Icinga Web 2: in the configuration of the neteye module, check I am ready to upgrade and save, or run icingacli neteye catrustready enable.

The upgrade prerequisite checks will fail until the confirmation is given. The check is skipped on NetEye Satellites, as they do not run Kubernetes workloads. The directory will be merged into the bundle used by the workloads during the upgrade.

The directory will remain after the upgrade in case you need to trust new CAs. For the content, the pre-population, the format of the files and the commands to apply a change, see Trusted CAs for Kubernetes Workloads.

Prerequisites

Before starting the upgrade, carefully read the latest release notes on NetEye’s blog and check the features that will change or be deprecated.

  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:

    1. 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.

    2. There is a number of configuration items that should not be modified in order to avoid issues during the update/upgrade of your instance. Please check out Protected Configuration Items for details.

  5. NetEye services are progressively moving to Kubernetes to improve scalability, security, resource management and the speed of updates.

    Access to the following domains is strictly required for upgrading to NetEye 4.51: Please ensure that all NetEye nodes can reach these domains over HTTPS (TCP port 443):

    Domain

    Port

    Intended Use

    ghcr.io

    443 TCP

    GitHub container images

    api.github.com

    443 TCP

    GitHub container images

    pkg-containers.githubusercontent.com

    443 TCP

    GitHub container images

    quay.io

    443 TCP

    Quay container images

    cdn01.quay.io

    443 TCP

    Quay container images

    docker.io

    443 TCP

    Docker Hub container images

    hub.docker.com

    443 TCP

    Docker Hub container images

    auth.docker.io

    443 TCP

    Docker Hub container images

    index.docker.io

    443 TCP

    Docker Hub container images

    registry-1.docker.io

    443 TCP

    Docker Hub container images

    production.cloudfront.docker.com

    443 TCP

    Docker Hub container images

    *.cloudflarestorage.com

    443 TCP

    Container images

    rpm.rancher.io

    443 TCP

    Rancher packages

    docker.elastic.co

    443 TCP

    Elastic container images (only with the Elastic Stack)

    docker-auth.elastic.co

    443 TCP

    Elastic container images (only with the Elastic Stack)

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

Keycloak in Kubernetes and the NetEye Operator

After a successful upgrade, you will be required to perform and verify the migration of the Keycloak systemd/pcs instance to the new Keycloak deployment in Kubernetes, which will be an upgrade prerequisite check for future releases. To automate this process, the product ships 3 utility tools and scripts that allow you to perform the validation and migration.

  1. neteye config auth switch-to-kube: This command will switch the authentication configuration from the systemd/pcs instance to the new Keycloak deployment in Kubernetes by updating the necessary configuration files. After successful execution, the systemd/pcs instance will be disabled, and you will be required to test the new environment to ensure that authentication is working as expected.

  2. neteye config auth rollback-from-kube: Should any issues arise with the new Keycloak deployment in Kubernetes, this command will allow you to roll back the authentication configuration to the previous systemd/pcs instance by restoring the necessary configuration files.

  3. neteye config auth cleanup-keycloak-pcs: Finally, once you are satisfied with the new Keycloak deployment, this command will clean up the old systemd/pcs instance by removing any remaining configuration files and data related to the previous Keycloak deployment. Backups of the old configuration files will be created in the /root/keycloak_upgrade_<timestamp>.bck directory. This step is non-reversible, and you will not be able to roll back to the previous systemd/pcs instance after executing this command.

Blog Online Demo Training
Contact Us
© 2026, Würth IT Italy s.r.l.
VAT ID 01054690217
Privacy Cookies