Posts by cWFc2sIh

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

    Es gab for einigen Stunden neue Releases für die einzelnen Icinga core 1 Releases, siehe https://github.com/Icinga/icinga-core/releases
    Für das neue Release 1.14.0 steht im Changelog:


    SECURITY FIXES


    * Bug #13709: CVE-2016-9566: Root priviledge escalation during log file opening
    * Bug #10453: Icinga Classic-UI 1.13.3 and older are vulnerable to XSS - CVE-2015-8010


    Icinga is **not** vulnerable to CVE-2016-9565 since we do not provide any PHP
    files nor external advertising RSS feeds inside the Classic UI.

    Icinga 1.8.4 ist wohl auch betroffen von CVE-2016-8641, siehe https://www.exploit-db.com/exploits/40774/
    denn dort wird auch im Initskript vom root user folgendes ausgeführt:


    chown $IcingaUser:$IcingaGroup $IcingaRunFile

    Danke, ich habe dort geschaut, aber ich kann nicht erkennen, wie mir der Text dort bei der Beantwortung meiner Frage hilft. Vielleicht kannst Du das etwas erläutern?


    Ich habe Icinga 1.8.4 manuell aus dem Tarball entpackt (also kein OMD) und das Init-Skript (auf Ubuntu 10) wird als root gestartet, dort:


    /usr/local/icinga/bin/icinga -d /usr/local/icinga/etc/icinga.cfg

    Hello,


    I have a host with Ubuntu Server LTS 14 and OMD 1.20.
    Core: Nagios 3.5.0
    GUI: Check_MK 1.2.4p5


    After changing the IP address of the host from a.b.c.200/24 to a.b.c.199/24
    (change hostname resolution in DNS and /etc/hosts accordingly)


    and reboot of the host


    To be clear: The IP address of the Nagios (OMD) host itself has changed, not of any host configured in and monitored by Nagios.


    The Nagios(OMD) Host itself is not monitored in Nagios.



    Now the "Network Topolgy" page is just empty. Before it showed up nicely.


    There is a red error message shortly showing up. Something like:


    "Access denied User/setOption"



    The hostname did not change.


    All other is working fine after host IP address change, only issue is with "Network Topology".


    URL is:


    http://myhost.examle.com/mypro…ashboard.py?name=topology


    How can I debug this ? Is there a log?


    How can I solve this ? Somehow "reset" the Topology ?


    There is no file ipaddresses.cache on the whole System at all


    I did


    cmk --update-dns-cache


    as the OMD project user, but that did not solve the problem. Network Topolgy still empty page.


    Did also arping from the host with the new ip, did also not help




    Thanks

    Hallo, ich habe dies bereits auf der check_mk Mailing list gepostet, aber noch keine Antwort erhalten, daher hier auch nochmal falls jemand eine Idee hat, Danke.

    Edit:
    Ich habe dieselbe Frage nochmal in der NagVis-Forums-Sektion gepostet:


    http://www.monitoring-portal.org/wbb/index.php?page=Thread&threadID=34098

    Core: Nagios 3.5.0
    GUI: Check_MK 1.2.4p5



    Zu
    check_interval 0

    Quote

    Regularly scheduled host checks are optional. If you set the check_interval
    option in your host definition to zero (0), Nagios will not perform
    checks of the hosts on a regular basis. It will, however, still perform
    on-demand checks of the host as needed for other parts of the
    monitoring logic.

    (Quelle: https://assets.nagios.com/down…core/3/en/hostchecks.html)

    Hallo,


    bei OMD 1.20


    sind alle Hosts als "stale" markiert (Uhrsymbol mit Warndreieck und Tooltip "This host is stale, no data has been received within the last 1.5 check periods").


    Wir möchten aber gar keine Host-Checks durchführen, dazu haben wir einen Ping-Service Check.


    Hier einige Konfigurationen:


    check_host_freshness=0


    Auch nochmal explizit beim Host:



    Dennoch wird der Host schon nach drei Minuten als stale gekennzeichnet.


    Wie kann ich das Warn-Symbol abschalten?


    Wieso wird das überhaupt eingeblendet wenn check_host_freshness=0 ?

    Hallo,


    OMD 1.20 läuft soweit ok, ich möchte damit Nagios nutzen. Jedoch sind alle Service- und Host-Checks immer nur im Status "Pending" und es wird immer nur angezeigt "Service check schedule for xxx" aber nie ein Result angezeigt.


    Vermutlich hat es mit damit zu tun, dass Gearman keine Verbindung hinbekommt?


    var/log/gearman/worker.log

    Code
    1. [2015-07-24 08:55:12][3993][ERROR] worker error: connect_poll(GEARMAN_TIMEOUT) timeout occurred while trying to connect -> libgearman/connection.cc:109
    2. [2015-07-24 08:57:05][1814][INFO ] no checks in 2minutes, restarting all workers
    3. [2015-07-24 08:57:13][4113][ERROR] worker error: connect_poll(GEARMAN_TIMEOUT) timeout occurred while trying to connect -> libgearman/connection.cc:109
    4. [2015-07-24 08:59:06][1814][INFO ] no checks in 2minutes, restarting all workers
    5. [2015-07-24 08:59:14][4213][ERROR] worker error: connect_poll(GEARMAN_TIMEOUT) timeout occurred while trying to connect -> libgearman/connection.cc:109


    An der mod-gearman-Konfiguration habe ich nichts geändert:


    etc/mod-gearman/port.conf

    Code
    1. # sets the addess of your gearman job server. Please
    2. # change only by using the "omd config" command.
    3. server=localhost:4730


    Der Gearman-Port lauscht auch:

    Code
    1. netstat -l
    2. tcp 0 0 localhost:4730 *:* LISTEN


    Ich kann gearmand nicht stoppen:

    Code
    1. omd stop gearmand
    2. Stopping gearmand........failed
    3. Killing gearmand..................failed


    var/log/gearman/gearmand.log

    Code
    1. ERROR 2015-06-24 07:29:16.000000 [ main ] GEARMAND_WAKEUP_SHUTDOWN(Bad file descriptor) -> libgearman-server/gearmand.cc:364


    gearman_top zeigt nur folgende Fehlermeldung:

    Code
    1. 2015-07-24 09:34:24 - localhost:4730
    2. error reading from localhost:4730 - Interrupted system call


    Was kann hier das Problem sein?
    Fehlen noch Ubuntu-Pakete?


    Ich hatte testweise auch mal manuell diese Pakete:
    libgearman-client-perl libgearman-dbg libgearman7


    vom Ubuntu-Repo installiert (weil hier auch jemand das Problem hatte, dass "keine Checks abgearbeitet" wurden, und die Paket-Installation die Lösung war: http://www.monitoring-portal.org/wbb/index.php?page=Thread&postID=203803#post203803 ), das hat aber nichts gebracht, da habe ich sie wieder deinstalliert


    Hier Angaben zur Umgebung:


    Ich habe folgendes BS frisch aufgesetzt:


    Ubuntu 14.04.2 LTS
    3.13.0-57-generic x86_64 GNU/Linux


    und dann das OMD-DEB-Paket heruntergeladen:
    http://files.omdistro.org/rele…omd-1.20.trusty.amd64.deb


    Code
    1. md5sum omd-1.20.trusty.amd64.deb
    2. 31c49a6a5f6b39f567079bd1f41f2614 omd-1.20.trusty.amd64.deb


    Paket-Anhängigkeiten:


    Code
    1. dpkg-deb --info omd-1.20.trusty.amd64.deb | grep 'Depends' | tr -d ','
    2. Depends: debconf (>= 0.5) | debconf-2.0 time traceroute libsnmp-python curl dialog dnsutils fping graphviz libapache2-mod-fcgid libapache2-mod-proxy-html apache2-mpm-prefork apache2-utils libboost-program-options1.54.0 libboost-system1.54.0 libdbi1 libevent-1.4-2 libltdl7 libnet-snmp-perl libpango1.0-0 libperl5.18 libreadline5 libsnmp-perl libuuid1 libxml2 mysql-server patch php5-cli php5-cgi php5-gd php5-mcrypt php5-sqlite php-pear pyro rsync smbclient snmp unzip xinetd xvfb python-ldap libradiusclient-ng2


    Also die Pakete installiert:

    Code
    1. apt-get install debconf time traceroute libsnmp-python curl dialog dnsutils fping graphviz libapache2-mod-fcgid libapache2-mod-proxy-html apache2-mpm-prefork apache2-utils libboost-program-options1.54.0 libboost-system1.54.0 libdbi1 libevent-1.4-2 libltdl7 libnet-snmp-perl libpango1.0-0 libperl5.18 libreadline5 libsnmp-perl libuuid1 libxml2 mysql-server patch php5-cli php5-cgi php5-gd php5-mcrypt php5-sqlite php-pear pyro rsync smbclient snmp unzip xinetd xvfb python-ldap libradiusclient-ng2


    Dann schließlich das OMD-Deb-Paket installiert:

    Code
    1. dpkg -i omd-1.20.trusty.amd64.deb


    Ich habe nur ein paar Kleinigkeiten an der Nagios-Konfiguration geändert, nur ein paar Hosts und Services zugefügt.
    Läuft eigentlich alles ganz gut, nur im Nagios Classic GUI steht für den Service eines Checks immer
    "Service check scheduled for ....."
    mit der Zeit in ein paar Minuten. Aber es wird nicht gecheckt.


    Hier noch einige Daten:



    Vielen Dank schonmal für die Unterstützung.


    Edit: Habe mit "omd config" mal gearmand, gearman_worker und mod_gearman deaktiviert. Nun werden die Check Results im Nagios Classic GUI auch wie gewohnt angezeigt.


    Ich möchte jedoch gerne gearman nutzen, also wäre schön, wenn jemand die Lösung für dieses Problem hätte.

    Ich habe mal einen Request für die Übernahme der klassischen "All problems" view aus Icinga classic erstellt. Ich würde generell anregen, sich bei der Funktionalität von Icinga Web an der von Icinga Classic zu orientieren, zumindest sollte nichts an Information verloren gehen.


    https://dev.icinga.org/issues/4167

    wer den Anspruch hat, bestimmte Ansichten nativ zu haben, ist herzlich eingeladen, mitzuhelfen und entsprechende Patches einzuschicken in den Bug Tracker :-)

    Hallo jmosshammer,


    vielen Dank für die ausführliche Anleitung. Leider hat die app/modules/Api/config/views/host.xml von icinga-web 1.8.3 nur 222 Zeilen und da ich nicht wirklich weiß, was ich dort genau mache, habe ich mich auf die erste Variante beschränkt, nur das


    Code
    1. AND
    2. hs.problem_has_been_acknowledged = 0 AND
    3. hs.scheduled_downtime_depth = 0


    herauszunehmen. Muss das neben der dql TARGET_OPEN_PROBLEMS auch in der dql TARGET_HOST_OPEN_PROBLEMS gemacht werden?


    Ich habe es überall rausgenommen, also an drei Stellen.


    Das hat wohl auch funktioniert, vielen Dank nochmal.


    Doch dann tat sich das nächste Problem auf:


    Es fehlen in der "Open Problems"-Übersicht die Spalten, wo man sehen kann, dass ein Problem acknowledged ist oder mit einer Scheduled Downtime versehen ist. Ohne diese Information ist die View leider kaum nutzbar.


    Hast Du eine Idee, wie sich dieses Problem möglichst einfach lösen ließe?


    Ich finde es schade, dass es bei Icinga Web nicht von Haus aus die Ansichten gibt, die es auch in Icinga Classic gibt, oder ich habe das Konzept nicht verstanden. Soll es so sein, dass man nur die Open Problems sehen kann und für die acked/downtimes dann oben im Header auf CRITICAL/WARNING etc. klickt, um dann jeweils die Liste mit den acked/downtime problems zu sehen?


    Im Grunde fehlen mir als Ergänzung zu der Ansicht "Open problems" die Ansichten "Handled problems" und "All problems" (open+handled). Gehe ich da mit dem falschen Gedankengang ran, oder wieso gibt es das nicht von Haus aus in Icinga Web?

    Hab das jetzt auf die schnelle nicht getestet, aber so sollte es gehen

    Hallo,


    es gibt ja standardmäßig den "Open problems" cronk. Dort sind acknowledged service problems nicht aufgeführt. Ich suche aber einen Cronk, der wie im Icinga Classic "All problems" (icinga/cgi-bin/status.cgi?allproblems) anzeigt.


    Wie kann ich evtl. den "Open problems" cronk so anpassen, dass auch handled service problems dort angezeigt werden? (würden den Cronk dann in "All problems" umbenennen). Oder noch besser den "Open Problems" Cronk klonen zu "All probloems" und in dem Klon dann alle Problems anzeigen (auch acked / Downtimes).


    Oder wie ist das Konzept, dass acknowleded problems nicht in Vergessenheit geraten, wo werden die angezeigt? Der Header oben fällt ja nicht so sehr ins Auge.


    Danke

    Der Output von diesem Service Check testservice123 wird im Icinga Web nicht korrekt dargestellt: