Fix 'test_windows/test_cpe_indexing' tests in 4.2

[damarisg]

Issue information

Related issue
Closes #1531

When it comes to starting with the test fix, there is some information that can help you:

Module: Vulnerability Detector
Support Team:  "binary beasts"
Target: Manager   
OS: Linux

I add some information obtained while researched the logs that failed.

Case:

Type	Description
Test Path	test_windows/test_cpe_indexing
Consistent	no
Test Execution	2/3 executions failed
Cases Fails	3
Summary	On test_window_version_indexing when make_vuln_callback is called. it requires research to know if there is a problem with parser error or if we don't detect log.
Error message	"{mock_system['os_name']} was not indexed"

In order to finish this issue the following tasks should be fulfilled:

• Research of fails.
• Apply Fix
• Full Green/ Full Yellow in test_windows/test_cpe_indexing for 3 times.
• Documentation of any important change done for these tests or the used tools.

[mdengra]

2021-07-16

Test results with the modules sca, syscollector and rootcheck modules disabled in the ossec.conf:

Test Executions	Date	By	Status
test_cpe_indexing_local_dm_r1.log	2021-07-16	Miguel	🔴
test_cpe_indexing_local_dm_r2.log	2021-07-16	Miguel	🔴
test_cpe_indexing_local_dm_r3.log	2021-07-16	Miguel	🔴

The test still fails with the previously mentioned modules disabled, so in principle, we can discard that the failures are due to FileMonitor.

It is important to note that in each run, the use cases that fail are different. Thus it may be due to timeouts. I continue researching.

[mdengra]

The test keeps failing to increase the timeout from 50 seconds to 120 seconds. You can also confirm in the attached files that the required logs are not written:

Test result	log
test_cpe_indexing_local_dm_120s.log	logs_test_cpe_indexing_local_dm_120s.txt

[mdengra]

It seems that the origin of the failure is that the NVD_CVE table of the CVEs database is empty at the moment of the failure. This is because no vulnerability is explicitly inserted in this table, but rather Vulnerability Detector updates it with the local vulnerabilities when it scans the agent.

To generate the message required by the test, one of the requirements is that the table mentioned above contains data.

The solution is to insert a vulnerability at the beginning of each use case in the NVD_CVE table to avoid the waiting time caused by the scanning of the agent by Vulnerability Detector.

[damarisg]

Test Results:

Test Executions	Date	By	Status
YellowCPEIndexing.log	2021-07-29	Seyla	🟡
YellowCPEIndexing2.log	2021-07-29	Seyla	🟡
YellowCPEIndexing3.log	2021-07-29	Seyla	🟡

This issue is fixed and closed by #1656 but I reopen because I see than sometime fails by #1602

[mdengra]

2021-08-17

To attempt to reproduce the error that occurs rarely and randomly, tests have been performed with different states of the VM (clean and dirty environment) and also reducing the CPU usage limit to 10% to see if the reduction of resources affected the number of times that the error occurs:

Used Wazuh-QA branch: 1531-full-yellow-vuln-det
Test results with the default configuration modules in the ossec.conf:

Test Executions	Date	By	Status
test_cpe_indexing_local_r1.log	2021-08-17	Miguel	🟡
test_cpe_indexing_local_r2.log	2021-08-17	Miguel	🟡
test_cpe_indexing_local_r3.log	2021-08-17	Miguel	🟡
test_cpe_indexing_local_r4.log	2021-08-17	Miguel	🟡
test_cpe_indexing_local_cpu10_r1.log	2021-08-17	Miguel	🟡
test_cpe_indexing_local_cpu10_r2.log	2021-08-17	Miguel	🟡
test_cpe_indexing_local_cpu10_r3.log	2021-08-17	Miguel	🟡
test_cpe_indexing_local_cpu10_r4.log	2021-08-17	Miguel	🟡
test_cpe_indexing_local_cpu10_r5.log	2021-08-17	Miguel	🟡
test_cpe_indexing_local_cpu10_r6.log	2021-08-17	Miguel	🟡
test_cpe_indexing_local_cpu10_r7.log	2021-08-17	Miguel	🟡
test_cpe_indexing_local_cpu10_r8.log	2021-08-17	Miguel	🔴

As you can see, the last run has failed:

            with connect:
                for item in query_list:
>                   connect.execute(item)
E                   sqlite3.OperationalError: database is locked

This is probably due to the issue: wazuh/wazuh#9309, so this bug should be fixed by that issue.

[damarisg]

This issue is closed because the test was disabled by wazuh/wazuh#9309.