REST API Activate Pending Changes and redirect = true => HTTP Code 404

Hi all,

we have a problem in 2.0.0p26 with the REST API when we use the Activate Pending changes Endpoint with the parameter redirect to true.

curl -X 'POST' \
  'https://checkmk-dev.local/dev/check_mk/api/1.0/domain-types/activation_run/actions/activate-changes/invoke' \
  -H 'accept: application/json' \
  -H 'Content-Type: application/json' \
  -d '{
  "redirect": true,
  "sites": [],
  "force_foreign_changes": false
}'

The activation is done, but we got a HTTP 404 error and are not redirected:

{
  "title": "Not Found",
  "status": 404,
  "detail": "404 Not Found: The requested URL was not found on the server. If you entered the URL manually please check your spelling and try again."
}

This works fine in 2.1.0p4, and when we set the redirect to false it is also working - but there will be no check if the Activation was successful.
There are other API Endpoints available to check if the Activation was successful, but it would be nice when it will work only with one API Call.

I’ve also send a mail to the feedback address, since this might be a bug.

Has anyone the same issue or a solution for this?

CMK version: 2.0.0p26
OS version: RHEL 7.9

Best Regards
Thomas

Hi

I also encountered the same problem using the API via Pyton requests.

Running Checkmk Raw Edition 2.1.0p14 on Ubuntu 20.04.

When I try to activate the changes as described in the API docs I receive the 404 status code. The changes have successfully been activated though.

While debugging I found that the redirect links get repeated an concatenated to the end of the URL.

https://<host>/<site>/check_mk/api/1.0/objects/activation_run/1655ddb4-9917-4b01-b53c-d3cb5547cd1b/actions/wait-for-completion/invoke
https://<host>/<site>/check_mk/api/1.0/objects/activation_run/1655ddb4-9917-4b01-b53c-d3cb5547cd1b/actions/wait-for-completion/invoke/<site>/check_mk/api/1.0/objects/activation_run/1655ddb4-9917-4b01-b53c-d3cb5547cd1b/actions/wait-for-completion/invoke

and so on. It always appends the

<site>/check_mk/api/1.0/objects/activation_run/1655ddb4-9917-4b01-b53c-d3cb5547cd1b/actions/wait-for-completion/invoke

portion to the end of the redirect URL before after every redirect. After some number of redirects (I guess until the changes have been succesfully applied) I receive a 404 instead of a 204.

As a workaround I now emulate the expected behavior with a while loop and the URL I get back from the activate_changes POST request. With this workaround it works fine for me.

Is there any insight on this problem yet?

Cheers
Sebastian

Hi Sebastian,

I’ve written a mail to the feedback address in July but didn’t receive a response yet.

The issue still exists in 2.0.1p16.

It would be much easier when this would work instead creating a workaround with the loop…

Best Regards
Thomas

Yeah I fully agree, that the workaround is not optimal and I would rather use the built in function. I just posted it for the sake of completeness of my post.

Do you have the same behavior that the redirect URLs get concatenated while redirecting?

Cheers
Sebastian

hm, where do you see that the URLs get concatenated while redirecting?
In a logfile (web.log with Debug) or in the API Response?

I’ve done some tests today with 2.0.1p16 and the API Endpoint Activate Pending changes, and as soon as I use “redirect”: true I got the following error message:

{   "title": "Activation '36f048f4-d12b-4df3-ad05' not found.",   "status": 404 }

I’m not sure if they are using the wrong activation id or what is going wrong here. Seems that they have changed something between the patches…

Best Regards
Thomas

I printed the redirect URLs in the Response Object in Python, as I am using the API in a Python Script. There you can output the history of a response with all its redirect URLs.

I think the problem might be that during the redirects everything works fine and as expected, but as soon as the activation succeeds the ID disappears (as it is resolved) and cannot be found anymore hence the 404. Because in my case I receive a 404 but the activation succeeds anyway.