QA Testing - Release 4.3.7-RC2 - Behavior of cluster restart procedure in the UI

[Deblintrake09]

Target version	Related issue	Related PR
4.3.7-rc2	wazuh/wazuh-dashboard-plugins#4277	wazuh/wazuh-dashboard-plugins#4405

Description

Whe need to ensure the correct behavior of the Cluster during restarts generated from the Wazuh Dashboard.

Proposed checks

• Restart cluster successfully
• Modify a rules/decoders/list file and restart cluster successfully
• Restart cluster - changing page during restart causes crash and goes to healthcheck
• Restart cluster during big files synchronization - No overwrite tag
• Restart cluster during big files synchronization - Use Overwrite tag

Configuration and considerations

Setup cluster with default configuration.

[Deblintrake09]

Review data

Tester	PR commit
@Deblintrake09	Tag v4.3.7-1

Testing environment

OS	OS version	Deployment	Image/AMI	Notes
Centos	8	<REMOTE | Deployer - EC2	ami-0e65b7ce2dab78ec9	Box Size c5.xlarge

Tested packages

• Installed Indexer, Manager and Dashboard using the wazuh-install.sh script

Status

• In progress
• Pending Review
• Team leader approved
• Manager approved

Conclusion 🟡

It was found that after the rollback done on the changes, the Wazuh UI App works correctly and restarts the cluster as expected.
During the testing Two un-related issues were found on the app.

Found Errors descriptions

• When one or more files with duplicated rules that are not being overwritten with the <overwrite>yes</overwrite> tag are found, it cannot properly read the rules, crashing the application. - Reported in App crashes with large rules files wazuh-dashboard-plugins#4410

• When trying to upload a file upload file button in the UI, if the file is too big, the error message does not specify if it has too many characters or lines or bytes. This should be improved upon, with a correct message - Reported in Improve warning message when exceeding file upload limits wazuh-dashboard-plugins#4411

[Deblintrake09]

Task Results

Restart cluster successfully 🟢

• Check cluster is synchronized

# curl -k -X GET "https://localhost:55000/cluster/ruleset/synchronization?pretty=true" -H "Authorization: Bearer $TOKEN"
{
   "data": {
      "affected_items": [
         {
            "name": "master",
            "synced": true
         },
         {
            "name": "worker1",
            "synced": true
         },
         {
            "name": "worker2",
            "synced": true
         }
      ],
      "total_affected_items": 3,
      "total_failed_items": 0,
      "failed_items": []
   },
   "message": "Nodes ruleset synchronization status was successfully read",
   "error": 0
}

• Restart the cluster from the /management/status page
• Change to other page during restart
• Check UI does not crash 🟢

VIDEO EVIDENCE

Restart-cluster.mp4

Modify a rules/decoders/list file and restart cluster successfully 🟢

• Check cluster is synchronized

# curl -k -X GET "https://localhost:55000/cluster/ruleset/synchronization?pretty=true" -H "Authorization: Bearer $TOKEN"
{
   "data": {
      "affected_items": [
         {
            "name": "master",
            "synced": true
         },
         {
            "name": "worker1",
            "synced": true
         },
         {
            "name": "worker2",
            "synced": true
         }
      ],
      "total_affected_items": 3,
      "total_failed_items": 0,
      "failed_items": []
   },
   "message": "Nodes ruleset synchronization status was successfully read",
   "error": 0
}

• Modify local_rules.xml file and save changes.
• Restart the cluster
• Check UI does not crash 🟢

VIDEO EVIDENCE

Modify-rules-restart.mp4

• Check cluster is synchronized

# curl -k -X GET "https://localhost:55000/cluster/ruleset/synchronization?pretty=true" -H "Authorization: Bearer $TOKEN"
{
   "data": {
      "affected_items": [
         {
            "name": "master",
            "synced": true
         },
         {
            "name": "worker1",
            "synced": true
         },
         {
            "name": "worker2",
            "synced": true
         }
      ],
      "total_affected_items": 3,
      "total_failed_items": 0,
      "failed_items": []
   },
   "message": "Nodes ruleset synchronization status was successfully read",
   "error": 0
}

Restart cluster - changing page during restart causes crash and goes to healthcheck 🟢

• Check cluster is synchronized

# curl -k -X GET "https://localhost:55000/cluster/ruleset/synchronization?pretty=true" -H "Authorization: Bearer $TOKEN"
{
   "data": {
      "affected_items": [
         {
            "name": "master",
            "synced": true
         },
         {
            "name": "worker1",
            "synced": true
         },
         {
            "name": "worker2",
            "synced": true
         }
      ],
      "total_affected_items": 3,
      "total_failed_items": 0,
      "failed_items": []
   },
   "message": "Nodes ruleset synchronization status was successfully read",
   "error": 0
}

• Restart the cluster from the /management/status page
• Change to other page during restart
• Check UI does crashes and goes to healthcheck automatticaly 🟢

VIDEO EVIDENCE

restart-cluster-failed.mp4

Restart cluster during big synchronization - No overwrite tag 🔴

• Check cluster is synchronized
• Copy test_rules_file.xml 5 times inside etc/rules/ via console script (No overwrite tag).
• Modify local_rules.xml file and save changes.
• Restart the cluster
• Check UI does not crash 🔴

VIDEO EVIDENCE

copy_multiple_rules_files_no_overwrite.mp4

• Remove the copied rules and refresh to check status

remove_rules_restart.mp4

Restart cluster during big synchronization - Using overwrite tag 🟢

• Check cluster is synchronized
• Copy test_rules_file.xml 5 times inside etc/rules/ via console script (using overwrite tag).
• Modify local_rules.xml file and save changes.
• Restart the cluster
• Check UI does not crash 🟢

VIDEO EVIDENCE

copy_multiple_rules_files_with_overwrite.mp4

[Deblintrake09]

Error testing results

The errors found were tested and replicated in 4.3.6, so they are not introduced in this version. It seems that the timeout is generated when big rule files are added to the rules directory. It was tested with 10Mb and 100Kb files. The error was found when the file was large.

Video Evidence

10 Megabytes file with no overwrite in 4.3.6 - 3 copies 🔴

Timeout.436.big.file.mp4

---

10 Megabytes file with no overwrite in 4.3.7 - 3 copies 🔴

Timeout.437.big.file.-.no.overwrite.mp4

100 Kilobytes file with no overwrite in 4.3.7 - 100 copies 🟢

Timeout.437.small.file.-.no.overwrite.mp4

Auxiliary files

In the linked zip file, you will find:

• copy.sh - bash script used to create copies of the rules file.
• test_rules_file.xml - 10Mb file with no overwrite tag
• test_rules_file_100k.xml - 100Kb file with no overwrite tag
• test_rules_file_100k_overwrite.xml - 100Kb file with overwrite tag

The copy.sh file can be modified to select the rules file source as well as the amount of copies to generate.

[jmv74211]

The following issues have been opened to report the problems detected in this testing issue:

• App crashes with large rules files
• Improve warning message when exceeding file upload limits