Enable the automatic agent deployment in upgrades

[BraulioV]

Hi team,

In this issue https://github.com/wazuh/wazuh-packages/issues/135 we added a feature to enable the registration and configuration of the Wazuh Agents while installing the package using shell variables.

This feature is only available in a fresh install scenario, which means that this feature is disabled in upgrades and reinstalls.

This issue aims to enable this feature in every scenario, where the user can register and configure the agents using the shell variables.

Regards.

[BraulioV]

Hi team,

I'm currently working on this branch 238-automatic-deployment-upgrades. Also in this branch wazuh/wazuh#238-wp-enable-auto-deploy-upgrades you can see the changes in the auto-deployment script.

The RPM packages are ready and now they can auto-deploy the agent while installing and upgrading the package. This was achieved by changing the temporary directory where this script was installed from packages_files to packages_files-%{version}-%{release}-tmp.

This allows the rpm package to unpack and execute this file when the package is been upgraded. But, there's a problem with the reinstall option. The files under this directory packages_files-%{version}-%{release}-tmp are marked as %ghost files because they are not used after installing the package and they shouldn't exist in the life cycle of the package. If we want to enable the auto-deploy while reinstalling the package, the script register_configure_agent.sh must be copied to bin directory.

For now, I'll keep working on .deb packages.

Regards.

[BraulioV]

Hi team,

The auto-deploy script in upgrades is already enabled in AIX's rpm packages, deb packages and macOS packages. In wazuh/wazuh there's already a PR opened with the changes to the auto deploy script.

Regards.

[BraulioV]

Hi team,

We recently had included the ability to auto-deploy the agents while reinstalling them. This change consists of changing the path where the register_configure_agent.sh script is installed to /var/ossec/bin and execute it always in the post-install.

For now, the auto-deploy script has been tested on:

• [x] Fresh install RPM.
• [x] Fresh install Deb.
• [x] Fresh install macOS.
• [x] Re-install RPM.
• [x] Re-install Deb.
• [x] Re-install macOS.
• [x] Upgrade RPM.
• [x] Upgrade Deb.
• [x] Upgrade macOS.
• [x] Package generation Solaris 11 and Solaris 10.

Finally, this change must be ported to the Windows installer, but here, the change is a bit more complex than the one made on UNIX installers. Here you can see a brief summary of the needed changes:

• Change all the CustomActions of the wxs file to enable being executed if the package is installed or not. Currently, the CustomActions are only executed if the package is not installed. https://github.com/wazuh/wazuh/blob/fc85ecdacd854601cd90d2e7a1a1af5d61d9eb9b/src/win32/wazuh-installer.wxs#L109-L159
• Refactor the post-install script (InstallerScript.vbs) and allow overwriting previous configuration if the package is already installed.

Finally, it would be interesting to merge this PR https://github.com/wazuh/wazuh/pull/3708 before starting to change the Windows installer in order to make easier the development.

[BraulioV]

Hi team,

I've been working on the Windows installer to allow the auto-deployment of the agent while reinstalling or upgrading. This feature was introduced with this commit: https://github.com/wazuh/wazuh/pull/3821/commits/72fd87ace96c23d07a130dd71046a0d88c55a4cd and consists of the following changes:

• wazuh-installer.wxs: by removing the check NOT Installed from every Custom Action, the installer will be able to run all the agent-auth actions and modify the ossec.conf file with the InstallerScript.vbs while installing, reinstalling, upgrading and even downgrading the package (if the lower version package supports this feature).
• InstallerScript.vbs: this script modifies the ossec.conf with the variables introduced while installing the package. To properly modify the configuration file while reinstalling or upgrading the package, it was necessary to create a new function to remove the client configuration and then re-add it again with the data stored in the WAZUH_MANAGER variable.

For now, I've tested in a Windows 10 Pro Edition the following cases:

• [x] Fresh install.
• [x] Re-install.
• [x] Re-install and change the value of the auto-deploy variables.
• [x] Upgrade.
• [x] Upgrade and change the value of the auto-deploy variables.
• [x] Downgrade.
• [x] Downgrade and change the value of the auto-deploy variables.

Regards.

[DFolchA]

Hello team,

I have tested the auto-deployment while upgrading in Linux systems.

I have run the following tests:

	Ubuntu 12 LTS	Ubuntu 16 LTS	Ubuntu 18 LTS	Centos 5	Centos 6	Centos 7
Clean installation	- [x]	- [x]	- [x]	- [x]	- [x]	- [x]
Upgrade from clean installation	- [x]	- [x]	- [x]	- [x]	- [x]	- [x]
Upgrade from configured agent changing variables	- [x]	- [x]	- [x]	- [x]	- [x]	- [x]

Regards, Daniel Folch

[rossengeorgiev]

Hi all, For Fedora/RHEL/CentOS, it is generally advised against starting services and having side effect like this automation during the install/upgrade/downgrade of RPMs.

I've outlined the issues in https://github.com/wazuh/wazuh-packages/issues/12

I just posted a comment in including helpful links: https://github.com/wazuh/wazuh-packages/issues/12#issuecomment-631435713

See https://docs.fedoraproject.org/en-US/packaging-guidelines/DefaultServices/#_enabling_services_by_default

Other packages, that have similar agent functionality, generally ship a tool used for configuring the agent. That tool is used post installation to say configure the software, such as enrolling to an external service. Once that is done, a sysadmin would manually enable and start the service.

I cannot stress enough, how important that is in an enterprise environment.