[Check_mk (deutsch)] Distributed WATO beim Kunden-Satelliten

[Schulze Leon]

Guten Tag zusammen,

ich bin seit 3 Tagen nun mit check_mk beschäftigt und habe folgenden Hintergrund:

* Bisheriges Monitoring mit icinga2, icingaweb2 und icinga director -> Umstieg auf check_mk weil Icinga2 auch noch nach Monaten extrem zeitaufwändig ist
* Der check_mk Master steht bei uns in der DMZ
* 1 check_mk Slave steht nun im internen Servernetz meiner Firma für unsere internen Systeme
* 1 check_mk Slave steht beim Kunden im Netz

Die Konfiguration des internen Slave verlief über Distributed WATO einfach schnell und einfach ab.

Die Distributed WATO Konfiguration des Slave beim Kunden stellt sich als schwieriger heraus, ich habe diese nun erstmal lokal per VPN auf der Kundeninstanz selbst durchgeführt.
Die Anbindung an unseren Master hat funktioniert, hier reichte eine entsprechende Port-Forwarding Regel auf der Kunden-Firewall.
Das Distributed WATO ist aber immer noch nicht möglich, da check_mk ja die vollständige URL möchte, dies aber auf Grund der unterschiedlichen Netze keinen Sinn ergibt...

Wie geht man hier am besten vor?
Gibt es eine Alternative oder ein Walkaround?

Gruß
Leon

Diese Email wurde unter Verwendung einer Z1 SecureMail Gateway
Evaluations-Version verschickt. Mehr Infos unter http://www.zertificon.com

[Andreas Döhler]

Hallo Leon,

wieso ergibt URL keinen Sinn? Wie schaut die "URL" fÃŒr den Livestatus aus?
Im Endeffekt schaut die URL fÃŒr die normale Anbindung doch genau so aus nur
mit Port 443 halt fÃŒr HTTPS.
Und dann noch dem Angabe des Sitenamens.

Gruß
Andreas

Post by Schulze Leon
Guten Tag zusammen,
ich bin seit 3 Tagen nun mit check_mk beschÀftigt und habe folgenden
- Bisheriges Monitoring mit icinga2, icingaweb2 und icinga director ->
Umstieg auf check_mk weil Icinga2 auch noch nach Monaten extrem
zeitaufwÀndig ist
- Der check_mk Master steht bei uns in der DMZ
- 1 check_mk Slave steht nun im internen Servernetz meiner Firma fÃŒr
unsere internen Systeme
- 1 check_mk Slave steht beim Kunden im Netz
Die Konfiguration des internen Slave verlief ÃŒber Distributed WATO einfach
schnell und einfach ab.
Die Distributed WATO Konfiguration des Slave beim Kunden stellt sich als
schwieriger heraus, ich habe diese nun erstmal lokal per VPN auf der
Kundeninstanz selbst durchgefÃŒhrt.
Die Anbindung an unseren Master hat funktioniert, hier reichte eine
entsprechende Port-Forwarding Regel auf der Kunden-Firewall.
Das Distributed WATO ist aber immer noch nicht möglich, da check_mk ja die
vollstÀndige URL möchte, dies aber auf Grund der unterschiedlichen Netze
keinen Sinn ergibt

Wie geht man hier am besten vor?
Gibt es eine Alternative oder ein Walkaround?
Gruß
Leon
Diese Email wurde unter Verwendung einer Z1 SecureMail Gateway
Evaluations-Version verschickt. Mehr Infos unter http://www.zertificon.com
_______________________________________________
checkmk-de mailing list
Verwaltung & Abmeldung unter
http://lists.mathias-kettner.de/mailman/listinfo/checkmk-de

[MarcK]

Klingt doch eher nach einem DNS Problem…

Kannst Du den Servernamen des Slave nicht bei Dir mit im DNS eintragen?!



Grüße Marc



Von: checkmk-de <checkmk-de-***@lists.mathias-kettner.de> Im Auftrag von
Schulze Leon
Gesendet: Dienstag, 23. Oktober 2018 15:16
An: checkmk-***@lists.mathias-kettner.de
Betreff: [Check_mk (deutsch)] Distributed WATO beim Kunden-Satelliten



Guten Tag zusammen,



ich bin seit 3 Tagen nun mit check_mk beschäftigt und habe folgenden
Hintergrund:

* Bisheriges Monitoring mit icinga2, icingaweb2 und icinga director ->
Umstieg auf check_mk weil Icinga2 auch noch nach Monaten extrem
zeitaufwändig ist
* Der check_mk Master steht bei uns in der DMZ
* 1 check_mk Slave steht nun im internen Servernetz meiner Firma für
unsere internen Systeme
* 1 check_mk Slave steht beim Kunden im Netz



Die Konfiguration des internen Slave verlief über Distributed WATO einfach
schnell und einfach ab.



Die Distributed WATO Konfiguration des Slave beim Kunden stellt sich als
schwieriger heraus, ich habe diese nun erstmal lokal per VPN auf der
Kundeninstanz selbst durchgeführt.

Die Anbindung an unseren Master hat funktioniert, hier reichte eine
entsprechende Port-Forwarding Regel auf der Kunden-Firewall.

Das Distributed WATO ist aber immer noch nicht möglich, da check_mk ja die
vollständige URL möchte, dies aber auf Grund der unterschiedlichen Netze
keinen Sinn ergibt…



Wie geht man hier am besten vor?

Gibt es eine Alternative oder ein Walkaround?



Gruß

Leon



Diese Email wurde unter Verwendung einer Z1 SecureMail Gateway
Evaluations-Version verschickt. Mehr Infos unter http://www.zertificon.com

[Hauke Bruno Wollentin]

Da schliesse ich mich meinen Vorrednern an; wir verfahren mit 20+ Kunden
Slaves genauso.

Die Slave Site muss per L3/4 erreichbar sein, aber durch dein VPN ist sie dies
scheinbar ja, ansonsten gibts da keinen Unterschied zu Sites bzw. Slaves die
im selben Subnetz umherfliegen.

Gruss,
Hauke

Post by MarcK
Klingt doch eher nach einem DNS Problem…
Kannst Du den Servernamen des Slave nicht bei Dir mit im DNS eintragen?!
Grüße Marc
Schulze Leon
Gesendet: Dienstag, 23. Oktober 2018 15:16
Betreff: [Check_mk (deutsch)] Distributed WATO beim Kunden-Satelliten
Guten Tag zusammen,
* Bisheriges Monitoring mit icinga2, icingaweb2 und icinga director ->
Umstieg auf check_mk weil Icinga2 auch noch nach Monaten extrem
zeitaufwändig ist
* Der check_mk Master steht bei uns in der DMZ
* 1 check_mk Slave steht nun im internen Servernetz meiner Firma für
unsere internen Systeme
* 1 check_mk Slave steht beim Kunden im Netz
Die Konfiguration des internen Slave verlief über Distributed WATO einfach
schnell und einfach ab.
Die Distributed WATO Konfiguration des Slave beim Kunden stellt sich als
schwieriger heraus, ich habe diese nun erstmal lokal per VPN auf der
Kundeninstanz selbst durchgeführt.
Die Anbindung an unseren Master hat funktioniert, hier reichte eine
entsprechende Port-Forwarding Regel auf der Kunden-Firewall.
Das Distributed WATO ist aber immer noch nicht möglich, da check_mk ja die
vollständige URL möchte, dies aber auf Grund der unterschiedlichen Netze
keinen Sinn ergibt…
Wie geht man hier am besten vor?
Gibt es eine Alternative oder ein Walkaround?
Gruß
Leon
Diese Email wurde unter Verwendung einer Z1 SecureMail Gateway
Evaluations-Version verschickt. Mehr Infos unter http://www.zertificon.com