Posts by Martin

This forum was archived to /woltlab and is now in read-only mode. Please register a new account on our new community platform.

You can create a thread on the new site and link to an archived thread. This archive is available as knowledge base, safe and secured.

More details here.

    Auf Sourceforge ist seit 22. Juni 2017 die NagiosQL Version 3.3.0 verfügbar. Diese enthält keine neuen Funktionalitäten aber wurde für PHP7 aktualisiert und benutzt nun die mysqli Schnittstelle.


    The NagiosQL version 3.3.0 has been available on Sourceforge since 22 June 2017. This version contains no new functionalities but has been updated for PHP7 and uses the mysqli interface.


    https://sourceforge.net/projects/nagiosql/

    Die Frage hier ist eher unglücklich gestellt.


    Man mit NagiosQL gar nicht "kompilieren". Dass sich Icinga gelegentlich verabschiedet, wenn man "RESTART_PROGRAM" an die Command Pipe schickt habe ich auch schon mal irgendwo in diesem Zusammenhang gelesen (in diesem Forum möglicherweise sogar). Mit NagiosQL hat das aber wenig zu tun.


    So oder so wären mehr Details für die Icinga-Spezialisten hier hilfreich, z.Bsp. welche Icinga Version verwendet wird und was das Logfile jeweils ausgibt, wenn ein "RESTART_PROGRAM" an die Pipeline geschickt wird:


    [1331191546] RESTART_PROGRAM;1331191546

    NagiosQL entwickeln ist für mich nur ein unbezahltes Hobby ;)


    D.h. ich kann da auch nur soviel Zeit investieren die ich neben den ganzen anderen Dingen noch erübrigen kann. Da es aber im Grunde natürlich auch viel Spass macht ist das schon die eine oder andere Stunde oder auch mehr. Trotzdem muss ich mich dabei leider immer noch auf das Wesentliche konzentrieren und so ist es halt nicht möglich alles zu tun was wünschenswert wäre. Ich glaube aber Dokumentationen haben bei Entwicklern sowieso nie eine sehr hohe Priorität :rolleyes:


    Kurz: für eine Deutsche Bedienungsanleitung war bisher leider noch keine Zeit übrig, auch wenn das seit Jahren schon auf der Agenda steht.


    Höhere Priorität hat zur Zeit übrigens die Deutsche Installationsanleitung noch auf Englisch zu übersetzen - vielleicht hat einer hier ja Lust da mitzuhelfen?


    Das integrierte Hilfesystem gibt es grundsätzlich nur auf Englisch. Das ist rein technisch auch noch nicht so umgesetzt, dass es Mehrsprachenfähig wäre. Da ist aktuell auch einfach die offizielle (tm) Nagios Dokumentation hinterlegt (http://nagios.sourceforge.net/docs/nagioscore/3/en/toc.html). Ob es die mittlerweilen auch inoffiziell in Deutsch gäbe da, weiss ich gerade nicht. Jedenfalls hatte ich bisher weder grosse Lust noch überhaupt die Zeit diese selbst zu übersetzen.

    Nur das neustarten von Nagios tut es nicht mehr
    da meckert er wegen Berechtigung
    Hatte es aber mal getan und geändert habe ich wissentlich nichts

    Das ist das Problem, das Michi ein paar Beiträge weiter oben erwähnt hat. Die Datei nagios.cmd wird beim effektiven Systemrestart von Nagios (nicht beim Restart über NagiosQL) jedesmal wieder neu angelegt und erhält die Standardberechtigungen. Man kann es auf verschiedene Weisen lösen. Zum einen so wie Michi sagt mit Vererbung, dann könnte man das Nagios Startscript editieren (/etc/init.d/nagios) damit es die Berechtigungen korrigiert oder man setzt den www-data User zusätzlich in die nagios Gruppe, sodass er auf Dateien bei denen die Gruppe nagios Schreibrechte besitzt "mitschreiben" darf.

    Quote

    Bin seit Sunden alle Host am bearbeiten und Rechte am verbiegen bis alle Errors weg waren


    Ich habe jede Menge Warnings zum Thema Duplicate

    Dann hast Du vermutlich zuviel verbogen ;)


    Ich kann davon ausgehen, dass die Supportseite nun keine Fehler mehr zeigt?


    Du hast in Deinen Servicedefinitionen eine NagiosQL Konfigurationsgruppe mit dem Namen "imp_Cisco-ZB3000-2". Innerhalb dieser Gruppe hast Du den Service "PING" definiert. Diesem Service hast Du den Host "Cisco-Core-5" hinzugefügt. Soweit so gut.


    Leider hast Du dann noch eine weitere NagiosQL Konfigurationsgruppe mit dem Namen "imp_Cisco-ZB4000-3" in der Du erneut den Service "PING" definiert hast, aber hier leider auch wieder den Host "Cisco-Core-5" hinzugefügt -> d.h. der Service "PING" ist für den Host "Cisco-Core-5" nun doppelt definiert (Duplicate Warning).


    Damit nicht genug - Du hast das auch noch in den Konfigurationsgruppen "imp_Cisco-ZB4000-2", "imp_Cisco-ZB3000-4", "imp_Cisco-Core-5", "imp_Cisco-ZB4000-4", "imp_Cisco-ZB3000-1" und "imp_Cisco-ZB3000-3" getan, womit Du mittlerweile diesen Service 8x definiert hast. Das mag Nagios nicht. Ein Service sollte nur 1x definiert werden.


    Du solltest also den Host "Cisco-Core-5" aus allen "PING" Servicedefinitionen löschen in die er nicht reingehört - ich tippe mal, dass er nur in die "PING" Definition der NagiosQL Konfigurationsgruppe "imp_Cisco-Core-5" wirklich rein gehört.


    Das sind nun aber Nagios Konfigurationsfehler die mit NagiosQL nicht mehr viel zu tun haben, dieselben Fehler hättest Du auch ohne NagiosQL, wenn Du die Konfigurationsfiles händisch so erstellen würdest. Bei der Konfiguration von Nagios selbst hört mein Support in der Regel auf - das soll Ethan übernehmen :D

    D.h. nagiosql importiert zwar die Config, schreibt sie dann aber in andere Dateien wieder raus?

    Genau. Es gibt da draussen unzählige Arten seine Konfiguration zu speichern, daher überführt NagiosQL die gesamte Konfiguration in klar standardisierte Dateien welche es dann in seiner eigenen, definierten Verzeichnisstruktur ablegt (vorzugsweise unter /etc/nagiosql).


    Beim Import gibt es keine Einschränkung, da kann die gesamte Konfiguration auch in einer einzelnen Datei stehen oder sich selbst auf der lokalen Platte des Clienten befinden (File-Upload).


    Durch diese Standardisierung erreicht man klare, strukturierte Abläufe in der Programmierung und reduziert damit Fehlerquellen. Zudem war es eine Bedingung für die Paketierung bei den grossen Linux-Distributionen, dass man ein eigenes Konfigurationsverzeichnis baut und nicht auf die Verzeichnisse eines anderen Pakets zugreift.


    Nach dem Import stellt man einfach in der nagios.cfg die Konfigurationspfade auf /etc/nagiosql/ um und ab dann nutzt Nagios die von NagiosQL verwaltete Konfiguration.


    Diese Standardisierung gefällt natürlich nicht allen und einige mögen es auch nicht, dass NagiosQL die Konfiguration stückelt (insbesondere bei Hosts und Services) - aber das sind Vorlieben die man nie zu 100% abdecken kann. Nach der Umstellung merkt der Anwender davon nichts mehr - Nachteile ergaben sich daraus bisher noch nie.

    Quote

    Error: Cannot open resource file '/usr/local/nagios/etc/resource.cfg' for reading!
    Error: Unable to write to temp_path ('/usr/local/nagios/var/spool/checkresults') - Permission denied
    Error: Unable to write to check_result_path ('/usr/local/nagios/var/spool/checkresults') - Permission denied

    Da wir das Nagios-Binary während dem Test als www-data ausführen kann es zu diesen Fehlern kommen. Wie sind denn die Berechtigungen dieser drei Dateien?


    # ls -al /usr/local/nagios/etc/resource.cfg
    # ls -ald
    /usr/local/nagios/var/spool/checkresults


    Jetzt nicht mehr :D


    NagiosQL legt die Konfigurationen Deiner Hosts nun unter /etc/nagiosql/hosts ab, d.h. die Datei switch.cfg ist überflüssig. Wäre sie weiterhin eingebunden gäbe es hässliche Fehler wegen doppelten Konfigurationen, daher die Fehlermeldung.


    Sieht so aus, als hättest Du Kapitel 3.1 in der Installationsanleitung nicht gelesen oder zumindest nicht befolgt. Die ganzen cfg_file= und cfg_dir= Pfade in der nagios.cfg müssen auf NagiosQL angepasst werden, dann verschwinden auch die Fehlermeldungen auf der Supportseite.


    cfg_file=/etc/nagiosql/contacttemplates.cfg
    cfg_file=/etc/nagiosql/contactgroups.cfg
    cfg_file=/etc/nagiosql/contacts.cfg
    cfg_file=/etc/nagiosql/timeperiods.cfg
    cfg_file=/etc/nagiosql/commands.cfg
    cfg_file=/etc/nagiosql/hostgroups.cfg
    cfg_file=/etc/nagiosql/servicegroups.cfg
    [usw.]
    ferner auch:
    cfg_dir=/etc/nagiosql/hosts
    cfg_dir=/etc/nagiosql/services


    Alle anderen cfg_file und cfg_dir Zeilen sind zu löschen oder auszukommentieren.


    Die Konfiguration der nagios.cfg Datei muss auf die von Dir festgelegten NagiosQL Pfade passen - sonst verstehen sich die beiden Programme nie.

    Nagios Command Datei Fehler! (nur lesen)


    Nagios Binary Datei Fehler! (Nicht ausführbar)

    sudo chmod 660 /usr/local/nagios/bin/nagios
    sudo chmod 660 /usr/local/nagios/var/rw/nagios.cmd


    brachte jetzt keine Lösung

    # chmod 770 /usr/local/nagios/bin/nagios


    Macht das Binary ausführbar


    # chown www-data.nagios /usr/local/nagios/bin/nagios
    # chown www-data.nagios /usr/local/nagios/var/rw/nagios.cmd


    Setzt die Berechtigungen noch korrekt

    Also: NagiosQL macht zwar den Eindruck es würde arbeiten, aber ich habe nicht den Eindruck das es seine Daten auch an Nagios weitergibt


    der Befehl Konfdateinen prüfen und Nagios neu starten tut es auch nicht

    NagiosQL macht nichts von sich aus - wenn Du willst, dass die Dateien an Nagios weitergegeben werden, dann musst Du NagiosQL schon anweisen das zu tun. Das geschieht unter Werkzeuge -> Nagios steuern.


    Zuerst die Konfigurationsdateien schreiben (zwei Buttons), dann die Konfiguration testen und dann Nagios neu starten.


    Die Voraussetzung dass das klappt ist, dass die Seite unter Verwaltung -> Support keine roten Einträge (Konfigurationsfehler) mehr anzeigt. Sind da rote Einträge müssen diese erst behandelt werden.

    Ich habe den Datenimport genutzt


    unter objekts gibt es natürlich auch eine resource.cfg

    Ah, dann macht das nix - die Datei kann sowieso nicht importiert werden - sie enthält auch nix mit dem NagiosQL etwas anfangen könnte. Diese Meldung beim Import kannst Du dann einfach ignorieren oder noch besser - die Datei gar nicht mehr mehr auswählen für den Import.

    # chown –R www-data.nagios /usr/local/nagios/etc/nagios.cfg


    Ist dasselbe wie wenn man diese beiden Befehle verwenden täte:


    # chown -R www-data /usr/local/nagios/etc/nagios.cfg
    # chgrp -R nagios /usr/local/nagios/etc/nagios.cfg


    Ich finde es einfach bequemer gleich Benutzer und Gruppe mit einem Befehl zu setzen ;)


    P.S: Fehler meinerseits, das -R ist überflüssig

    Ich bin gerade die Pfade am einrichten


    Nagios Konfigurationsdatei usr/local/nagios/etc/nagios.cfg ist nicht beschreibbar
    CGI Konfigurationsdatei usr/local/nagios/etc/cgi.cfg ist nicht beschreibbar


    Die will er nicht

    Ich gehe nun einmal davon aus, dass die Dateien sich tatsächlich auch dort befinden. Auch hier muss der Superuser dafür sorgen, dass die Dateien für den Webserver Demon beschreibbar aber für den Nagios Demon immer noch lesbar sind:


    Z.Bsp. mit
    # chown –R www-data.nagios /usr/local/nagios/etc/nagios.cfg
    # chown –R www-data.nagios /
    usr/local/nagios/etc/cgi.cfg
    # chmod 640 /usr/local/nagios/etc/nagios.cfg
    # chmod 640 /
    usr/local/nagios/etc/cgi.cfg

    Deshalb meine Bitte hier den DB-Layer für NagiosSQL so zu machen, das man die einzelnen Objektmethoden mit einer eigenen DB-Implementierung überschreiben kann. Das erleichtert auch Implementierungen für andere, jetzt noch ungenannte DBs (evtl. SQLite,DB2, Sybase etc..) .

    Der aktuelle (neue) DB Layer von NagiosQL sieht so aus, dass es für jeden Datenbanktyp eine eigene PHP Klasse gibt. Alle diese Klassen bieten gegen aussen dieselben Funktionen an, die sich auch identisch verhalten. Somit entscheidet lediglich, welche Klasse zu Beginn eingebunden wird - welche Datenbank verwendet wird. Also wenn im NagiosQL code steht $dbklasse->connect(), so wird mit der DB verbunden. "connect()" sieht aber in jeder DB Klasse natürlich etwas anders aus.


    Wenn man nun eine zusätzliche Datenbank einbinden will, muss man lediglich eine neue DB Klasse erstellen und einbinden.


    Das ist der eine Teil, der andere Teil - die SQL Abfragen selbst - da habe ich bisher noch keinen eleganten Weg gefunden der mir richtig gefällt :)


    Eine Möglichkeit wäre es, alle SQL Abfragen in einer Definitionsdatei zu sammeln. Das wäre machbar, wird aber durch die schiere Menge der Abfragen mit der Zeit etwas unübersichtlich. Man könnte auch pro DB Typ eine Definitionsdatei erstellen, dann fehlt aber die direkte Gegenüberstellung.


    Eine dynamische Generierung hingegen ist wieder sehr komplex, weil man eine Vielzahl von Nebenbedingungen berücksichtigen müsste.


    Die dritte und bisher letzte Variante ist eine generische Datenbanksprache, die in den jeweiligen DB-Klassen in SQL Statements umgesetzt werden. Allerdings wird das für Drittentwickler etwas komplexer, weil diese Sprache vermutlich etwas gewöhnungsbedürftig wäre.


    Vielleicht hat ja hier noch jemand eine gute Idee, allerdings darf es bei der Umsetzung zu keinem Performanceverlust kommen wie dies bei DB Layern von Drittanbietern oft der Fall ist.