Posts by 00stormy00

This forum was archived to /woltlab and is now in read-only mode.

    Hy Michi


    Ich habe diesbez noch kein Ticket eröffnet, da ich noch am recherchieren bin.

    Bis jetzt sind einige Tickets im Umlauf aber leider noch keine 100%ige Lösung. :-(


    Es schaut so aus als wenn zwischen dem Reload etwas länger gewartet werden müsste damit der Port wieder freigegeben wird. Die neue Instanz gestartet werden kann. Vermutlich ist dir das besser bekannt als mir.
    Hoffe mal auf eine baldige Lösung, da ich doch viele Unknown State dadurch erhalte


    sg

    Hallo Michi

    Genau um diese Dependencies zu umgehen und den Host auch via ping zu überwachen, hab ich mich für die Clusterzone entschieden.

    Ich muss mir hierzu nochmals genau die Dependencies ansehen. (Derzeit verwende ich nur die Standardsettings laut Doku)

    Vielen Dank erst mal, leider muss ich mir bevor ich dann dieses Thema angehen noch schnell ansehen warum nach einem Reload manche Agents nicht mehr hoch kommen. Hier habe ich bei 2 Clients (mit aktuellsten Agent 2.6.3.2) noch das Socket Problem:


    Wird auch hier behandelt:

    https://github.com/Icinga/icinga2/issues/4867#note-19



    sg

    Roland

    Hy


    Der Aufbau sollte natürlich flexibel sein, kommt ein Host hinzu soll dieser auch mit überwacht werden.
    Die Überwachung mit snmp kommt neu hinzu darum auch der Linux Server. Bis jetzt kam ich mit den Windowshosts immer gut aus.

    Wie angesprochen habe ich 2 Satelliten Server in eine Zone gesteckt um vom Master zu erkennen ob der Service icinga2 gestoppt ist oder der Server down ist. (Leider habe ich noch das Problem, dass manche Services nach einem reload nicht mehr hoch kommen, muss noch checken warum)

    Meine letzte Frage:

    Wie kann ich bei einem "Satelliten in der Mitte" diesen überwachen? Wenn der Service icinga2 down ist, gehen alle weiteren Hosts/Services auf unknown.

    Hast du hierzu noch ein Tipp?


    Danke

    Hy Michi


    Ich habe die beiden Satelliten in die gleiche Zone gesteckt, damit sich diese gegenseitig via ping überwachen.

    Ohne icmp (ping) vom Master zu den Satelliten kann ich ansonsten nicht erkennen ob der Host oder nur der icinga2-Service down ist


    Ist es möglich, dass sich 2 getrennte Satelliten-Zonen gegenseitig via ping überwachen.
    In meinem Fall slmonp01.spr.loca und swadsp01.spr.local?



    Danke für deine Hilfe!

    Roland

    Hy Michi!


    Unten findest du ein Bild wie die Hosts miteinander verbunden sind.

    Beim Server slmonp01.spr.local handelt es es sich um ein Testserver für snmp.
    (Vorher war nur der Server swadsp01.spr.local im Netzwerk vorhanden. Da auf einem WindowsAgent keine snmp checks funktionieren, kam slmonp01.spr.local dazu)

    + Grund warum slmonp01.spr.local und swadsp01.spr.local in der gleichen Zone sind:
    Zwischen dem Master und der Kunden "SPR" besteht kein VPN. Die Agents *spr.local verbinden sich zum Master.
    Die Hosts slmonp01.spr.local und swadsp01.spr.local sind in der gleichen Zone, sodass diese sich gegenseitig via Ping überwachen können.


    + SNMP Service
    Der Service snmp-uptime ist ein erster Test, darum hab ich diesen (quick&dirty) beim Kunden (spr) erstellt.
    Der Check snmp-uptime soll für den Host sw01.spr.local am Host slmonp01.spr.local abgefeuert werden

    Frage: Kann die doppelten Definition der Grund sein warum "command_endpoint = "slmonp01.spr.local" nicht gezogen hat?








    Sorry für die Namensgleichheit des Masters u Linux Agents, der Kollege hat hier schnell einen Standardserver erstellt und dieser heisst eben so

    Hy Michi!


    Erst mal danke für deine Hilfe, anbei die Konfig:

    Interessanterweise steht beim LinuxServer (slmonp01.spr.local) immer "is reachable" aber auch "Check result is late"

    Anmerken möchte ich, dass der Master kein direkten Zugang zu den Endpoints hat, der Aufbau findet nur vom Agent zum Master statt

    Anbei die Konfig:



    /etc/icinga2/zones.conf am master


    Code
    1. object Endpoint "swadsp01.spr.local" {
    2. }
    3. object Endpoint "slmonp01.spr.local" {
    4. }
    5. object Zone "spr" {
    6. endpoints = ["swadsp01.spr.local", "slmonp01.spr.local" ]
    7. parent = "master"
    8. }


    zones.conf am slmonp01.spr.local



    zones.conf am swadsp01.spr.local




    icinga2 object list --type Service --name *uptime-snmp*


    Hy Kevin!


    Danke für deine Antwort. An die Zonen habe ich auch schon gedacht.

    Nachdem mein Master keine Verbindung zu den Satelliten aufbauen kann, habe ich an jedem Standort 2 Satelliten um Ausfälle besser zu erkennen.
    So erkenne ich ob der icinga2 Service gestoppt ist oder wirklich der Host IP-technisch nicht antwortet.

    Wenn ich nun den Linux Client in eine eigene Zone gebe, kann ich diese dann noch gegenseitig via Ping überwachen?

    Noch ein anderes Argument warum es vlt nicht an der Zone liegt:

    Gebe ich beim Service als command_endpoint direkt den Linux Host an "command_endpoint = "linuxsatellite.domain.local" " wird der check richtig ausgeführt.

    Das Problem besteht nur wenn ich "command_endpoint = host.vars.remote_client" verwende


    thx

    Roland

    Hallo NG


    Ich darf euch mal wieder um eure Unterstützung bitten.

    Kurz zu meiner Umgebung:


    Bei uns im Haus steht ein icinga2 Master an welchen Standorte angebunden sind. Zwischen dem Master und Standorten existiert kein vpn.
    In den Standorten befinden sich WindowsServer auf welchen der icinga2 Agent läuft (Auf 2 Servern als Satellite und weiter Server die an diese die Satelliten angebunden sind)

    Angedacht ist die Erweiterung der Überwachung mit snmp (switch, nas...).
    Dazu möchte ich am Standort ein Linux Agent installieren und zusammen mit einem WindowsServer als Satelliten einsetzen (2 Satelliten je Standort -> in diesem Fall 1x Linux, 1x Windows)

    Auf allen Hosts wird icinga2 Version r2.6.3-1 (Windows 2.6.3-x86_x64) eingesetzt


    Zum Problem:

    Beim snmp check gebe ich als command_endpoint mittels "vars.remote_client" den Linux Satelliten an.
    Leider wird der check trotzdem über den Windows Satelliten getriggert (Windows kann keine snmp checks)

    Gebe ich beim Service unter check_command direkt den Hostnamen des Linuxservers ein wird der check am richtigen Host ausgeführt


    Konfig:

    Hallo NG


    Anbei noch de Command um eine Minimalconfig des NSClients zu installieren.
    Meiner Meinung nach sollte die für icinga2 ausreichen.
    Danach tausche ich noch die nsclient.ini um ein Passwort zu setzen und die nich benötigten Plugins zu deaktivieren (dass diese nicht versucht werden zu starten)


    msiexec /q /i nscp.msi ADDLOCAL=ALL REMOVE=Documentation,WEBPlugins,DotNetPluginSupport,LuaScript,PythonScript,SampleConfig,Shortcuts,NRPEPlugins,NSCAPlugin,NSCPlugins"

    Hallo NG


    Ich bin eben dabei die Clientinstallation für Windows zu automatisieren. Dabei hänge ich derzeit an 2 Problemen wo ich hoffe ihr könnt mir weiterhelfen.


    1) Node Setup schlägt fehl bei Generierung des Master ca-Files

    Grund ist, dass ich das Ticket gerne für alle Hosts in Kleinbuchstaben ausstellen möchte.
    Der folgende Command zieht jedoch die Variable HOSTNAME heran, diese liest den Namen teilweise in Großbuchstaben aus.

    Kann man den CN bei beim diesem Command mitangeben?


    Code
    1. [root@icinga2-client1.localdomain /]# icinga2 node setup --ticket ead2d570e18c78abf285d6b85524970a0f69c22d \
    2. --endpoint icinga2-master1.localdomain \
    3. --zone icinga2-client1.localdomain \
    4. --master_host icinga2-master1.localdomain \
    5. --trustedcert /etc/icinga2/pki/trusted-master.crt \
    6. --accept-commands --accept-config


    Output bei Ausführen des Commands:

    Code
    1. information/cli: Using the following CN (defaults to FQDN): 'HOSTNAME.domain.local'.

    Fehler weil HOSTNAME.domain.local <> hostname.domain.local



    2) NSClient


    Da ich mit der Icinga2-ITL arbeite benötige ich von NSCLient keinerlei zusätzliche Funktionen wie "Webserver" "nrpe" usw.
    Kennt jemand die Parameter der 0.5 Version mit welchen nur nsca.exe Funktionalität installiert wird?


    Danke u sg
    Roland

    hy rainbow_75

    ich wäre ja für alles offen solange ich vars+= abbilden kann, denn derzeit kann ich mit dem direkor wenig weitermachen.

    es würden zuviele services entstehen welche in meiner alten config nur aus 1 service bestehen


    vlt gibts ja irgendwelche infos bis wann man mit einer lösung/workaround rechnen könnte.


    danke

    Hallo Leute!


    Nun darf ich euch noch eine Frage stellen:


    Bei meiner manuellen Config (ohne director) habe ich gerne mit Configvariablen ( vars += config )gearbeitet.


    Wie kann ich eine solche im Director abbilden?




    Beispiel:


    Hier wird wenn am Host " vars.disks["Disk C"]" existiert eine Service mit Überwachung von C hinzugefügt. Die Schwellwerte konnte ich so variable mitpflegen



    Code
    1. vars.disks["Disk C"] = {
    2. disk_partitions = "C:"
    3. disk_wfree = "15%"
    4. disk_cfree = "10%"
    5. }


    Danke & sg
    Roland

    Hallo


    Leider hatte wohl niemand die gleichen Voraussetzungen wie ich.
    Mittlerweile habe ich mich entschlossen die Config neu zu bauen, anbei meine Erfahrungen. Für Hilfe/Tipps bin ich jederzeit offen :-)


    1
    Die Hosts (Testgerät = Windows Host) welche vom Director aus via IP (Ping) erreichbar sind habe ich als Hosts eingebunden. Als Vorlage dient ein Template in welchen Agent auf yes steht.
    Die Hostüberwachung erfolgt via hostalive und funktioniert (master kann agent per ping erreichen)
    Am Director wurde für den Hosts keine eigene Zone erstellt, am Hosts ist die Zone <FQDN> des Clients vom Kickstart-Script erstellt worden.


    2)
    Hosts (diesmal ein Windows und ein Linux Host) stehen in einem Kundennetz das vom Master nicht erreichbar ist.
    Der Master ist vom Kundennetz unter einem anderen Hostnamen als den FQDN erreichbar. (Der öffentliche Name <> FQDN des Masters)


    In meiner manuellen Konfig habe ich die beiden Hosts in einer gemeinsame Zone erstellt. So konnten sich diese gegenseitig per Ping überwachen.
    Die Möglichkeit, 2 Hosts einer Zone zuzuweisen konnte ich via dem Director noch nicht nachstellen -> Wie Tom sagt möchte ich soweit es geht das Zonenkonzept dem Director überlassen.
    Hier warte ich auf: https://dev.icinga.com/issues/12268


    Da ich jedoch mal weiterkommen muss, kann ich auch damit leben jeden dezentralen Hosts per eigener Zone anzusteueren und als Hostcheck "cluster-zone" zu verwenden.


    aufgetretene Fehler:
    Das Kickstartsctipt schlägt aufgrund der unterschiedlichen FQDN und Hostnamen unter welchen der Master erreichbar ist fehl:

    Code
    1. Notice: Storing Icinga 2 certificates
    2. Exception calling "generateCertificates" with "0" argument(s): "Exception calling "printAndAssertResultBasedOnExitCode"
    3. with "2" argument(s): "critical/TcpSocket: getaddrinfo() failed with error code 11004, "The requested name is valid, but
    4. no data of the requested type was found. " critical/pki: Cannot connect to host '<Interner FQDN Master>c' on port '5665' critica
    5. l/cli: Failed to fetch certificate from host""


    Lösung:
    Im Kickstartscript Zeile 892 den Hostnamen anpassen

    Code
    1. $icinga = Icinga2AgentModule `
    2. -AgentName 'Host.domain.local' `
    3. -Ticket 'xxxxxxxxx' `
    4. -ParentZone 'master' `
    5. -ParentEndpoints '<Interner FQDN Master>' `
    6. -CAServer '<FQDN unter welchen der Master erreicht werden kann>'

    Nach einem Restart des Icinga2-Service am Host schlug die Konfigüberprüfung fehl. Das lag daran, dass in der icinga2.conf und in der global-director die Zone global-director definiert war.
    Ich habe diese aus der icinga2.conf gelöscht, der Host ist derzeit online.





    2 Fragen:
    - Ist/wird es möglich sein 2 Host in einer Zone zu definieren, sodass sich diese per PING überwachen können? -> Wenn bereis möglich bin ich über ein Tipp sehr dankbar
    - Mache ich mit meiner Kickstartinstallation etwas komplett falsch sodass diese Fehler auftreten?



    Danke & sg Roland

    hy


    leider funkt das auskommentieren nicht da der director das aus der DB erstellt und somit "überschrieben wird"


    Derzeit bin ich am überlegen die ganze config nochmals zu löschen und sauber im director abzubilden. is zwar arbeit aber dann sauber


    sg

    Hallo NG


    Aus Dummheit habe ich ein Command welcher bereits als "external Command" definiert ist nochmals im director erstellt. Seitdem kann ich die Config aufrund von "duplicate Command" nicht deploy'n


    Wenn ich den Command löschen will, wird der von mir im director erstellte Command ebenfalls als "extern" angezeigt und lässt sich nicht löschen.
    Des weiteren markieren sich in der GUI (unter Commands) beim anklicken eines der beiden Commands beide.


    Meine Frage: Wie bekomme ich den doppelten Eintrag wieder aus der Config?


    Anbei noch 2 Screenshots


    Danke
    Roland