Update `upgrade_custom` API endpoint

[Selutario]

Description

Currently, the user can download WPK files in any folder. As long as it's downloaded inside /var/ossec, it can be used for the PUT /agents/upgrade_custom endpoint, specifying the full path in the file_path parameter.

To make it easier to understand (among other reasons), we want to change file_path to filename. The endpoint will search for the chosen file only within the /var/ossec/var/upgrade folder. This path has been selected for consistency, since this is where the WPKs are downloaded when a standard (not custom) upgrade is performed.

Documentation also needs to be updated since now users must create or download the WPK file in the folder mentioned above.

Checks

The following elements have been updated or reviewed (should also be checked if no modification is required):

• [ ] Tests (unit tests, API integration tests).
• [ ] Changelog.
• [ ] Documentation.
• [ ] Integration test mapping (using api/test/integration/mapping/_test_mapping.py).

[EduLeon12]

Issue Update

Parameter have been changed as seen on corresponding branch.

Next Steps:

• [x] Develop validator and exception raiser.
• [x] Test parameter change.
• [x] Test Filename is being properly taken.

[EduLeon12]

Issue Update

During the test of the parameter a type error was constantly raised because of a duplication error on the parameter, it has been renamed to wpk_filename and refactored where it was needed.

Also, a discussion with the core-team has been raised to check if the agent-upgrade daemon found in modulesd needs an update since the parameter has been changed, an issue opening has been proposed to address it confirmation pending

• [x] Test validator is working as expected.
• [ ] Rewrite UTs.

[EduLeon12]

Issue Update

Issue #17571 has been opened for the core team to change the parameter in the upgrade agent module daemon as well.

Test cases.

• Wrong wpk file in upgrade path:

request: {{baseUrl}}/agents/upgrade_custom?agents_list=001&wpk_filename=non_existant_file response:

{
    "title": "Bad Request",
    "detail": "File/directory does not exist or there is a problem with the permissions: File non_existant_file not found in /var/ossec/var/upgrade",
    "remediation": "Please, check if path to file/directory is correct and `wazuh` has the appropriate permissions",
    "dapi_errors": {
        "master-node": {
            "error": "File/directory does not exist or there is a problem with the permissions: File non_existant_file not found in /var/ossec/var/upgrade"
        }
    },
    "error": 1006
}

[EduLeon12]

Issue Update

Current validator is only validating that the file exist in the master not in the agent passed as parameter that is why the received response is the correct.

{
    "data": {
        "affected_items": [
            {
                "agent": "002",
                "task_id": 1
            }
        ],
        "total_affected_items": 1,
        "total_failed_items": 0,
        "failed_items": []
    },
    "message": "All upgrade tasks were created",
    "error": 0
}

I'll keep investigating how to address this issue

[EduLeon12]

I have raised a discussion to find the best way to handle this situation.

[EduLeon12]

Issue Update

Since there is no way to access directly to the content of the agent, the proper way to do it would be to create a petition to the socket and ask for the content of the upgrade folder. But since that would also required a development on the side of the core team to manage the socket petition the issue #17571 has been updated to ask the core team to validate the existence of the file prior to the execution of the module, and then update the endpoint, if needed, to properly handle the cases. Ex: bad request.

Issue will be blocked until the development (#17571 ) is completed.

[EduLeon12]

Issue Update

The parameter's name has been changed from filename to _wpkfilename since filename already exists for another parameter, causing a validation error but the name of the parameter expected to create the socket message is still filename,