Open rauldpm opened 1 month ago
@rauldpm I've reproduced that in AlmaLinux 9:
<active-response>
<disabled>no</disabled>
<ca_store>etc/wpk_root.pem</ca_store>
<ca_verification>yes</ca_verification>
</active-response>
<active-response>
<disabled>no</disabled>
<ca_store>etc/wpk_root.pem</ca_store>
<ca_store>/path/to/my_cert.pem</ca_store>
<ca_verification>yes</ca_verification>
</active-response>
<active-response>
<disabled>no</disabled>
<ca_store>etc/wpk_root.pem</ca_store>
<ca_verification>yes</ca_verification>
</active-response>
<active-response>
<disabled>no</disabled>
<ca_store>etc/wpk_root.pem</ca_store>
<ca_verification>yes</ca_verification>
</active-response>
<active-response>
<disabled>no</disabled>
<ca_store>etc/wpk_root.pem</ca_store>
<ca_verification>yes</ca_verification>
</active-response>
<active-response>
<disabled>no</disabled>
<ca_store>etc/wpk_root.pem</ca_store>
<ca_verification>yes</ca_verification>
</active-response>
<!-- Active response -->
<active-response>
<disabled>no</disabled>
<ca_store>etc/wpk_root.pem</ca_store>
<ca_store>/path/to/my_cert.pem</ca_store>
<ca_verification>yes</ca_verification>
</active-response>
The behavior regarding the content of ossec.conf file is correct.
What we need to figure out is why the 4.9.0 package is leaving an "rpmsave" file on upgrade.
@vikman90 the .rpmnew file is a file generated by the package manager based on the changes in the system package DDBB when the original file has changed, so the new file does not overwrite it and data is lost, I think that the upgrade is not generating the correct configuration file when it not being overwritten (maybe sources?), I do not see that the SPEC file manages something about the ossec.conf generation
This behavior is also defined in the SPEC files, we have the second case here
https://kc.jetpatch.com/hc/en-us/articles/360043017992-rpmnew-and-rpmsave-handling
The v4.9.0-alpha3 SPEC file for the Wazuh agent has the following configuration
%attr(660, root, wazuh) %config(noreplace) %{_localstatedir}/etc/ossec.conf
Hello team, I have been researching and testing this behavior as much as possible.
The key is in the option already discussed by the SPECS by marking the ossec.conf file with (noreplace)
.
This setting indicates that if during an upgrade, the file metioned is different between versions (the default file of each version must be different), when upgrading the ossec.conf file will remain the same as the initial version, and the one corresponding to the new version will be renamed with the rpmnew.
This has been the case for older versions of Wazuh, as it has always been marked with the option (noreplace)
.
I have been testing doing an upgrade from version 4.4.0 to version 4.8.0 (to make sure that the default files are different), and indeed the ossec.conf.rpmnew file appears (with the same error of the duplicated ca_store tag).
So in conclusion this issue is not new in version 4.9.0.
Here is the verbose output of a 4.4.0->4.8.0 upgrade and the ossec.conf and ossec.conf.rpmnew files:
[root@centos9stream vagrant]# rpm -i wazuh-agent-4.4.0-1.x86_64.rpm
warning: wazuh-agent-4.4.0-1.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID 29111145: NOKEY
[root@centos9stream vagrant]# rpm -Uvvv wazuh-agent-4.8.0-1.x86_64.rpm
In this output, we can see the warning:
warning: /var/ossec/etc/ossec.conf created as /var/ossec/etc/ossec.conf.rpmnew
Now mentioning the problem of the double ca_store tag of the active-response block, I have not managed to find the exact reason. I have been investigating the gen_ossec.sh script, as SPECS have this line where the osseec.conf is created:
%{_localstatedir}/packages_files/agent_installation_scripts/gen_ossec.sh conf agent ${DIST_NAME} ${DIST_VER}.${DIST_SUBVER} %{_localstatedir} > %{_localstatedir}/etc/ossec.conf
I'm trying to see what interaction there is between this point and the rpmnew generation, which is where the erroneous double tag occurs.
Since the problem is not new from 4.9.0, we should rethink the priority and release at which this bug should be fixed.
Thanks, @jotacarma90.
Let's add this issue to the backlog
as a medium-impact bug, since it dates back to previous versions.
I began investigating this issue to gain a full understanding.
Description
Testing the 4.8.1 -> 4.9.0 AIX upgrade, I found a possible error in the ossec.conf file generated, as it is duplicating the
ca_store
tag of theactive_response
blockThe rpmnew file is the new package file saved as .rpmnew so the current ossec.conf is not overwritten if modified
How-To
This has been reproduced using an RPM Wazuh agent and the AIX package, the DEB packages should be checked too.
A fresh RPM 4.9.0 install has the following content
Related