[BUG] 401 unauthorized using ansible collection

[jgotteswinter]

Verify first that your issue is not already reported here. Where possible also test if the latest release and main branch are affected too. Complete all sections as described!

Describe the bug

When trying to use the MK Ansible collection i always end up in a 401 unauthorized. Calling the same url from my browser (using the automation secret) works fine, no auth issues. Using curl also works fine.

When using the Ansible collection it always ends up with a 401. This is a fresh installation i am currently working on.

The sites apache shows "AH01614: client used wrong authentication scheme:" when trying to do something with the ansible collection.

Component Name Component Name: activation

Ansible Version

ansible [core 2.17.2]
  config file = None
  configured module search path = ['/Users/jgotteswinter/.ansible/plugins/modules', '/opt/local/share/ansible/plugins/modules']
  ansible python module location = /opt/local/Library/Frameworks/Python.framework/Versions/3.12/lib/python3.12/site-packages/ansible
  ansible collection location = /Users/jgotteswinter/.ansible/collections:/opt/local/share/ansible/collections
  executable location = /opt/local/bin/ansible
  python version = 3.12.7 (main, Oct  5 2024, 01:39:55) [Clang 16.0.0 (clang-1600.0.26.3)] (/opt/local/Library/Frameworks/Python.framework/Versions/3.12/bin/python3.12)
  jinja version = 3.1.4
  libyaml = True

Checkmk Version and Edition

2.3.0p17 RAW

Collection Version

Collection                               Version
---------------------------------------- -------
ansible.posix                            1.5.4
ansible.utils                            4.1.0
checkmk.general                          5.3.0
community.general                        8.6.0

To Reproduce

Fresh installation on Ubuntu 24.04, get the automation user secret and try a random task with the ansible collection

[robin-checkmk]

Thanks for filing this issue @jgotteswinter! This feels like an issue with the system Apache on the server. Do you have any particular configuration there? A redirect or something else? Maybe the logs of said Apache contain a hint as well.

[jgotteswinter]

The error message is logged in /omd/sites/xxx/var/log/apache/error.log, the config is not modified at all. I am accessing OMD via http. Like mentioned, its a fresh install. The only thing which has been done before was omd create

[robin-checkmk]

I am referring to your system Apache. The one you see with systemctl status apache2 and whose logs are in /var/log/apache2/. :slightly_smiling_face:

[jgotteswinter]

no that one does not log any errors at all

i also tested with this script, which also works

#!/bin/bash

# NOTE: We recommend all shell users to use the "httpie" examples instead.
#       `curl` should not be used for writing large scripts.
#       This code is provided for debugging purposes only.

HOST_NAME=""
SITE_NAME="xxx"
PROTO="http" #[http|https]
API_URL="$PROTO://$HOST_NAME/$SITE_NAME/check_mk/api/1.0"

USERNAME="automation"
PASSWORD="xxx"

curl -6 \
  --request POST \
  --write-out "\nxxx-status_code=%{http_code}\n" \
  --header "Authorization: Bearer $USERNAME $PASSWORD" \
  --header "Accept: application/json" \
  --header "Content-Type: application/json" \
  --data '{
          "attributes": {
            "ipaddress": "192.168.0.123"
          },
          "folder": "/",
          "host_name": "example.com"
        }' \
  "$API_URL/domain-types/host_config/collections/all"

it might be worth mentioning that we are running a v6 only network

[robin-checkmk]

it might be worth mentioning that we are running a v6 only network

Huh. Well that is at least a peculiarity which might be relevant, but I am uncertain how exactly that would come to bear. Is there any way to test this in an IPv4 environment?

I know that we use Ansible libraries to make the HTTP calls, so I cannot see, that it really is a problem of this very collection, but rather one of Ansible and its libraries. I will need to do some research though.

P.S.: Any chance, this is relevant somehow? https://github.com/ansible/ansible/issues/74397

[jgotteswinter]

I successfully tested my Ansible against a v4 CheckMk (older Version). Apart from that, i will add a v4 address to the new installation for testing. Lets see what happens.

Thanks for the BR, i will take a look at this. Yes, there are many parties/moving parts involved. Using v6 is still full of surprises :)

[robin-checkmk]

Nice! Thanks for testing!

In all honesty: Even if we can pin it to IPv6, I am not sure how much or how quickly something can be done. Just to manage expectations. Maybe it is a trivial thing to fix, maybe it is awfully complex. We will do what we can here, but be prepared to accept the necessity for a workaround.

That being said, I am still hopeful, that we can understand and fix this! :muscle:

[HarisDotParis]

@jgotteswinter Could you please share your (anonymised) code using the Ansible collection? I have the sense that you encountered the same issue I did. The manual doesn't mention that the parameters server_url and site are thrown together with all API requests. If you look at the code inside api.py, then you'll see that server_url and site are concatenated.

Example:

- name: Example task
  checkmk.general.folder:
    server_url: "https://checkmk.example.com"
    site: "mainsite"
    automation_user: "my_fancy_user"
    automation_secret:" "m3_1ncr3dibl3_s3cr3t"
    ......

This would mean it would access the URL {{ server_url }}/{{ site }}/check_mk/api/1.0 i.e. https://checkmk.example.com/mainsite/check_mk/api/1.0. I kept trying entering https://checkmk.example.com/mainsite as server_url and only when me and a colleague of mine looked into the source code did we see that misunderstanding. I'll fix this in the manual, and I hope this may help you resolve this issue.

[robin-checkmk]

@HarisDotParis can you open a dedicated issue or PR for the perceived shortcomings of the documentation? I would very much like to understand, where we can be better in that regard, but I do not want to clutter this issue with it.

[github-actions[bot]]

This issue has been stale for 60 days. It will close in 7 days.