Skip to content

Wrong credentials with distributed multisite setup #41

Open
@ganto

Description

@ganto

Issue #32 added initial support for setting up multiple Check_MK monitoring sites in a distributed setup. It will create a dedicated 'sitesync' account for configuration synchronization. However, when running a playbook with a distributed setup, the following error is thrown:

TASK [debops-contrib.checkmk_server : Login on slave sites] ********************
...ignoring
failed: [cmk01] (item=mon02) => {"cache_control": "no-cache", "connection": "close", "content": "Authentication error: Invalid login credentials.\n", "content_length": "
49", "content_type": "text/html; charset=UTF-8", "date": "Thu, 26 Jan 2017 17:35:07 GMT", "failed": true, "item": "mon02", "msg": "Status code was not [302]: OK (49 byte
s)", "redirected": false, "server": "Apache/2.4.10 (Debian)", "status": 200, "url": "https://cmk02.example.com/mon02/check_mk//login.py"}

Reason: The default password configuration for the site login from the master site is defined in checkmk_server__distributed_sites_defaults which points to the own 'sitesync' account credential. However, when creating a slave site, a new set of default credentials will be generated as defined in checkmk_server__multisite_debops_users. These secret paths don't match.

Work-around: It is possible to set the checkmk_server__distributed_sites.<slave_site>.password definition to the secret path of the master server. But as the slave site (inventory configuration) doesn't know anything about the master, it has to be explicitly configured by the user which is cumbersome.

But attention: After the initial configuration sync to the slave site, the originally defined site accounts will be overwritten with the accounts of the master site (including passwords), which completely invalidates individual inventory secrets for the slave site used by Ansible.

A possible solution(?) would be to symlink the slave site secret directory to the master site. However this must be done properly to avoid the secret to be accessed before the symlink is generated...

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions