-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve WPKs #21152
Improve WPKs #21152
Comments
@TomasTurina the plan should be expanded to better accommodate a development process. |
@havidarou I've just updated it. Please let me know what you think. |
As reviewed with @havidarou, we approve the design but we shall divide the current testing proposal into a unit/smoke testing to be done by the WPK developers and deployability system tests to be performed by QA. |
UpdateThe current approach to remote upgrades involves installing Wazuh from sources, which overwrites an existing installation and leads to discrepancies if the original was installed using a package manager. To achieve this, the WPK features a script that backs up the current version before upgrading. This script also ensures that the new version connects to the Wazuh manager; if the upgrade fails, it reverts to the previous version by restoring the backup. The script, not utilizing package management, replicates certain package logic, particularly in creating or altering file ownership, reinstating the SELinux policy, and managing the agent service's stoppage and restart. Automatic rollbacksAlthough package systems such as RPM, DEB, and PKG allow for the inclusion of arbitrary shell scripts during the installation and uninstallation processes, adhering to standard package management practices and guidelines is strongly recommended. Consequently, it is advised not to attempt rolling back an installed or upgraded package to its previous version based solely on post-installation performance outcomes, such as the ability to connect to the Wazuh manager. Possible WPK improvementsRPM, DEBBy utilizing standard package management features, it's possible to simplify the WPK upgrade script significantly for RPM and DEB packages, retaining only the functionality to verify the agent's connection to the manager after an upgrade and the rollback in case of error. The streamlined process would involve:
Note: It is not possible to achieve this with PKG packages on OSX since they don't have run uninstall scripts when the package is being upgraded or downgraded. MSIOur MSI relies heavily on many
PKGAs there are no [pre|post][uninstall|upgrade] scripts in PKG packages, we cannot downgrade installations by means of a package install. Moreover, a recommended best practice is to include an uninstall script, which we currently do not provide. A necessary first step would be to provide such uninstall script, and let the WPK levarage it if necessary. |
UpdateFor this stage, we decided to do the following:
Second stage
Third stage:
|
Test: upgrade wazuh-agent using WPK on ubuntu 🟢Agent
os-release
Upgrade evidenceSteps
Syscollector colected dataBefore
After
Agent info from global.dbAfter
|
Test: upgrade wazuh-agent using WPK on Windows 11 🟢Agent
msinfo32
Upgrade evidenceSteps
Syscollector colected dataBefore
After
Agent info from global.dbAfter
|
Test: upgrade wazuh-agent using WPK on centos 🟢Agent
os-release
Upgrade evidenceSteps
Syscollector colected dataBefore
After
Agent info from global.dbBefore
After
|
Test: upgrade wazuh-agent using WPK on alpine timed out 🟢Agent
os-release
Upgrade evidenceSteps
Syscollector colected dataBefore
After
Agent info from global.dbBefore
After
NOTE: this scenario turns out as expected since the agent needs some libraries for rpm that are not present.
|
Test: upgrade wazuh-agent using WPK on MacOS 🟢Agent
system_profiler SPSoftwareDataType
Upgrade evidenceSteps
Agent info from global.dbBefore
After
|
Test: upgrade wazuh-agent using WPK on debian 🟢Agent
os-release
Upgrade evidenceSteps
Syscollector colected dataBefore
After
Agent info from global.dbBefore
After
|
Test: upgrade wazuh-agent using WPK on redhat 🟢Agent
os-release
Upgrade evidenceSyscollector colected dataAgent info from global.db |
Test: upgrade wazuh-agent using WPK on ubuntu 🟢Agent
os-release
Upgrade evidenceSyscollector colected dataAgent info from global.db |
Test: upgrade wazuh-agent using WPK on ubuntu fail due to wrong package_type 🟢Agent
os-release
Upgrade evidenceSyscollector colected dataAgent info from global.db |
Test: upgrade wazuh-agent using WPK on centos7 - ignoring package_type=deb 🟢Agent
os-release
Upgrade evidenceSyscollector colected dataAgent info from global.db |
Test: upgrade wazuh-agent using WPK on centos forcing packages_type=deb 🟢Agent
os-release
Upgrade evidenceNOTE: The upgrade fails because it does not have how to install a deb package, but downloads the correct package indicated by the request. |
Test: upgrade wazuh-agent using WPK on Centos5 unsupported platform 🟢Agent
os-release
Upgrade evidenceSyscollector colected dataAgent info from global.db |
Test: upgrade wazuh-agent using WPK on Linux fails with installation on non default path 🟢Custom upgrade task created
Task in progress
Task failed
Upgrade log from agent
Report from manager
|
Test: upgrade wazuh-agent fail (installed on another path) using WPK on ubuntu 🟢Agent
os-release
Agent info from global.dbAgent 012
Upgrade evidenceSteps
Upgrade log
|
Test: upgrade wazuh-agent using WPK on fedora with another upgrade already running 🟢Agent
os-release
Upgrade evidenceSteps
Syscollector colected dataBefore
After
Agent info from global.dbBefore
After
|
Test: upgrade wazuh-agent using WPK on Windows running 🟢Agent
os-info
Upgrade evidenceSteps
Syscollector colected dataBefore
After
Agent info from global.dbBefore
After
|
Description
As part of this epic, it is mandatory to reduce WPK packages' logic, especially the backup/rollback process (which will now rely on the package itself).
The resulting WPK package should only contain the package to be installed (to update the agent according to the OS and architecture) and an update script that will execute the package update. After the upgrade is completed the script should validate whether the process finished successfully or not and notify the agent.
Functional requirements
upgrade_result
file with0
or2
depending on the upgrade result.Non-functional requirements
Implementation restrictions
Plan
Plan for simplifying WPK upgrade process:
1. Analysis and planning:
2. Simplify package structure (dependency task):
3. Adapt existing upgrade script and agent integration:
4. Documentation update:
5. Testing:
Test scenarios should include:
Requirements traceability matrix (RTM)
Tasks
Approved by
The text was updated successfully, but these errors were encountered: