User Guide

Single Node Upgrade from 4.31 to 4.32

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

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.32 is possible only from 4.31; for example, if you have version 4.27, you must first upgrade to the 4.28, then 4.29, and so on.

Breaking Changes

Smart Director removal

In NetEye 4.32, we upgraded Icinga2 from version 2.11.9 to version 2.14.0, which comes with the drop of the Instant Deploy feature of the Smart Director.

For the purpose of making a good transition to the new NetEye version, we introduced a dedicated health check that ensures the Instant Deploy feature of the Smart Director is disabled before executing the upgrade.

The Instant Deploy feature can be manually disabled by unchecking the flag that can be found in Configuration > Modules > smartdirector in the Configuration tab. Once the upgrade to 4.32 has been completed the Smart Director module will be completely removed from NetEye installations.

Tornado - Legacy deprecation

In NetEye 4.32, “Tornadocarbon” module moves out from preview and becomes the official GUI of Tornado.

For this reason, Tornado GUI available in NetEye versions prior to 4.32 is deprecated and renamed into “Tornado - Legacy”. “Tornado - Legacy” module will be completely removed from NetEye 4.34 (31.01.2024).

The user permissions will be automatically migrated to the new Tornado GUI module during the upgrade procedure.

El Proxy

With NetEye 4.32, El Proxy will automatically start writing its blockchain on Elasticsearch data streams to improve how index rollover is managed and avoid the so-called Elasticsearch oversharding. This change causes the breaking changes described below.

Kibana Analytics on Blockchains

This migration to data stream implicates that the index pattern used for El Proxy blockchain changes from *-*-elproxysigned-<tenant>-<retention>-<tag>-* to *-*-elproxysigned-<tenant>-<retention>-<tag> (note the missing -* representing the date of the index).

This means that if you have any Kibana visualizations on El Proxy blockchains you should migrate them, otherwise they will only display old El Proxy data.

To include both old data and new data in your Kibana Analytics objects (i.e. the objects shown in the screenshot below), you can create a new data view that includes old data as well as new data and use this index pattern in your visualizations. For example, the index pattern can be set to: *-*-elproxysigned-<tenant>-<retention>-<tag>* to account for both the presence and the absence of the date at the end of the index/data stream

../../_images/analytics-objects.png

Removal of Retention warning

From NetEye 4.32, the El Proxy verify command will not report a warning anymore in case it finds logs older than the retention period in the verified blockchains. This is due to the fact that logs recovered via the dlq recover command may remain in Elasticsearch for a longer period of time with respect to their expected retention period in case they are recovered days or weeks after ending up in DLQ.

Support for Beats 7.17

From NetEye 4.32 the Beats agents with version 7.17 or smaller that send their data to El Proxy, will match the generic index templates of El Proxy and not the index template of the specific Beat.

To ensure Beats logs will match their specific index templates please upgrade your Beats agents to version 8.8.2 before upgrading NetEye to version 4.32.

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 you are an El Proxy user and you created a custom retention for El Proxy in addition to the standard retentions, please ensure you declared the retention in /neteye/shared/elastic-blockchain-proxy/conf/retention_policies.d/.

    If not, please create a .toml file in /neteye/shared/elastic-blockchain-proxy/conf/retention_policies.d/ with a content like the following:

    [1_month]
    duration_in_days = 30
    

    Note

    Substitute 1_month with the name of your retention and duration_in_days with the duration of your retention

    This operation is needed because from NetEye 4.32 the custom retentions for El Proxy will be managed by NetEye, which will for example set the Elasticsearch templates for El Proxy retentions to Data Streams.

    Regarding the Elasticsearch index templates (and ILMs) that you created in the past for the custom retentions, please delete them after you finish the upgrade to NetEye 4.32. Ensure to only delete the manually created index templates and not the ones managed by NetEye (the index templates managed by NetEye are recognizable by looking at their metadata, where you will find "managed_by": "NetEye")

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

If you have the SIEM module installed and you verify El Proxy blockchains via the DPO machine, please also upgrade the DPO machine to ensure that El Proxy verifications will also take into account data stored on Elasticsearch data streams.