**CMK version:**2.4.0
**OS version:**container
**Error message:**none
Output of “cmk --debug -vvn hostname”: (If it is a problem with checks or plugins)
deploy the check_mk container from 2.4.0 on, there is no automation user anymore. which makes it difficult to automate it with eg: ansible.
2.3.0-latest still does have the automation user, and 2.4.0p1 does not.
So, how are we supposed to automate container setups then? Can we get the automation password in some other way? the option to store cleartext automation secrets would not be an option, since we dont have credentials to enable that after a container is deployed. it is mentioned the automation cleartext secret is no longer needed internally, so how should i automate container deployments?
also, how hard is it to add an Environment settings to enable this storing of cleartext of automation password in your dockers? i can’t imagine it’s too hard, if there is no other way…
You can configure that the automation password is stored in clear text as before.
After container creation use the default cmkadmin account to create an automation user with stored password and you can use this account as before.
At the moment it is a per user setting not a general/global option.
So the workflow now is to first omd create --admin-password XXX ... and then use the REST-API with cmkadmin/XXX to create an automation user and then switch to that automation user for subsequent REST calls? Sounds cumbersome.
And the question arises what the automation user is then good for if it is far easier to use the cmkadmin for the initial automation process in the first place.
The creation of an automation user with cleartext password in a file should definitely be an option to omd create.
The usage is different if I look at the complete admin account and some automation account with specific privileges. At the moment I don’t use a global admin automation user. Only with specific roles like the registration role and so on. Or a host creation automation user.
So, in a container context, it’s just easier to use the container environment (cleartext) to set the cmkadmin password and just keep using that in the api, instead of an automation user? If that is the workflow, i’m gonna do that; but i will have some questions.
I’m not against removing clear-text passwords, but there is no clear way to handle automation in containers. (no manual intervention)
I would not recommend this.
As i said use the cmkadmin user to setup an automation account after creating the container.
This can be scripted to setup the automation user.
Please just have this be the default in the container or at least provide an environment variable to do this automatically. From an automation perspective, this is a step backwards. in fact, there should be a better way than to store the automation password there specifically, in clear-text.
Hi Maarten,
If you would like to make a suggestion for the improvement of Checkmk, it might be a good idea to add it into the Ideas Portal. That way it will reach the product team and could also receive votes from the Community, showing interest.