SPIKE - Installation assistant

[teddytpc1]

Objective
https://github.com/wazuh/internal-devel-requests/issues/1319

Description

As part of the DevOps overhaul objective, we need to research, analyze alternatives, and design how to implement the following changes:

1. Simplification:

   • The installation assistant must be streamlined.
   • Remove the offline installation option from the script.
   • Eliminate additional configuration options to reduce complexity.

2. Package Usage:

   • Transition to using Wazuh packages instead of package repositories.

3. Configuration Standardization:

   • Utilize out-of-the-box Wazuh configurations for installations.

4. Requirements Validation:

   • Add a validation step to ensure minimum requirements are met before proceeding with the installation.

5. Tool Optimization:

   • Leverage well-known tools to improve reliability and maintainability.
   • Avoid using additional dependencies to the ones required by Wazuh.

6. Testing Improvements:

   • Enhance the DevOps-owned testing for the installation assistant.
   • The GH Workflows must allow testing with Production, pre-release, and development packages.

Implementation restrictions

• Testing Environment:
  • Tests must be implemented using GitHub Actions (GHA).
• Compatibility:
  • Ensure compatibility with supported operating systems and environments.
• Minimal Maintenance:
  • Focus on reducing complexity and ensuring the script is easy to maintain.

Plan

1. Research & Analysis:

   • Review the current installation assistant to identify areas of complexity.
   • Analyze the impact of removing offline installation and additional configuration options.

2. Simplification:

   • Remove the offline installation option from the script.
   • Eliminate unnecessary configuration options to streamline the process.

3. Package & Configuration Updates:

   • Modify the script to use Wazuh packages instead of package repositories.
   • Ensure out-of-the-box configurations are implemented throughout the installation process.

4. Requirements Validation:

   • Add pre-installation checks to validate system requirements.
   • Notify users if minimum requirements are not met and provide guidance.

5. Tool Integration:

   • Replace custom implementations with well-known tools where applicable.
   • Document the reasons for tool selection and usage.

6. Testing Enhancements:

   • Create comprehensive GHA workflows to test the installation assistant.
   • Include tests for package installation, configuration application, and requirements validation.

7. Documentation Updates:

   • Update the installation assistant documentation to reflect the new process.
   • Simplify instructions and focus on the prerequisites for using the script.

8. Validation & Feedback:

   • Test the updated installation assistant across various environments.
   • Collect feedback from stakeholders and users to ensure alignment with expectations.

[Enaraque]

Update report

The different parts of the code have been reviewed to assess the feasibility of using Python as the programming language, particularly concerning the external dependencies it may require. This investigation is tentative for now, as the installation assistant for version 5.0.0 will differ significantly from what we currently know. Therefore, to conduct an investigation that allows us to determine if Python is the right language and whether implementation will not encounter too many external dependencies, it will be divided into three parts:

• Core Code: This is the most relevant part of the investigation. It represents the code that is most likely to remain in the implementation, in other words, the code that is most likely to be part of the new implementation in Python.
• Adaptable Code: This includes probable code to be implemented but might undergo changes in the Python implementation or due to future decisions.
• Deprecated Code: This consists of code likely to be removed from the installation assistant.

This division in the investigation reflects the priority of the different parts, with the Core Code being the most critical for decision-making and the Deprecated Code being the least significant.

[Enaraque]

Dependencies of the Installation Assistant

Types of Dependencies

The installation assistant has two types of dependencies:

1. Libraries required for the proper functioning of Wazuh: These libraries are not tied to the installation assistant's code but to Wazuh's main components, so they do not impact this investigation.

These libraries are:

Components	Libraries
Wazuh Indexer	- apt: debconf, adduser, procps - yum: coreutils
Wazuh Manager	- apt: gnupg, apt-transport-https
Wazuh Dashboard	- apt: debhelper, tar, curl, libcap2-bin, - yum: libcap

2. Libraries used by the code: These are libraries necessary for the execution of the installation assistant's code. They may or may not be required for Wazuh's proper functioning. These are the ones analyzed in this investigation.

Library	Description	Python Library	Native in Python	Minimum Python Version
grep	Text search utility	re	Yes 🟢	1.x
tar	Archive compression/decompression tool	tarfile	Yes 🟢	2.3
coreutils	Basic system utilities	os, pathlib	Yes 🟢	3.4 (pathlib)
procps-ng	Used to manage processes (e.g., kill)	os, signal	Yes 🟢	1.x
gawk	Text processing utility	re	Yes	1.x
curl	Data transfer utility	requests, urllib	Requests: No 🔴, urllib: Yes 🟢	3.0 (urllib)

Minimum Python version to use

Most of the libraries to be used have been part of Python for quite some time. However, the minimum version required, for now, would be 3.4, as pathlib is included starting from this version.

Important

It is also important to note that elements such as dataclasses (>=3.7), f-strings (>=3.6), or Enums (>=3.4) can be used in the code logic. Therefore, a definitive minimum Python version to use has not yet been established.

Conclusion

After completing the investigation, it can be concluded that all dependencies of the installation assistant are native to Python, so no additional dependencies need to be installed for its proper functioning.

Note

The most commonly used library for making HTTP requests in Python is requests. However, it is not necessary to install it because urllib is a native Python library and can be used for the same purpose. Still, if more complex HTTP requests are required in the future, the possibility of needing to install requests should not be ruled out.

Disclaimer

As shown, there are currently no external libraries required in the installation assistant's code. However, this does not mean that external libraries won't need to be added as the code evolves, such as the use of Pydantic, among others.

[Enaraque]

Update report

First, it is necessary to specify which options from the installation assistant will be kept and which will be deprecated.

For now, it is clear that both offline installation and the password-tool will be deprecated starting from version 5.0.0.
The cert-tool will remain for certificate generation.

Below is a list of all the options currently available in the installation assistant. Each option will have an associated color tag indicating whether it will be maintained or deprecated in version 5.0.

Options List

Legend:

🔴 Deprecated option
🟡 Option under review
🟢 Maintained option

Option	Description	Status
-a, --all-in-one	Install and configure Wazuh server, Wazuh indexer, Wazuh dashboard.	🟢
-c, --config-file <path-to-config-yml>	Path to the configuration file used to generate wazuh-install-files.tar file containing the files that will be needed for installation. By default, the Wazuh installation assistant will search for a file named config.yml in the same path as the script.	🟡
-d [pre-release|staging], --development	Use development repositories. By default it uses the pre-release package repository. If staging is specified, it will use that repository.	🟡
-dw, --download-wazuh <deb|rpm>	Download all the packages necessary for offline installation. Type of packages to download for offline installation (rpm, deb)	🔴
-fd, --force-install-dashboard	Force Wazuh dashboard installation to continue even when it is not capable of connecting to the Wazuh indexer.	🟡
-g, --generate-config-files	Generate wazuh-install-files.tar file containing the files that will be needed for installation from config.yml. In distributed deployments you will need to copy this file to all hosts.	🟢
-h, --help	Display this help and exit.	🟢
-i, --ignore-check	Ignore the check for minimum hardware requirements.	🟢
-id, --install-dependencies	Installs automatically the necessary dependencies for the installation.	🟡
-o, --overwrite	Overwrites previously installed components. This will erase all the existing configuration and data.	🟢
-of, --offline-installation	Perform an offline installation. This option must be used with -a, -ws, -s, -wi, or -wd.	🔴
-p, --port	Specifies the Wazuh web user interface port. By default is the 443 TCP port. Recommended ports are: 8443, 8444, 8080, 8888, 9000.	🟡
-s, --start-cluster	Initialize Wazuh indexer cluster security settings.	🟡
-t, --tar <path-to-certs-tar>	Path to tar file containing certificate files. By default, the Wazuh installation assistant will search for a file named wazuh-install-files.tar in the same path as the script.	🟡
-u, --uninstall	Uninstalls all Wazuh components. This will erase all the existing configuration and data.	🟢
-v, --verbose	Shows the complete installation output.	🟢
-V, --version	Shows the version of the script and Wazuh packages.	🟢
-wd, --wazuh-dashboard <dashboard-node-name>	Install and configure Wazuh dashboard, used for distributed deployments.	🟡
-wi, --wazuh-indexer <indexer-node-name>	Install and configure Wazuh indexer, used for distributed deployments.	🟡
-ws, --wazuh-server <server-node-name>	Install and configure Wazuh manager and Filebeat, used for distributed deployments.	🟡

Questions to Discuss

Based on this table, several questions arise for discussion with the team members:

• Will the password-tool be maintained?
• Will the cert-tool retain its current options, or will it be simplified?
• Will it be possible to use a custom directory for both config.yml and the tar with the certificates, rather than requiring them to be in the same path as the wazuh-install? (Regarding the -c and -t tags)
• Will the development mode installation still be used? (Tag -d)
• Will customizing the dashboard port still be supported? (Tag -p)
• Without using Filebeat for communication between the server and indexer, how will it be possible to verify that the communication between them is working correctly?
• Will still be possible to do the distributed installation or only the AIO?
• Will the start-cluster option still be available?

[c-bordon]

Options List

Legend:

🔴 Deprecated option
🟡 Option under review
🟢 Maintained option

Option	Description	Status
-a, --all-in-one	Install and configure Wazuh server, Wazuh indexer, Wazuh dashboard.	🟢
-c, --config-file <path-to-config-yml>	Path to the configuration file used to generate wazuh-install-files.tar file containing the files that will be needed for installation. By default, the Wazuh installation assistant will search for a file named config.yml in the same path as the script.	🟡
-d [pre-release|staging], --development	Use development repositories. By default it uses the pre-release package repository. If staging is specified, it will use that repository.	🔴
-dw, --download-wazuh <deb|rpm>	Download all the packages necessary for offline installation. Type of packages to download for offline installation (rpm, deb)	🔴
-fd, --force-install-dashboard	Force Wazuh dashboard installation to continue even when it is not capable of connecting to the Wazuh indexer.	🟡
-g, --generate-config-files	Generate wazuh-install-files.tar file containing the files that will be needed for installation from config.yml. In distributed deployments you will need to copy this file to all hosts.	🟢
-h, --help	Display this help and exit.	🟢
-i, --ignore-check	Ignore the check for minimum hardware requirements.	🟢
-id, --install-dependencies	Installs automatically the necessary dependencies for the installation.	🟡
-o, --overwrite	Overwrites previously installed components. This will erase all the existing configuration and data.	🟢
-of, --offline-installation	Perform an offline installation. This option must be used with -a, -ws, -s, -wi, or -wd.	🔴
-p, --port	Specifies the Wazuh web user interface port. By default is the 443 TCP port. Recommended ports are: 8443, 8444, 8080, 8888, 9000.	🔴
-s, --start-cluster	Initialize Wazuh indexer cluster security settings.	🟢
-t, --tar <path-to-certs-tar>	Path to tar file containing certificate files. By default, the Wazuh installation assistant will search for a file named wazuh-install-files.tar in the same path as the script.	🟡
-u, --uninstall	Uninstalls all Wazuh components. This will erase all the existing configuration and data.	🟢
-v, --verbose	Shows the complete installation output.	🟢
-V, --version	Shows the version of the script and Wazuh packages.	🟢
-wd, --wazuh-dashboard <dashboard-node-name>	Install and configure Wazuh dashboard, used for distributed deployments.	🟢
-wi, --wazuh-indexer <indexer-node-name>	Install and configure Wazuh indexer, used for distributed deployments.	🟢
-ws, --wazuh-server <server-node-name>	Install and configure Wazuh manager and Filebeat, used for distributed deployments.	🟢

Questions to Discuss

Will the password-tool be maintained?

The owners of each tool will maintain the password tool. (each tool will have their password tool)

Will the cert-tool retain its current options, or will it be simplified?

Some things need to be defined about the cert-tool, but in principle, it would keep the same functions and be published as it is currently. For the moment, it would be kept in bash, and ultimately, if the changes to the assistant are successful, it would be migrated to Python. This could lead to the assistant not having the cert-tool embedded as it is currently.

Will it be possible to use a custom directory for both config.yml and the tar with the certificates, rather than requiring them to be in the same path as the wazuh-install? (Regarding the -c and -t tags)

I understand that this is a decision that we must make. Currently, this option gives the user more flexibility in handling these files. In principle, we would keep them.

Will the development mode installation still be used? (Tag -d)

As planned, no, the installation assistant should have a file with the list of URLs of the packages to be installed. In the case of development, we should use that file and replace the URLs of the packages according to our needs.

Will customizing the dashboard port still be supported? (Tag -p)

No, the installation assistant will only install the products on the default ports, customization of this will not be allowed.

Without using Filebeat for communication between the server and indexer, how will it be possible to verify that the communication between them is working correctly?

This will probably be answered later in the product itself. Wazuh server probably has some functionality to validate connectivity against indexer. We will check.

Will still be possible to do the distributed installation or only the AIO?

Distributed installation will be possible, but only with the default options. That is, only the configuration will be modified to be able to be configured in a distributed way.

Will the start-cluster option still be available?

This will depend mainly on how the Wazuh indexer is developed by OpenSearch, as it has already been announced that the security admin will be deprecated and replaced by another service. We will have to validate with our team how this will be implemented.

The security admin script will be maintained so we will have to maintain a similar option to initialize the cluster

[Enaraque]

Function Filtering

Once the list of options for the Installation Assistant has been defined, it is necessary to analyze and categorize the existing functions. Some functions may no longer be needed or used.

Among these functions, we will need to distinguish between:

• Global functions (used by any Wazuh component)
• Component-specific functions

By creating this list, we will ensure a more efficient migration of the Installation Assistant to Python.

Function List

Functions list

Main directories

There are two directories dedicated to the functions of the installation assistant. These are:

• common_functions
• install_functions

Each function in every directory has been evaluated and categorized into three statuses:

• ✅ To be used: The function will remain and is necessary.
• ❌ Not to be used: The function will be discarded.
• ❓ Possible: The function may be needed, depending on further implementation details.

Common_functions

common_functions

In this directory, there are 2 files:

• common.sh: Contains global functions for cert-tool, password-tool, and wazuh-install.

  common.sh

  Function	Explanation	Status	Explanation of Status
  common_checkAptLock()	Checks if another process is using apt and waits for it to finish before using it.	✅
  common_logger()	Function used for logging.	❌	Python has its own logging functionality, which is preferable for consistency.
  common_checkRoot()	Checks if the installation assistant is being run with sudo and verifies if sudo is installed.	✅
  common_checkInstalled()	Checks if Wazuh components are installed and verifies the presence of related files.	✅
  common_checkSystem()	Checks the system being used (apt or yum).	✅
  common_checkWazuhConfigYaml()	Checks if config.yml is written correctly.	✅
  common_curl()	Curl function with custom options.	❓	May be needed depending on the Python implementation; this could be redundant if Python's requests or urllib is sufficient.
  common_remove_gpg_key()	Removes the GPG key.	❌	GPG key is used for Wazuh components installation via the repository; will be unnecessary now that packages will be used instead.
  common_checkYumLock()	Checks if another process is using yum and waits for it to finish before using it.	✅

  Summary:

  • Total of 9 functions in common.sh
  • Discarded functions: 2 ❌
  • Functions in doubt: 1 ❓
  • Functions that remain: 6 ✅

  ---

• commonVariables.sh: File with global variables.

Install_functions

install_functions

Main directory of the installation assistant. It contains all the functions related to each Wazuh component, checks, and global functions for each component.

This directory has 10 files. Two of them are related to offline installation and one to Filebeat. Therefore, 7 files remain to be reviewed.

• checks.sh: Functions intended to check different parts of the installation assistant.

  checks.sh

  Function	Explanation	Status	Explanation of Status
  checks_arch()	Checks the system architecture.	✅
  checks_arguments()	Checks the arguments passed to the installation assistant.	❓	May be used, but logic could be handled differently in Python.
  check_curlVersion()	Checks the curl version on the system.	❌	Python's curl will be used instead, making this function unnecessary.
  check_dist()	Checks the OS distribution.	❓	Could be refactored in Python to optimize the OS distribution check, possibly using a class.
  checks_health()	Checks the system's minimal requirements to run the installation assistant.	❓	Could be implemented more efficiently in Python.
  checks_names()	Checks that component names follow the correct structure.	✅
  checks_previousCertificate()	Verifies that the necessary certificates have been created before installation.	✅
  checks_specialDepsAL2023()	Adds specific dependencies for AL2023 OS.	✅	Needed for handling special dependencies in AL2023 OS.
  checks_specifications()	Verifies the system's specifications, such as cores and RAM.	✅
  checks_ports()	Verifies that the ports required by each component are available.	✅
  check_versions()	Checks if the first parameter's version is greater than or equal to the second parameter's version.	❌	This function is used only for curl, but since Python's curl will be used, this function is no longer needed.
  checks_available_port()	Verifies that the specified port is available.	❌	This function is specifically used for changing the dashboard port, but as the installation assistant will no longer support this feature, it will not be used.
  checks_filebeatURL()	Verifies if the Filebeat template URL is correct.	❌	Filebeat will not be used in version 5.0, so this function will not be necessary.
  checks_firewall()	Checks if the firewall is active on the system.	✅

  Summary:

  • Total of 14 functions in checks.sh
  • Discarded functions: 4 ❌
  • Functions in doubt: 3 ❓
  • Functions that remain: 7 ✅

  ---

• dashboard.sh: Functions intended to install and configure the Wazuh dashboard.

  dashboard.sh

  Function	Description	Status	Explanation
  dashboard_changePort()	Changes the dashboard port. Not needed in version 5.0.	❌	In version 5.0, customizing the dashboard port will not be possible, so this function will not be used.
  dashboard_configure()	Creates configuration files and sets them up with the correct parameters.	✅
  dashboard_copyCertificates()	Copies and configures dashboard certificates. A dedicated class for certificates may be better.	❓	Managing all certificate-related tasks might be better handled by a dedicated class that controls paths and configurations.
  dashboard_initialize()	Initializes the dashboard in a distributed environment and checks connectivity.	❓	This function is too extensive; it could be split into smaller functions for better readability and scalability.
  dashboard_initializeAIO()	Initializes the dashboard in an AIO environment. Could be merged with distributed initialization.	❓	It might be merged with the distributed dashboard initialization if a more scalable logic is implemented.
  dashboard_install()	Installs the dashboard service. Might change or be excluded in version 5.0.	❓	Components will be installed using packages, so this function may need adjustments or might not be included in version 5.0.

  Summary:

  • Total of 6 functions in dashboard.sh
  • Discarded functions: 1 ❌
  • Functions in doubt: 4 ❓
  • Functions that remain: 1 ✅

  ---

• indexer.sh: Functions intended to install and configure the Wazuh indexer.

  indexer.sh

  Function	Description	Status	Explanation
  indexer_configure()	Creates configuration files and sets parameters correctly.	✅
  indexer_copyCertificates()	Copies and configures the indexer certificates.	❓	Same reason as the dashboard: a centralized certificate management class might be preferable.
  indexer_initialize()	Initializes the indexer and checks cluster connectivity.	✅
  indexer_install()	Installs the indexer service.	❓	Components will be installed using packages, so this function may need adjustments or might not be included in version 5.0.
  indexer_startCluster()	Starts the indexer cluster in a distributed environment.	✅

  Summary:

  • Total of 5 functions in indexer.sh
  • Discarded functions: 0 ❌
  • Functions in doubt: 2 ❓
  • Functions that remain: 3 ✅

  ---

• manager.sh: Functions intended to install and configure the Wazuh manager.

  manager.sh

  Function	Description	Status	Explanation
  manager_startCluster()	Initializes the manager cluster.	❓	In version 5.0, there will be no Manager and Worker concepts, only Servers. This function might disappear or need adjustments.
  manager_configure()	Configures the connection with Filebeat and the Indexer.	❓	The connection setup might change since Filebeat will not exist in version 5.0.
  manager_install()	Installs the manager service.	❓	Components will be installed using packages, so this function may need adjustments or might not be included in version 5.0.

  Summary:

  • Total of 3 functions in manager.sh
  • Discarded functions: 0 ❌
  • Functions in doubt: 3 ❓
  • Functions that remain: 0 ✅

  ---

• installCommon.sh: Global functions for any Wazuh component.

  installCommon.sh

  Function	Description	Status	Explanation
  installCommon_addCentOSRepository()	Adds the CentOS repository.	❓	Needs evaluation: whether it's only for the Wazuh repo or also for dependencies.
  installCommon_cleanExit()	Handles interruption of installation and performs rollback if necessary.	✅
  installCommon_addWazuhRepo()	Adds the Wazuh repository for the corresponding OS.	❌	In 5.0, we will use packages instead of repositories.
  installCommon_aptInstall()	Installs packages using APT.	✅
  installCommon_aptInstallList()	Checks for missing dependencies and installs them using installCommon_aptInstall().	✅
  installCommon_changePasswordApi()	Changes API user passwords.	❓	The password-tool mechanism is changing, so this function might need modifications.
  installCommon_createCertificates()	Creates certificates for different components.	✅
  installCommon_createClusterKey()	Creates the manager cluster key.	❓	Since 5.0 uses Servers instead of Manager/Workers, this function might not be necessary.
  installCommon_createInstallFiles()	Creates wazuh-install-files.tar containing certificates, passwords, and config.yml.	❓	Could be split into multiple functions for better organization.
  installCommon_changePasswords()	Changes passwords for one or multiple components.	❓	The password-tool mechanism is changing, so this function might need modifications.
  installCommon_configureCentOSRepositories()	Adds multiple CentOS repositories.	❓	Needs evaluation: whether it's only for the Wazuh repo or also for dependencies.
  installCommon_extractConfig()	Extracts config.yml from the certificate tar.	✅
  installCommon_getConfig()	Retrieves and applies the configuration file for a Wazuh component.	✅
  installCommon_getPass()	Retrieves a user's password.	❓	The password-tool mechanism is changing, so this function might need modifications.
  installCommon_installCheckDependencies()	Installs dependencies for the installation assistant.	❌	Dependencies will be handled in a Python virtual environment instead.
  installCommon_installPrerequisites()	Installs prerequisites for Wazuh components.	✅
  installCommon_readPasswordFileUsers()	Reads the password file and initializes user/password variables.	❌	Password management will be handled by the corresponding teams, so we won't use the password-tool.
  installCommon_restoreWazuhrepo()	Restores the Wazuh repository in development mode by switching pre-release to production URLs.	❌	In 5.0, we will use packages instead of repositories.
  installCommon_removeCentOSrepositories()	Removes the Wazuh repository from CentOS.	❌	In 5.0, we will use packages instead of repositories.
  installCommon_rollBack()	Removes Wazuh components and associated files.	❓	Function is too large and could be split into smaller functions.
  installCommon_startService()	Starts a service passed as a parameter.	✅
  installCommon_yumInstallList()	Checks for missing dependencies and installs them using installCommon_yumInstall().	✅
  installCommon_removeWIADependencies()	Calls functions to remove installation assistant dependencies.	❌	Dependencies will be handled in a Python virtual environment instead.
  installCommon_yumRemoveWIADependencies()	Removes installation assistant dependencies installed via YUM.	❌	Dependencies will be handled in a Python virtual environment instead.
  installCommon_aptRemoveWIADependencies()	Removes installation assistant dependencies installed via APT.	❌	Dependencies will be handled in a Python virtual environment instead.
  installCommon_yumInstall()	Installs packages using YUM.	✅
  installCommon_checkAptLock()	Prevents issues with APT lock files.	❌	Function is duplicated in common.sh.

  Summary:

  • Total of 27 functions in installCommon.sh
  • Discarded functions: 8 ❌
  • Functions in doubt: 6 ❓
  • Functions that remain: 13 ✅

  ---

• installMain.sh: Functions intended to run the installation assistant and show help for the different options.

  installMain.sh

  Function	Description	Status	Explanation
  getHelp()	Displays help with all available options.	✅
  main()	Sets various variables based on passed options and checks everything necessary for installation.	✅

  Summary:

  • Total of 2 functions in main.sh
  • Discarded functions: 0 ❌
  • Functions in doubt: 0 ❓
  • Functions that remain: 2 ✅

  ---

• installVariables.sh: File with global variables for the installation.

Functions Summary

Summary

Category	Total Functions	To be used ✅	Possible ❓	Not to be used ❌
common_functions	9	6	1	2
install_functions	57	26	18	13
Total	66	32	19	15

[Enaraque]

Development Plan for the Installation Assistant Repository

This development plan divides the installation-assistant repository into two fundamental parts:

• cert-tool: Responsible for generating the certificates for Wazuh's main components based on a config.yml file.
• installation-assistant: Responsible for configuring the main components of Wazuh.

There will also be a module used by both parts, which will control and manage the configuration data of each component. This module will handle the data from config.yml.

Below, each part is described with the different modules that need to be considered during their creation.

Cert-tool

Certificate Management Module (cert-tool)

This module is responsible for managing certificates, including:

• Obtaining and managing cert-tool. For now, everything related to certificate generation will remain in Bash and will not be migrated to Python, though this will be considered in the future.
• Verifying the existence of certificates in the correct path. This part, which will be written in Python, ensures that the installation assistant correctly understands the context of the certificates.

The way to obtain information regarding each component for certificate creation will be through the module responsible for managing configuration data.

Installation-assistant

1. Package Download and Installation Module

This module is responsible for obtaining and installing the necessary packages. Its responsibilities include:

• Processing information from a file containing the component URLs.
• Storing the version to be installed.
• Checking component dependencies and installing them if they are missing.
• Verifying that the necessary component ports are open.

This module manages the prerequisites and the installation of packages, serving as a precursor to the configuration of each component.

2. Wazuh Global Configuration Module

This module handles the configuration and initialization of Wazuh's main components. It considers the following:

• Pre-reading the config.yml file (Component Data Configurer Module) to identify the component (distributed) or components (AIO) to install.
• Pre-reading the certificate package (Certificate Management Module) to determine the required certificate paths.
• Determining the component’s IP address, as well as the IPs of other components involved in communication (Component Data Configurer Module).
• Verifying the correct installation of components (Package Download and Installation Module).
• Checking for the necessary dependencies (Package Download and Installation Module).

Since this information is already retrieved beforehand, it does not need to be obtained again, and it will be passed as context to the components for configuration.

Main Submodules

• Server Configuration: Contains everything necessary for configuring and initializing the Wazuh server.
• Indexer Configuration: Contains everything necessary for configuring and initializing the Indexer.
• Dashboard Configuration: Contains everything necessary for configuring and initializing the Dashboard.

These submodules will exclusively contain files, classes, and functions dedicated to each specific component. They will be responsible for:

• Configuring the component: Retrieving the component's configuration files (e.g., opensearch.yml for the Indexer, opensearch_dashboards.yml for the Dashboard), modifying them according to the installation type (AIO or distributed), and copying their certificates.
  • To achieve this, there will be a config directory inside both the Indexer and Dashboard, which will store the templates for the mentioned configuration files, similar to how it currently exists in the installation assistant.
• Initializing the component: Once configured, the component will be initialized and its connection with other components will be checked (e.g., executing securityadmin in the Indexer or modifying wazuh.yml with the correct API IP for the Dashboard).
• Initializing the cluster if necessary.

Generic Module

In addition to the specific submodules, a generic module will include common functions for all components, such as:

• Checks
• InstallCommon

This module will not be created separately from the start but will be built progressively as the installation assistant evolves and the need for generic checks or functions arises.

3. Component Data Configurer Module

This module extracts relevant component information from a config.yml file. The data includes:

• IP address.
• Component name.
• Number of components.

Based on this configuration and data extraction:

• The cert-tool will obtain all necessary information for certificate generation.
• The installation-assistant will retrieve component IPs and names to facilitate easier configuration.

Since this module is not independent but serves as a complementary module for both the cert-tool and the installation-assistant, it will be housed inside the generic module.

[Enaraque]

How the Installation Assistant will be executed

The installation of the Installation Assistant components, being implemented in Python, will be managed within a virtual environment. This ensures that if any external Python dependencies are required, they will be installed inside this environment rather than alongside the user's system-wide Python packages. This approach keeps the installation isolated from the user's machine files and configurations.

Once the Installation Assistant finishes executing, it will automatically remove the virtual environment along with all installed Python dependencies, leaving the system clean of them.

Transparency for the User

To make the installation process as seamless as possible for the user, the following approach has been designed:

Currently, users execute the wazuh-install.sh script with various options as needed. To maintain this workflow, a Bash script (wazuh-install.sh) will be kept as the entry point, which will:

1. Check if Python, python-venv, and the required dependencies are installed on the system. If they are missing, an error will be displayed, and the installation will exit.
2. If Python, python-venv, and its dependencies are present, the entry point will call the main Python module, which will handle the rest of the process.

This approach ensures an initial dependency check to verify that all necessary components are available before starting the installation. Additionally, it maintains a seamless experience for users, who will not need to change how they execute the Installation Assistant compared to previous versions.

[Enaraque]

Development Tools

One of the main tools that will be necessary to keep the code clean is Ruff. This tool was implemented some time ago for use in the wazuh-automation repository, aiming to have better-written and cleaner code.

On the other hand, when developing and testing a new feature or simply running tests to ensure everything works correctly, I propose using Hatch and pyproject.toml.

Hatch is a tool for managing virtual environments, installing dependencies, and running tests. It allows for a centralized development environment to be defined within pyproject.toml, eliminating the need to manually manage a venv and making it easier to run tools like pytest and ruff.

In addition to managing environments and dependencies, Hatch has the option to run custom commands through scripts defined in the pyproject.toml. This feature allows you to automate repetitive tasks by executing predefined commands with the hatch run command, such as running tests, linting, or starting the development environment.

With pyproject.toml, we can specify the project's dependencies and necessary tools. This simplifies and standardizes the validation commands across all development environments.

In addition to defining dependencies, pyproject.toml also allows specifying configurations for tools like ruff, ensuring that all developers use the same parameters without needing to configure options manually for each run.

Thanks to this, we can have a centralized place for all configurations and execute different commands more easily and efficiently. It also helps in the creation of workflows, such as the one responsible for running the tests.