icingaweb2 und icinga2-director: Undefined offset: 0

Eisenfaust

Well-Known Member
Hallo Liste.

Wir betreiben jüngst eine icinga2 Installation, die derzeit auf 12-CURRENT läuft. Zwei Platformen dienen als Testumgebung und sind unterschiedlich in ihrer Topologie: ein Host trägt sowohl die PostgreSQL Datenbank, icinga2 selbst sowie den Apache24 Webserver nebst icingaweb2 und den icinga2-director. Die anderen Umgebung spaltet die wesentlichen Dienste auf jails/hosts auf: Datenbankserver, Webserver, Icinga2 Server. Icingaweb2 und der icinga2-director sind selbstverständlich auf dem Webserver installiert.

Icinga2 arbeitet problemlos. Allerdings laufe ich auf beiden Platformen mit icinga2-director in ein und denselben Fehler, wenn ich das oberste, also "Toplevel" Menü im Icingaweb2 des Modules "Director" aufrufe: es haglet eine "Undefined offset: 0" Fehlermeldung, deren Nachverfolgung in den ersten Zeilen so ausschaut (auf beiden Host identisch):

[...]
#0 /usr/local/www/icingaweb2/modules/director/library/Director/Dashboard/Dashlet/Dashlet.php(233): Icinga\Application\ApplicationBootstrap->Icinga\Application\{closure}(8, 'Undefined offse...', '/usr/local/www/...', 233, Array)
#1 /usr/local/www/icingaweb2/modules/director/library/Director/Dashboard/Dashlet/Dashlet.php(163): Icinga\Module\Director\Dashboard\Dashlet\Dashlet->statSummary(false)
#2 /usr/local/www/icingaweb2/modules/director/library/Director/Dashboard/Dashlet/Dashlet.php(172): Icinga\Module\Director\Dashboard\Dashlet\Dashlet->getSummary()
#3 zend.view:///usr/local/www/icingaweb2/modules/director/application/views/scripts/dashlets/default.phtml(4): Icinga\Module\Director\Dashboard\Dashlet\Dashlet->getEscapedSummary()
#4 /usr/local/www/icingaweb2/library/Icinga/Web/View.php(231): include('zend.view:///us...')
#5 /usr/local/www/icingaweb2/library/vendor/Zend/View/Abstract.php(877): Icinga\Web\View->_run('/usr/local/www/...')
#6 /usr/local/www/icingaweb2/library/vendor/Zend/View/Helper/Partial.php(106): Zend_View_Abstract->render('dashlets/defaul...')
#7 [internal function]: Zend_View_Helper_Partial->partial('dashlets/defaul...', Array)
[...]

Der "Director" kann in beiden Konfigurationen Daten (Templates) in die Datenbank schreiben - sowohl auf dem Host, der die DB direkt auf derselben Maschine wie Icinga2/Icingaweb2 und Director betreibt, wie auch auf dem System mit dislozierten Hosts und Diensten - daraus schließe ich, daß kein Problem mit dem IDO Backend besteht.

Der "Director" kommuniziert mit Icinga2 über das "REST API 2" - sofern eine Konfiguration verteilt werden soll. Hier habe ich nur rudimentär - nach Anleitungen mittels Node-Wizard usw., die entsprechenden Konfigurationen auf beiden Systemen vervollständigt und mit "curl" die empfohlenen Tests auf den jeweilen Host gemacht - was auch funktioniert.

Wenn ich mittels "/usr/local/www/icingaweb2/bin/icingacli director host show" mit dem CLI etwas machen möchte, erhalte ich eine Fehlermeldung:

[...]
ERROR: Icinga\Exception\IcingaException in /usr/local/www/icingaweb2/library/Icinga/Cli/Command.php:141 with message: Director is not configured correctly
[...]

Nun, eigentlich ist diese Meldung schon weiterführend, denn sie sagt ja, was Sache ist. Nur: nach nunmehr zwei Tagen stoischem Abgleich und Studium der nicht gerade sehr platformunabhängigkeitsfreundlichen Doku zu "icinga2-director (sehr Linux-lastig) bin ich kurz vor der Verzweiflung.

PHP liefert leider keine Logs, die ich auswerten kann (ich kenne mich mit dieser Skriptsprache nicht aus). Die Logs des Apache werfen weder im Access noch im Error Log etwas aus, die DB protokolliert ebenfalls nichts Auffälliges.

Ich weiß auch nicht, was dem php-Gedöns in icinga2-director fehlen sollte - scheinbar ist ein (erwartetes) Array leer. Nur: wie finde ich heraus, was dem Kameraden fehlt?

Im Netz ist nicht viel zu finden - es gibt wohl einen FreeBSD Anwender, der ein Problem hatte, das sich allerdings nach genauerer Analyse und korrekter API Einrichtung in Wohlgefallen aufgelöst hat. Es trifft nicht auf meinen Fall.

ich prüfe gerade, ob die icinga2 Installation überhaupt korrekt ist - mir scheint, das Frickelpaket "vergißt" einfach die Einrichtung von verzeichnissen bzw. setzt gewisse Rechte nicht oder es wird nicht erläutert, daß bestimmte Dateien sicher gemacht werden müssen und dem Nutzer "icinga" (bzw. dem Nutzer, unter welchem icinga2 läuft) gehören müssen, wie zum Beispiel api-user.conf. Man tappt lange im Dunkeln. ich vermute - wohlwollend - daß es sich um ein relativ kleines Problem handelt, das mich hier wie beschrieben nervt, aber wie war das mit dem berühmten Sandkorn und dem Motor ...

ich danke im voraus für Hilfe ...
 
Wenn ich eine Lösung habe, immer gerne. Bislang aber scheitere ich daran herauszufinden, was denn das PHP Skript haben will und nicht kriegt oder findet.

Addendum: Ich bin eben mal mit einem "truss" and das icingacli CLI Programm herangetreten und es erklärt mir, daß es

lstat("/etc/icingaweb2/modules/director/config.ini",0x7fffffffce48) ERR#2 'No such file or directory'

nicht findet! ich denke, das erklärt ja dann doch einiges und ich suche mal nach der Ursache.

Der Pfad muß "/usr/local/etc/icingaweb2/modules/director/config.ini" lauten, und nicht, wie bemängelt, linuxianisch "/etc/icingaweb2/modules/director/config.ini".
 
Im Moment versagt es bei mir :-(

Wie findet icingaweb2 seinen Standard-Konfigurationspfad? Dieser ist irgendwo auf "/usr/local/etc/icingaweb2" gesetzt. Da das für andere Module funktioniert und diese ihre Konfiguration (vermeintlich) finden, schließe ich mal icingaweb2 als Ursache aus und suche im Modul "director". Allerdings finde ich hierzu viel zu wenig Informationen zur "mauellen Konfiguration".
 
Wie findet icingaweb2 seinen Standard-Konfigurationspfad?
Siehe library/Icinga/Application/ApplicationBootstrap.php (um Zeile 140):
Code:
        if ($configDir === null) {
            $configDir = getenv('ICINGAWEB_CONFIGDIR');
            if ($configDir === false) {
                $configDir = Platform::isWindows()
                    ? $baseDir . '/config'
                    : '/etc/icingaweb2';
            }
Hast du die Umgebungsvariable ICINGAWEB_CONFIGDIR im Webserver gesetzt?

Rob
 
Hallo Rob.

Ja, mein Webserver hat folgende Zeile (so, wie die Anleitung es verlangt):

SetEnv ICINGAWEB_CONFIGDIR "/usr/local/etc/icingaweb2/"

Wenn diese Variable auf einen fehlerhaften, nicht existenten Wert gesetzt wäre, würden dann nicht auch andere Module und vor allem die Resourcen für Icingaweb2 nicht funktionieren bzw. nicht gefunden werden?

Ich speichere auch die Icingaweb2 Konfigurations- bzw. Präferenzdaten in einer eigenen Datenbank (sofern diese Information hilfreich sein sollte).

Experimnet:

ich setze in library/Icinga/Application/ApplicationBootstrap.php (um Zeile 140) 9siehe Robs Antwort oben) statt
'/etc/icingaweb2';
auf
'/usr/local/etc/icingaweb2';

Jetzt ist die Fehlermeldung im "icingacli" eine andere, die aber mit der Syntax und nicht vorhandener Zonen/Zonen-Endpunkte zu tun haben - also nicht mehr einen nicht gefundenen Pfad.

Allerdings funktioniert das Webfrontend immer noch nicht und meldet die eingangs (siehe oben) beschrieben Fehlermeldung "Undefined offset: 0"
 
Undefined offset: 0
Die Methode statSummary in library/Director/Dashboard/Dashlet/Dashlet.php erwartet ein skalares Argument, bekommt aber ein boolean false überreicht (siehe Backtrace). Aus false wird dann 0, implizite Typkonvertierung.

Dieses false kommt aus der Methode getSummary, dort wird statSummary folgendermaßen aufgerufen:
Code:
$this->statSummary(current($this->requiredStats));
current ist eine PHP-Funktion, die nur false liefert, wenn der interne Positionszeiger des Arrays hinter den letzten Wert zeigt.

Dies erschließt sich mir nicht.
Das Feld $requiredStats wird im ganzen Quelltext immer nur initialisiert und nirgends anders manipuliert. Prüfen kann man dies mit folgendem Befehl:
Code:
grep -r requiredStats /usr/local/www/icingaweb2/modules/director

Rob
 
Ich bin schier am Verzweifeln.

Über die "Qualitäten" der Skriptsprachen , so auch php, bin ich hinlänglich vorgewarnt. Danke, @Rob, für die Analyse. Einmal davon abgesehen, daß vermutlich der logische Ablauf nicht ganz sauber definiert ist, suche ich nach dem Grund, warum "$this->requiredStats" nicht, also "0" oder "false" enthält.

Meine Vermutung lag bei einer nicht korrekt konfigurierten Kommunikation via API 2, aber hier komme ich nicht weiter, denn auch ohne API 2 Konfiguration sollten wenigstens die vom Icingaweb2-Director dargebotenen Menüpunkte/Piktogramme und Konfigurationsmöglichkeiten erscheinen und nicht dieser abstruse Fehler "Undefined Offset: 0".
 
Zuletzt bearbeitet:
Das Modul checke ich via Subversion aus. Momentan ist es bei Version 4022.


Was auch immer ich mit dem CLI (icingacli) und dem Modul "director" mache, ich erhalte die fehlermeldung, daß der "Director" nicht korrekt konfiguriert sei:

root@www:/usr/local/www/icingaweb2/modules/director # /usr/local/www/icingaweb2/bin/icingacli director core
ERROR: Icinga\Exception\IcingaException in /usr/local/www/icingaweb2/library/Icinga/Cli/Command.php:141 with message: Director is not configured correctly

Das läßt mich dann doch vermuten, daß irgendwo die Konfiguration nicht korrekt ist, entweder Linuxismen oder falsche Zugriffsrechte oder, was leider in vielen Modulen auch vorkommt, statische Pfade zu wichtigen Konfigurationsverzeichnissen (sehr oft /etc/icingaweb2/ statt /usr/local/etc/icingaweb2, gilt für die *BSD UNIXe).
 
... und wie soll es denn auch anders sein :-(

Ein truss offenbart das geahnte Problem:

[...]
lstat("/usr/local/www/icingaweb2/modules/director/library/Director/IcingaConfig/IcingaConfigRenderer.php",{ mode=-rw-r--r-- ,inode=231726,size=206,blksize=4096 }) = 0 (0x0)
lstat("/usr/local/www/icingaweb2/modules/director/library/Director/IcingaConfig",{ mode=drwxr-xr-x ,inode=231700,size=13,blksize=4096 }) = 0 (0x0)
access("/usr/local/www/icingaweb2/modules/director/library/Director/IcingaConfig/IcingaConfigRenderer.php",F_OK) = 0 (0x0)
openat(AT_FDCWD,"/usr/local/www/icingaweb2/modules/director/library/Director/IcingaConfig/IcingaConfigRenderer.php",O_RDONLY,00) = 5 (0x5)
fstat(5,{ mode=-rw-r--r-- ,inode=231726,size=206,blksize=4096 }) = 0 (0x0)
__sysctl(0x7fffffffc630,0x2,0x7fffffffc614,0x7fffffffc618,0x0,0x0) = 0 (0x0)
fstat(5,{ mode=-rw-r--r-- ,inode=231726,size=206,blksize=4096 }) = 0 (0x0)
fstat(5,{ mode=-rw-r--r-- ,inode=231726,size=206,blksize=4096 }) = 0 (0x0)
mmap(0x0,206,PROT_READ,MAP_SHARED,5,0x0) = 34370547712 (0x800a4f000)
munmap(0x800a4f000,206) = 0 (0x0)
close(5) = 0 (0x0)
------
lstat("/etc/icingaweb2/modules/director/config.ini",0x7fffffffce48) ERR#2 'No such file or directory'
------
lstat("/usr/local/www/icingaweb2/library/Icinga/Exception/IcingaException.php",{ mode=-r--r--r-- ,inode=201381,size=1614,blksize=4096 }) = 0 (0x0)
lstat("/usr/local/www/icingaweb2/library/Icinga/Exception",{ mode=drwxr-xr-x ,inode=195029,size=17,blksize=4096 }) = 0 (0x0)
access("/usr/local/www/icingaweb2/library/Icinga/Exception/IcingaException.php",F_OK) = 0 (0x0)
openat(AT_FDCWD,"/usr/local/www/icingaweb2/library/Icinga/Exception/IcingaException.php",O_RDONLY,00) = 5 (0x5)
fstat(5,{ mode=-r--r--r-- ,inode=201381,size=1614,blksize=4096 }) = 0 (0x0)
__sysctl(0x7fffffffd210,0x2,0x7fffffffd1f4,0x7fffffffd1f8,0x0,0x0) = 0 (0x0)
fstat(5,{ mode=-r--r--r-- ,inode=201381,size=1614,blksize=4096 }) = 0 (0x0)
fstat(5,{ mode=-r--r--r-- ,inode=201381,size=1614,blksize=4096 }) = 0 (0x0)
mmap(0x0,1614,PROT_READ,MAP_SHARED,5,0x0) = 34370547712 (0x800a4f000)
munmap(0x800a4f000,1614) = 0 (0x0)
close(5) = 0 (0x0)
ERROR: Icinga\Exception\IcingaException in /usr/local/www/icingaweb2/library/Icinga/Cli/Command.php:141 with message: Director is not configured correctly
write(1,"\^[[31mERROR\^[[0m: Icinga\\Exce"...,164) = 164 (0xa4)
[...]

Ich hatte in NagVis ein ähnliches Problem, das ich aber, weil ich blind war, bei der Einrichtung nicht beachtete: dort wird ein PHP Code-Schnipsel in die index.php im Core gepflanzt mit dem entsprechenden Pfad für die Konfigurationsdaten:

https://github.com/Icinga/icingaweb2-module-nagvis

Vermutlich ist hier ähnliches passiert und mein Director findet eben seine Konfiguration nicht :-(
 
Die Frage ist eben, ob icingacli auch die Umgebungsvariable entsprechend setzt. Ich würde das Tool mal mittels env und der entsprechenden Zuweisung aufrufen.

Rob
 
Den Konfigurationspfad sollten icingaweb2-Module durch explizites Setzen der Umgebungsvariablen

ICINGAWEB_CONFIGDIR

finden. Diese Umgebungsvariable wird in der Konfiguration zum Apache 2.4 Webserver gesetzt (siehe z.B. https://lists.icinga.org/pipermail/icinga-checkins/2015-December/048320.html - ich habe Besseres leider nicht gefunden).

Die Umgebungsvariable ICINGAWEB_CONFIGDIR wird in icingaweb2 im Modul ApplicationsBootstrap.php eruiert:

icingaweb2/library/Icinga/Application/ApplicationBootstrap.php, etwa Zeile 140

Hier steht der Standardwert, falls die Variable nichts liefert, auf '/etc/icingaweb2', genau das, was icingacli auch findet, weil ICINGAWEB_CONFIGDIR nur vom Webserver gesetzt wird. Wenn ich entweder in besagtem obigen Modul den Standardpfad ändere oder die SHELL Umgebung mit der Variable und ihrem korrekten Wert belege, arbeitet auch das icingacli Kommando - nicht aber der Director :-(
 
... das wollte ich eigentlich vermeiden ... ;-)
Da ich jetzt die Umgebung mit ICINGAWEB_CONFIGDIR=/usr/local/etc/icingaweb2 gefüttert habe, funktioniert "icingacli" wie erwartet - es findet also sein Zielverzeichnis für die Konfiguration.

Nur der Director in der Webumgebung beglückt mich immer noch mit seinem renitenten "Undefined Offset: 0".

Auf der Basis des Traces kann ich mir absolut kein Bild machen, wonach "Director" sucht :-(
 
Der Fehler hat auch nichts mit der vermeintlich fehlerhaften Konfiguration zu tun, das hast du ja weiter oben bereits rausgefunden.
Ich würde die Entwickler mal anschreiben.

Rob
 
Ja, ein Kontakt mit den Entwicklern wird wohl schneller zum Ziel führen. Ich wollte ausschließen, daß es ein übersehenes Konfigurationsproblem ist.
 
Hi!

Ich hänge hier auch mit der gleichen Fehlermeldung. Es bringt auch nichts, wenn man in /etc den symlink zu icingaweb2 anlegt, die Fehlermeldung in der WebGUI bleibt die gleiche.

Ich verwende den nginx mit php-fpm und sowohl in der nginx.conf, als auch in der php-fpm.conf ist die ICINGAWEB_CONFIGDIR Variable gesetzt. Ich tendiere dazu, dass das gar nichts mit diesem Problem zu tun hat. Probleme treten ja auch gerne in Rudeln auf...

Hat jemand News zu dem Thema?

Ciao.
Markus
 
@max93: Das Problem ist inzwischen gefixt. Du benötigst die neueste Version des Icinga 2 Ports. Seit vorgestern ist auch net-mgmt/icingaweb2-module-director in den Ports.
 
Hm:

Code:
root@icinga02:~# pkg info | grep icinga
icinga2-2.6.1_1                Monitoring and management system for hosts, services and networks
icingaweb2-2.4.1_1             Next generation web interface for Icinga 1 and 2

Nur den neuen icingaweb2-module-director port hab ich noch nicht. Ich installier den mal nach und melde mich dann nochmal.

Danke!
Markus
 
Der macht aber auch nix anderes :)

Schau mal in /usr/local/etc/rc.d/icinga2, ob da /usr/local/sbin im PATH gesetzt wird. Wenn ja, starte Icinga 2 mal neu, dann sollte es gehen.
 
Also,

/usr/local/sbin wird in der rc.d/icinga2 schon gesetzt, das ist es bei mir auch nicht.

Aber lass' mal gut sein (wenn es für dich schon läuft, dann hat's wohl was mit php-fpm und/oder nginx zu tun), ich kann das Director Modul für mich wohl eher nicht nutzen, ich brauche Abhängigkeiten (die man dort nicht anlegen kann) damit ich bei Ausfall meiner Leitung nicht mit SMS zugeschixxen werde ;-) Darum muss ich wohl doch wieder handgeschöpfte Configs bauen...

Danke für deinen unermüdlichen Einsatz!
Markus
 
Zurück
Oben