Nice job with the project, it seems promising. I may have missed this (reading the docs and the youtube videos/community calls) I did not notice when/where if you set the automation user password via this collection.
I did not think (until writing this) to try and set the automation secret using the user module, although a quick look would suggest it does not work, as it would set the automation users password, not automation_secret (unless Im not understanding things correctly).
and updated the config.yml checkmk_server_sites as follows:
checkmk_server_sites:
- name: "{{ site }}"
version: "{{ checkmk_server_version }}"
state: started
admin_pw: test
automation_user: automation
automation_secret: abracadraba
The other ideas are:
dont use the automaiton user as cmkadmin can do it all
wrap up an API call to set the automation secret via the rest-api
Both felt strange since 1. may break if this behaviour changes and 2. is strange because we’re already on the server, running omd create xxx, it feels like the right time and place to set the automation secret as well.
Thanks and if this is not the right place to post, my apologies in advance, Ill start a new topic.
Cheers,
Marius
Hi Marius, I moved your post to a dedicated thread, as it looks like there is something to discuss here.
Let me get back to you later with a little more elaborate answer.
The automation account’s password is the secret. It has to be stored encrypted in $OMD_ROOT/etc/htpasswd to work.
The file automation.secret in the account’s directory under $OMD_ROOT/var/check_mk/web is just the same in plaintext to be able to be consumed by scripts running as site user. You should not write into that file but use the user part of the API to change the secret / password.
I think Checkmk should allow either you to have the same secret for the “automation” user as cmkadmin (That you can specify when you create the site) or allow you to create an automation user yourselves (having built-in admin users with well defined usernames is a big NO-NO at my place)
The best way would be to allow cmkadmin to use the RestAPI initially and then rename that account, and create another one for API calls. Both allowing different passwords.
We run ansible to create sites, and configure them, so we just read the automation.secret (Why change the password, just stupid) - and we create a different API user and then just remove the automation one.
Thanks Robert, I did try to change the password via htpasswd first however it would not work. I looked at !etc/checkmk/multisite.d/wato/users.mk and noticed that the user automation had an automation_secret with an automatically generated UUID. I used that as the password for some curls tests and it worked, even though I had a different password configured via htpasswd.
In any case, I will set these via the rest-api also taking into consideration Anders’ note I think it also makes sens for us to change the default usernames as well.
one more addition from me: We are already working on a user module for user management, but you still need initial credentials. I think using the cmkadmin for that is sound, and you actually can use the server role to set an initial password for that user. Afterwards you can of course change that.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed. Contact an admin if you think this should be re-opened.