Closed fcaffieri closed 1 month ago
To correctly configure "the same" environment on each system it was decided to install python from source code, and then the python based dependencies (pip, venv, etc..) on top of that.
To do so, some other steps are required on the dependencies playbook:
yum groupinstall "Development Tools"
apt-get install build-essential
zypper install --type pattern devel_basis
apk add build-base
Restructured the playbooks renaming generic to package (as that's the provisioning method), this way we have a more accurate definition of the provisioning methods. The wazuh related playbooks will be kept under the wazuh/
subdirectory.
├── playbooks
│ ├── deps/
│ ├── package/
│ │ ├── install/
│ │ └── uninstall/
│ ├── sources/
│ │ └── install/
│ └── wazuh/
│ ├── aio/
│ └── package/
Replaced the ComponentType
based classes with a single ProvisionHandler
class that is responsible for the component privisioning method definition and validations.
class ProvisionHandler:
_base_templates_path = Path(__file__).parent / 'playbooks'
_actions = ['install', 'uninstall']
_methods = ['package', 'aio', 'dependencies', 'sources']
def __init__(self, component_info: ComponentInfo, action: str, method: str) -> None:
if not action in self._actions:
raise ValueError(f"Unsupported action: {action}")
if not method in self._methods:
raise ValueError(f"Unsupported method: {method}")
if not "wazuh" in component_info.component and method.lower() == 'aio':
raise ValueError(f"AIO actions is only supported for Wazuh components.")
# We cant uninstall from sources.
if action == "uninstall" and method.lower() == "sources":
logger.debug(f"Uninstall from sources not supported. Using package.")
method = "package"
self.action = action.lower()
self.method = method.lower()
self.component_info = component_info
self.templates_path = self._get_templates_path()
self.templates_order = self._get_templates_order()
self.variables_dict = self._generate_dict()
def _get_templates_path(self) -> str:
# If the component is wazuh, we need to change the templates path.
if "wazuh" in self.component_info.component:
self._base_templates_path = f'{self._base_templates_path}/wazuh'
return f"{self._base_templates_path}/{self.method}/{self.action}"
def _get_templates_order(self) -> list[str]:
"""
Get the order of the templates to be executed.
Returns:
list[str]: List of templates to be executed.
"""
if self.method == 'package' and self.action == "install":
return ["set_repo.j2", "install.j2", "register.j2", "service.j2"]
elif self.method == 'aio':
return ["download.j2", f"{self.action}.j2"]
return []
def _generate_dict(self) -> dict:
variables = {
'component': self.component_info.component,
'version': self.component_info.version,
'type': self.component_info.type,
'dependencies': self.component_info.dependencies or None,
'templates_path': self.templates_path,
'templates_order': self.templates_order or None
}
return variables
This issue will remain on hold until the release testing is finished
The new structure seems to work properly, now I´m facing an error at the python installation from sources, punctually at the "set default python version" step
TASK [Set default python to 3.10.0] ********************************************
fatal: [192.168.57.2]: FAILED! => changed=true
cmd: |-
update-alternatives --install /usr/local/bin/python3 python3 /usr/bin/python3.10.0 1
update-alternatives --install /usr/local/bin/pip3 pip3 /usr/bin/pip3.10.0 1
delta: '0:00:00.014980'
end: '2024-03-01 17:15:51.401133'
msg: non-zero return code
rc: 2
start: '2024-03-01 17:15:51.386153'
stderr: |-
update-alternatives: error: alternative path /usr/bin/python3.10.0 doesn't exist
update-alternatives: error: alternative path /usr/bin/pip3.10.0 doesn't exist
stderr_lines: <omitted>
stdout: ''
stdout_lines: <omitted>
Dynamic python version installation from sources is successful.
TASK [Set default python to 3.10.11] *******************************************
changed: [192.168.57.2] => changed=true
cmd: |-
sudo update-alternatives --install /usr/bin/python3 python3 /usr/bin/python3.10 1
delta: '0:00:00.011521'
end: '2024-03-04 12:54:24.605422'
msg: ''
rc: 0
start: '2024-03-04 12:54:24.593901'
stderr: ''
stderr_lines: <omitted>
stdout: 'update-alternatives: using /usr/bin/python3.10 to provide /usr/bin/python3 (python3) in auto mode'
stdout_lines: <omitted>
PLAY RECAP *********************************************************************
192.168.57.2 : ok=9 changed=8 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0
[2024-03-04 09:54:25] [INFO] [43479] [ThreadPoolExecutor-0_0] [workflow_engine]: [provision-install-linux-ubuntu-22.04-amd64] Finished task in 348.77 seconds.
The installation of the packages could be directly using the package name or with the requirements.txt A task that using the pip provision would look something like this
- task: "provision-install-{agent}" description: "Provision resources for the {agent} agent." do: this: process with: path: python3 args: - modules/provision/main.py - inventory: "{working-dir}/agent-{agent}/inventory.yaml" - dependencies: - agent: "{working-dir}/agent-{agent}/inventory.yaml" - install: - component: curl - component: python type: source version: "{python-version}" - component: virtualenv # Installation of one package. type: pip - component: deps/requirements.txt # Installation from requirements. type: pip - component: pyyaml # Installation of one package with version. type: pip version: 6.0.1 depends-on: - "allocate-{agent}" foreach: - variable: agents-os as: agent
The implementation of the sources installation method and the personalized python version brought some problems with several linux distros that uses an specific python version by default. It was discussed with @fcaffieri and @pro-akim who faced a similar issue, we decided to give up that installation method and only support (at least for this iteration) the installation by package manager for the non-wazuh packages.
Packages installation on supported OS status
OS | Result | Full log |
---|---|---|
Debian 10 | :green_circle: | output.log |
Debian 11 | :green_circle: | output.log |
Debian 12 | :green_circle: | output.log |
Ubuntu 18.04 | :green_circle: | output.log |
Ubuntu 20.04 | :green_circle: | output.log |
Ubuntu 22.04 | :green_circle: | output.log |
Centos 7 | :red_circle: | output.log |
Update the provision module to support all the required systems. Results of wazuh-manager and wazuh-agent installation on the different OS.
Amazon Linux was repeated on the list,.
OS | Result | Full log |
---|---|---|
AmazonLinux 2 | :green_circle: | output.log |
Centos 7 | :green_circle: | output.log |
Centos 8 | :green_circle: | output.log |
Debian 10 | :green_circle: | output.log |
Debian 11 | :green_circle: | output.log |
Debian 12 | :green_circle: | output.log |
OpenSuse 15 | :green_circle: | output.log |
OpenSuse Tumbleweed | :green_circle: | output.log |
Oracle 9 | :green_circle: | output.log |
Ubuntu 18.04 | :green_circle: | output.log |
Ubuntu 20.04 | :green_circle: | output.log |
Ubuntu 22.04 | :green_circle: | output.log |
RedHat 7 | :red_circle: | output.log |
RedHat 8 | :green_circle: | output.log |
RedHat 9 | :green_circle: | output.log |
Completed the executions of all the required OS, RedHat 7
raised several errors, some were fixed, but the execution is still with failures. It was discussed with @fcaffieri and we decided to generate an AMI of a fixed RedHat 7
in a future iteration, but for now, this OS will remain unsuported by the provision module.
The errors on RedHat 7 are related to the packages repository of the OS.
Rename AIO installation to Assistant for clarity.
This issue will remain in On Hold status until we discuss about changes on the allocator module that are now allowing us to initialize AWS machines without some labels.
Meet defined: Sync allocation module
- Wednesday, March 20⋅8:00 – 8:30pm
ESP
Changed status to Blocked for third-party
raise
instead of sys.exit
issue
parameter does not come in the call to the module, the instance_name
or some other parameter will be used to create the name of the key.Until the DevOps teams develops the final solution mentioned in the previous comment, we will work on this issue by using a workarround that let us use the allocation
module with some minor changes.
Some fixes were applied in order to ensure the correct functionality in AWS provided VMs
OS | Result |
---|---|
AmazonLinux 2 | :green_circle: |
Centos 7 | :green_circle: |
Centos 8 | :green_circle: |
Debian 10 | :green_circle: |
Debian 11 | :green_circle: |
Debian 12 | :green_circle: |
Suse 15 | :green_circle: |
Oracle 9 | :green_circle: |
Ubuntu 18.04 | :green_circle: |
Ubuntu 20.04 | :green_circle: |
Ubuntu 22.04 | :green_circle: |
RedHat 7 | :green_circle: |
RedHat 8 | :green_circle: |
RedHat 9 | :green_circle: |
LGTM
Description
The objective of this issue is to ensure the installation of dependencies on each system is correct and the version is the same across all the supported OS to execute the tests.
OS to validate:
Tasks