Advanced Topics

In this section, we will cover some advanced topics about the NetEye command.

neteye install

In a nutshell, the tasks carried out by the script are:

• To register the machine to RHEL 8

• To set up Red Hat Insights

• To reconfigure NetEye services and/or migrate configurations and databases after important changes

• To restart services that were stopped or modified

• To create certificates for secure communication

This command features a parallel execution of the configuration tasks, which is explored in detail in the Parallel execution of automated configuration with Ansible section.

neteye update

The neteye update command runs a number of tasks as listed below in order of execution.

Task	Order	Single Node	Cluster	Description
Health checks	#1	yes	yes	Carry out health checks to verify that NetEye installation is healthy and eligible for update
Parallel update configuration	#2	yes	yes	Execute the update for the supported services in parallel, you can find more information in the Parallel execution of automated configuration with Ansible section
Standby and fencing	#3	no	yes	puts all nodes in standby except the NetEye Active Node, and disables fencing, if enabled
Serial update configuration	#4	yes	yes	Execute the update for the remaining services in serial
.rpmsave and .rpmnew check	#5	yes	yes	Searches for any .rpmsave and .rpmnew files
Secure install	#6	yes	yes	Execute neteye_secure_install to complete update and initialise all NetEye modules

If any of these tasks is unsuccessful, a message will explain where the command failed, allowing you to manually fix the corresponding step, then launch again the neteye update command. Check also the Troubleshooting section for more information and directions about fixing the problems. To explore the parallel execution of the configuration tasks, please refer to the Parallel execution of automated configuration with Ansible.

neteye upgrade

Warning

The neteye upgrade command may take a long time before it completes successfully, so please do not interrupt it until it exits.

The tasks carried out by the neteye upgrade command are listed below in order of execution. It is also mentioned if they run on Clusters or Single Nodes.

Single Nodes and Cluster

Task	Order	Single Node	Cluster	Description
Health checks	#1	yes	yes	Carry out health checks to verify that NetEye installation is healthy and eligible for update
Check update status	#2	yes	yes	NetEye is fully updated and there are no minor (bugfix) updates to be installed. If there are, the upgrade process will be interrupted and the user will be asked to run the neteye update command first.
Upgrade eligibility	#3	yes	yes	Verify that NetEye is eligible for upgrade: it checks which is the installed version (e.g., 4.20) and that the last upgrade was finalized
Repo update	#4	yes	yes	Update all the NetEye repositories to the next version to which it is possible to upgrade (e.g., 4.21)
Packages check	#5	yes	yes	Check for new software packages in the repositories
Parallel upgrade configuration	#6	yes	yes	Execute the upgrade for the supported services in parallel, you can find more information in the Parallel execution of automated configuration with Ansible section
Standby and fencing	#7	no	yes	puts all nodes in standby except the Active Node, and disables fencing, if enabled
Active Node node check	#8	no	yes	Make sure the Active Node is active (i.e. non in standby mode, please refer to section The NetEye Active Node below to understand which node is considered as the Active Node.
Serial upgrade configuration	#19	yes	yes	Execute the upgrade for the remaining services in serial
.rpmsave and .rpmnew check	#10	yes	yes	Searches for any .rpmsave and .rpmnew files
Finalise installation	#11	yes	yes	The neteye_secure_install and neteye_finalize_installation scripts are executed

To explore the parallel execution of the configuration tasks, please refer to the Parallel execution of automated configuration with Ansible.

neteye update vs. neteye upgrade

The main difference between the two commands is that the neteye update installs all available packages in the current version of NetEye. On the other side, neteye upgrade installs all available packages in next version of NetEye.

For example, given a NetEye version 4.20, neteye update fully updates NetEye 4.20 with the latest packages in the 4.20 repository, while neteye upgrade installs and configures all new packages available in the 4.21 repository.

What neteye update and neteye upgrade do not do on Clusters

The following tasks are required to bring a cluster back to the correct operative status after an update or an upgrade and need to be carried out manually:

• Unstandby nodes

• Restore stonith on cluster

Additionally, the commands can not be launched on Elastic-only or a Voting-only nodes. Please note that, however, even if the two commands can be executed on operative nodes only, the update/upgrade procedure is performed also on Elastic-only and Voting-only nodes.

Moreover, the commands currently do not update/upgrade InfluxDB-only nodes. The maintenance of InfluxDB-only nodes should be performed on the user’s part.

Parallel execution of automated configuration with Ansible

To enhance speed and efficiency, the neteye install, neteye update, and neteye upgrade feature a parallel processing mechanism of Ansible playbooks. To mantain and manage the order of operations among services that require a specific order, this process relies on a dependency tree that is built based on the dependencies declared. The installation tree differs from the one used for the update and upgrade (which are the same). You may look at this dependencies graphs in the following images, for the install and update/upgrade respectively:

Fig. 18 A visual representation of the neteye install services dependency graph

Fig. 19 A visual representation of the neteye update and neteye upgrade dependency graph

Each box rappresents a NetEye service or component, and the arrows represent the dependencies between them. For example, if service A depends on service B (i.e. service B must have finished its configuration before service A can start) the arrow goes from B to A.

The procedure basically works as follows:

1. The dependency tree is built based on the dependencies declared in the services configuration files (/usr/share/neteye/install/ and /usr/share/neteye/update_upgrade/ for the appropriate commands). For each subdirectory, which represents a service, the dependencies are read from the dependencies.json file. If no dependencies are declared, the service is considered independent and is executed as soon as the procedure is started. Dependency names are the same as the service names (i.e. the directory names).

2. The tree is then traversed in a topological order. If all the dependencies of a service are met, the service is executed in parallel with the other services.

   1. The entrypoint for a service is the main.yml playbook found in its config directory.

   2. For each service, a dropin.d subdiectory may be specified. If present, every playbook found will be executed after the main.yml playbook in a unspecified order.

   3. If present, the post.yml playbook will be executed after all the other playbooks have finished.

   4. If any error occurs during the execution of a playbook, the procedure will let currently running playbooks finish, and then stop the execution of the remaining playbooks, even if they do not depend on the failed service.

   5. Logs for each service are stored in the /neteye/local/os/logs/neteye_command/[install,update,upgrade]/yyyyMMdd-hhmmss/ directory.