Posts by Ruven.Graf

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

    Hallo nochmal,


    ich hatte die 64bit Version vom 29.07 genommen, also brandneu. (Die 32bit kann man auf nem 64bit nicht installieren)


    Save Password ändert leider nichts.


    Was noch interssant ist, wenn ich auf "OK" drücke, dann verschwindet das Fenster wie schon erwähnt.



    Wenn ich Nagstamon dann wieder starte, dann sagt er er hätte keine gespeicherte Konfiguration... alles sehr komisch.



    Kleines edit noch:


    Wenn ich die Eingabe bestätige geht Nagstamon zu und der Prozess auch!


    Es läuft dann also nichts mehr.

    Hallo Leute,


    ich versuche gerade Nagstamon 2.XX mit Icingaweb2 zum laufen zu bringen, aber irgendwas klappt nicht so ganz.


    Wenn ich einen AD-User, der für den Zugriff auf Icingaweb2 berechtigt ist, angebe, dann geht Nagstamon einfach zu nach Eingabe des Passworts.


    Der Prozess läuft zwar weiterhin aber er lässt sich nicht mehr "wecken".



    Mach ich hier irgendwas grundlegendes falsch? Muss man einen speziellen User einrichten für diesen Zugriff? Wenn ja, wie?


    Konfig sieht so aus:



    Vielen Dank im Voraus.




    Liebe Grüße

    Hallo Leute,


    ich habe heute Icinga2 auf einem Windows Client installiert, genauer die neuste Version 2.4.10.


    Dabei musste ich mich doch sehr wundern, dass das ICINGA2-Verzeichnis auf C:\Programme jetzt ziemlich anders aussieht.


    Ob das jetzt daran liegt das sich das von Version 2.4.1 auf 2.4.10 geändert hat, oder wegen dem Umstieg von 32 auf 64bit weiß ich nicht, aber die Tatsache ist, dass ich nichtmehr alle Unterverzeichnisse finde.



    Zwar bin ich, wie der Titel schon sagt, auf der suche nach dem "pki" Verzeichnis. Dieses lag früher hier: C:\Program Files (x86)\ICINGA2\etc\icinga2\pki


    ist jetzt aber nichtmehr aufzufinden in der neuen Version.



    Ich würde gerne wieder mit NSIS ein Paket für die unattended Installation bauen, dazu muss ich jedoch wissen wo ich die Zertifikate ablegen muss, falls das überhaupt noch so geht.



    Habt ihr da zufällig schon Erfahrungen gemacht?




    Vielen Dank im Voraus und schönes Wochenende!



    Gruß

    Hallo Leute,


    ich habe derzeit ein kleines Problem mit der Installation von Icinga2 auf SLES11.


    Derzeit haben wir noch 2 SLES11 Maschinen in unserer Umgebung, das sind die einzigen die übrig bleiben und die werden auch nichtmehr so lange leben.



    Ich habe die dringende Anforderung diese Maschinen zu überwachen, bekomme aber über unser Repository die Icinga2-Pakete nicht installiert.


    An sich ist mir das auch recht egal, denn das Ende dieser Server ist ja schon besiegelt und ich will sie nur noch bis dahin überwachen, bestenfalls nicht über NRPE.



    Jetzt zu meiner Frage:


    Kann mir bitte jemand alle Abhängigkeiten von Icinga2 auf einem SLES11-System auflisten, so dass ich das Ding manuell installieren kann?


    Das wäre echt super.



    Viele Grüße

    Vielen Dank!


    Die Variablen waren tatsächlich nicht mehr vorhanden.


    Habe sie erst als Global Variables gesetzt, dann hat zwar der Check manuell funktioniert aber noch nicht in Icinga, dann habe ich sie im Startskript gesetzt und jetzt geht alles wieder.


    Hatte mir gleich gedacht, dass es nur so eine Kleinigkeit ist.



    Wäre trotzdem interessant wieso die Dinger einfach rausgekickt wurden...



    Danke nochmals und schönes Wochenende.

    Hallo liebe Forengemeinde,



    ich habe gestern mal wieder Packets aktualisiert und seitdem ein kleines Problem.



    Zwar kann ich seit dem das Oracle_Health_Check Plugin nicht mehr nutzen, der schmeißt nur noch mit Criticals um sich das es gerade so raucht.




    Er zeigt in den Icinga WebGUI folgenden fehler (den zeigt er auch wenn ich den Check mit gegebenen Parametern manuell durchführe)



    CRITICAL - cannot connect to *Datenbankname*. ORA-12154: TNS:could not resolve the connect identifier specified (DBD ERROR: OCIServerAttach)



    Erster Gedanke: TNSNames verstrubbelt. Danach den Fehler gegoogelt und siehe da, definitiv was mit den TNSNames.



    Das erste was ich gemacht habe war mir die TNSNames Datei anzuschauen, diese lag unter: /usr/lib/oracle/11.2/client64/network/admin/



    Meines Erachtens ist das genau der Ort wo die Datei sein sollte, da stimmt also alles.



    Nächster Versuch war mal in die Datei reinzuschauen, ob es syntaktische Fehler gibt; keine gesehen.



    Bin jetzt gerade ein bisschen Ratlos wie ich hier weitermachen soll, hat jemand vielleicht eine Idee?





    VIelen Dank im Voraus.




    Gruß

    Hallo nochmal,


    erst nocheinmal danke an alle.


    Ich konnte mich leider in den letzten 2 Wochen gar nicht um das Thema kümmern, da es bei uns ein bisschen stressig zu ging.


    Jetzt habe ich mich heute morgen nochmal in Ruhe hingesetzt und den Fehler tatsächlich gefunden.


    Es war am Ende tatsächlich eine Sache der Groß- und Kleinschreibung.


    Der Icinga2-Windows-Client hatte da schon was vorkonfiguriert, dem ich einfach blind vertraut habe, was, wie sich rausgestellt hat, eine Fehlentscheidung war.


    Jetzt läuft alles so weit zu meiner Zufriedenheit.



    Vielen Dank nochmal an alle!



    Grüße
    Ruven

    Zur Version am Master:


    icinga2 - The Icinga 2 network monitoring daemon (version: r2.4.1-1)


    Version am Client: 2.4.1


    Der log des Clients, im Log wiederholt sich immer wieder dieser Eintrag, mittlerweile ist das Ding 33MB groß.


    [2016-03-18 11:41:36 W. Europe Standard Time] information/JsonRpcConnection: No messages for identity 'dbblx60.badintern.de' have been received in the last 60 seconds.
    [2016-03-18 11:41:36 W. Europe Standard Time] warning/JsonRpcConnection: API client disconnected for identity 'dbblx60.badintern.de'
    [2016-03-18 11:41:36 W. Europe Standard Time] warning/ApiListener: Removing API client for endpoint 'dbblx60.badintern.de'. 0 API clients left.
    [2016-03-18 11:41:39 W. Europe Standard Time] information/JsonRpcConnection: Reconnecting to API endpoint 'dbblx60.badintern.de' via host 'dbblx60.badintern.de' and port '5665'
    [2016-03-18 11:41:39 W. Europe Standard Time] information/ApiListener: New client connection for identity 'dbblx60.badintern.de'
    [2016-03-18 11:41:39 W. Europe Standard Time] information/ApiListener: Sending updates for endpoint 'dbblx60.badintern.de'.
    [2016-03-18 11:41:39 W. Europe Standard Time] information/ApiListener: Syncing runtime objects to endpoint 'dbblx60.badintern.de'.
    [2016-03-18 11:41:39 W. Europe Standard Time] information/ApiListener: Finished sending updates for endpoint 'dbblx60.badintern.de'.
    [2016-03-18 11:41:39 W. Europe Standard Time] information/ApiListener: Replayed 399 messages.


    (Der "DBBLX60.badintern.de" ist der Master)



    Was mir noch aufgefallen ist, wenn ich am Master den Dienst neu starte wirft er folgende warning aus:


    [2016-03-18 10:25:27 +0100] warning/ApiListener: Ignoring config update for object 'DBBWN090.badintern.de!load!DBBWN090-1458262805-14' of type 'Downtime'. 'api' does not accept config.


    (Der "DBBWN090.badintern.de ist der Client um den es geht)



    Könnt ihr damit etwas anfangen?

    Zones.conf des Clients unter "C:\Program Files (x86)\ICINGA2\etc\icinga2\zones.conf"


    Guten Morgen,


    Erstmal danke für die flotte Antwort.


    Also die Konfig des Servers auf dem Master liegt in diesem Verzeichnis:



    /etc/icinga2/zones.d/master/hosts/windows/Server1.domainname.conf


    Drin steht folgendes:


    #object Endpoint "Server1.domainname" {
    #}
    #
    #
    #object Zone "Server1.domainname"" {
    # parent = "master"
    # endpoints = [ "Server1.domainname"" ]
    #}
    #
    #
    #object Host "Server1.domainname"" {
    # import "generic-host"
    #
    #
    # display_name = "Server1"
    # address = "aa.bb.cc.dd" <- ist korrekt
    #
    #
    # vars.os = "Windows"
    #}
    #


    Diese Konfig entspricht genau der anderer, schon funktionierende Server und scheint auch ihren Job zu tun, denn Icinga2 zeigt den Host an und kann ihn auch Pingen.


    Zur zones.conf des Masters:


    Unter: /etc/icinga2/zones.conf



    #object Endpoint "dbblx60.badintern.de" {
    #}
    #
    #
    #object Zone "master" {
    # endpoints = [ "dbblx60.badintern.de" ]
    #}
    #
    #
    #object Zone "global" {
    # global = true
    #}
    #


    Das ist alles was da drin steht, aber andere Clients werden ja gecheckt, also sollte es daran nicht liegen, oder?



    Gruß
    Ruven

    Hallo liebe Forengemeinde,


    ich bin Recht neu im Thema Icinga2 und habe mir selbstverständlich erstmal Dokus etc. durchgelesen.


    Vielleicht etwas zu meinen Kenntnissen, ich habe Icinga2 von einem kürzlich ausgeschiedenen Kollegen "geerbt" und hatte keine Ahnung von dem System.
    Das System an sich war soweit funktionsfähig aufgebaut, die nächste logische Folgearbeit war nun erstmal alle Clients aufzunehmen.
    Ich habe das reine Aufnehmen der Clients in Icinga2 für kein Problem gehalten, bin von viel Tipparbeit ausgegangen, aber wenig zum denken.


    Was ich getan habe:


    Auf dem Master hab ich in der Zones.d/master/hosts in Unterordnern, die mein Ex-Kollege schon angelegt hatte, Conf-Dateien für die Server angelegt.
    Ich habe mich dabei an den schon angelegten Servern orientiert, die er schon angelegt hat, quasi kopiert.
    Gehen wir hier erstmal nur von Windows-Systemem aus.


    Nach dem Anlegen der Windows-Systeme in "...hosts/windows/" tauchten diese nach einem "icinga2 daemon -C" und "service icinga2 reload" auf dem Master auch brav in der Web-GUI auf.


    Nachdem ich alle angelegt hatte, hab ich mich dran gemacht den Client auf der Maschine zu installieren und hier gingen die Probleme los.


    Ich hab also auf einem Server, nennen wir ihn "Server1" IcingaClient2.4.1 installiert und mich an den Wizard gehalten:


    Instance Name: Server1


    Setup Ticket: erstellt mit: icinga2 pki ticket --cn 'Server1.domainname'


    Dann bei Add Endpoint:


    Instance Name: Master.domainname


    Haken gesetzt bei "Connect to this Endpoint"


    Master.domainname, Port 5665


    Haken gesetzt bei "Listen to Connections from the master instance"


    Bei Advanced Options alle drei Haken rein.



    Installation läuft einwandfrei durch, danach Installation des NSClient (wobei der ja soweit noch gar nichts machen muss)


    Schaue ich dann in die Dienste des Servers läuft Icinga2, um auf Nummer sicher zu gehen restarte ich den Dienst nochmal und geh dann auf die Icinga2-WebGUI.


    Schaue ich nun bei dem Server klappt der Ping und der Host wird als "reachable" angezeigt (was auch vorher schon ging), jedoch ist die Icinga2 Instance nicht erreichbar, folgender Fehler erscheint:


    Remote Icinga instance 'Server1' is not connected to 'Master'


    Zur Ergänzung: die Kommunikation auf Port 5665 funktioniert.



    Ich gehe stark davon aus, dass ich irgendwas vergessen habe zu tun oder einen Haken falsch gesetzt habe.


    Mir gehen so langsam die Ideen aus, deswegen wende ich mich nun an euch, ist vielleicht mal erfrischend jemand zu helfen der von Tuten und Blasen keine Ahnung hat.



    Falls ihr irgendwelche Conf-Dateien oder logs braucht wärs super wenn ihr genau sagen könnt welche, ich komme zwar mittlerweile ganz gut klar mit den Files und deren Standorten, aber sicher ist sicher.



    Dann möchte ich mich schonmal im Voraus herzlich bedanken für jegliche Hilfe.



    Liebe Grüße
    Ruven