Slave Instanz einbinden funktioniert nicht

[markus.heinze]

Hallo,

kurz zur Konfig aktiv derzeit:

2xDebian 10.3 / aktuelles Patchlevel mit jeweils check_mk 1.6.0p10 Master/Slave

nun wollte ich eine 2te Slaveinstanz anbinden, also Debian 10.3 - patchen - check_mk drauf.
Site erstellt, Passwort angepasst, Distributed Monitoring -> Livestatus an, Port 6557 is ok, Site gestartet, alles wunderbar. Nun Auf dem Master neue Connection eingerichtet, alles gut wird gefunden, Login, alles wunderbar und grün.
Jetzt geh ich auf Activate Changes und dies kommt:

---

State: Failed. Started at: 15:40:22. Finished at: 15:40:23.
Failed: Got invalid data:

Internal automation error: Error running automation call restart (exit code 1), error:

not all arguments converted during string formatting

Traceback (most recent call last):
File “/omd/sites/slave2/lib/python/cmk/gui/wato/pages/automation.py”, line 186, in _execute_automation_command
html.write(repr(automation.execute(automation.get_request())))
File “/omd/sites/slave2/lib/python/cmk/gui/wato/pages/activate_changes.py”, line 519, in execute
return cmk.gui.watolib.activate_changes.execute_activate_changes(request.domains)
File “/omd/sites/slave2/lib/python/cmk/gui/watolib/activate_changes.py”, line 1172, in execute_activate_changes
warnings = domain_class().activate()
File “/omd/sites/slave2/lib/python/cmk/gui/watolib/config_domains.py”, line 69, in activate
return check_mk_local_automation(config.wato_activation_method)
File “/omd/sites/slave2/lib/python/cmk/gui/watolib/automations.py”, line 126, in check_mk_local_automation
err=errdata)
MKGeneralException: Error running automation call restart (exit code 1), error:

not all arguments converted during string formatting

---

und die Konfig ist hinüber.

Kennt jemand dieses Problem? Als ich den ersten Slave eingerichtet hatte ging alles problemlos, allerings war dies noch die 1.6.0p2

Ich kann es mir nicht erklären. Vielleicht weiss jemand Rat?

mfg
M.Heinze

[markus.heinze]

p.s. es ist die CRE und ich habe auch schon eine komplette Neuinstallation durchgeführt, da ich dachte im Vorfeld etwas flasch gemacht zu haben, leider ohne Erfolg

[simon-mueller]

Was hast du denn bei URL of remote site eingetragen? Den Fehler bekommt man normalerweise wenn der Pfad zu der Remotesite nicht passt.

Der Hilfetext dazu ist folgender:

URL of the remote Check_MK including /check_mk/. This URL is in many cases the same as the URL-Prefix but with check_mk/ appended, but it must always be an absolute URL. Please note, that that URL will be fetched by the Apache server of the local site itself, whilst the URL-Prefix is used by your local Browser.

[markus.heinze]

Das hab ich auch schon mehrfach geprüft,

da ist ein http://<ip>/slave2/check_mk/

ist auch erreichbar.

[tosch (Tobias Schönau)]

Hallo,

die URL of remote site darf nicht als URI angegeben werden, also es ist nur der Teil /<site>/ ohne Servernamen.
Kannst du bitte einmal deine Konfiguration der remote Site zeigen und die sensiblen Daten maskieren?

[tosch (Tobias Schönau)]

Hallo,

kannst du bitte einmal deine Konfiguration der remote Site zeigen und die sensiblen Daten maskieren?

[markus.heinze]

‘slave2’: {‘url_prefix’: ‘/slave2/’, ‘status_host’: None, ‘user_sync’: None, ‘socket’: (‘tcp’, {‘tls’: (‘plain_text’, {}), ‘address’: (‘x.x.x.x’, 6557)}), ‘replication’: ‘slave’, ‘user_login’: True, ‘insecure’: False, ‘disable_wato’: False, ‘disabled’: False, ‘alias’: u’MON_SLAVE2’, ‘secret’: ‘S8:--------:J’, ‘globals’: {‘site_livestatus_tcp’: {‘port’: 6557}}, ‘replicate_mkps’: True, ‘proxy’: None, ‘timeout’: 5, ‘persist’: True, ‘replicate_ec’: False, ‘multisiteurl’: ‘http://x.x.x.x/slave2/check_mk/’},

[tosch (Tobias Schönau)]

So wie ich es sehe, hast du keinen Status-Host gesetzt. Ich kann jetzt aus der Kalten nicht sagen, ob das ein Problem verursachen kann, ich habe noch nie eine Connection ohne verwendet.

Ansonsten sehen die Werte in meinen augen gut aus. Ich schaue gleich mal in den Quelltext, an welchen Stellen er sich stört.

[markus.heinze]

Ok, Danke!

Ich habe den slave1 auch so aufgesetzt welcher ohne murren funktioniert.

Er fängt ja auch an die Config zu pushen nur kommt die offensichtlich nicht vollständig an. Gibt es ein Log für die Replikation?

mfg
M.Heinze

[tosch (Tobias Schönau)]

Also, es sieht danach aus, dass er beim Pushen der Konfiguration einen Fehler bekommt und der Stacktrace deswegen geschrieben wird, weil er für das Erstellen der Fehlermeldung nicht alle Variablen bekommt.

Dein Master und Slave haben die gleich Version?

Der Fehler dritt auch auf der Slave-Site auf, wird aber im Master angezeigt.

[markus.heinze]

Ja die Version ist die 1.6.0p10 auf allen.

Ich habe jetzt mal im gleichen Subnetz eine neue Instanz aufgesetzt umd Netzprobleme auszuschliessen, selbes Bild.
Alle Nutzen Debian 10.3 mit letztem Patchstand und 1.6.0p10 CRE

Offensichtlich ist beim Pushen der Konfiguration das Problem.

[markus.heinze]

Hallo,

das Problem scheint gelöst.

der cmkadmin war auf der Master Instanz nicht Mitglied der Cotactgroup Everything/all. Nachdem dieser wieder dort hinzugefügt wurde konnte der Slave korrekt verbunden werden.
Ich weiss nicht warum dies Verhalten so ist. Vllt. könnten man dies prüfen und eine entsprechende Fehlermeldung ausgeben. Scheinbar ist dies nur der Fall wenn eine neue Site ohne jegliche andere Konfig hinzugefügt wird.
Auf jeden Fall bin ich froh das dies gelöst ist und vllt. hilft es ja dem ein oder anderen.

Vielen Dank tosch für die Unterstützung und vllt. hast Du ja noch etwas Hintergrundwissen warum dies Verhalten so ist oder ggf. ein anderer Mitleser

mfg
M.Heinze