Upgrade ICINGA 2.6 -> 2.8

Möglicher Fehler während dem Upgrade von ICINGA2 von Version 2.6 auf 2.8.

Nachdem ich gestern die erste Instanz von ICINGA2 updated habe, wollte der Assistent auch die Datenbank aktualisieren. Dies schlug aber mit folgendem Fehler fehl:

ERROR 1728 (HY000) at line 17: Cannot load from mysql.proc. The table is probably corrupted

Nach ignorieren des Fehlers konnte das Update beendet wurden und ICINGA startete wieder, jedoch mit der Bemerkung, das IDO nicht läuft.

Nach einer Weile analysieren konnte fand ich dann heraus, dass effektiv nicht Version 2.8 gestartet war, sondern erst 2.6. Ein manueller Start via icinga2 daemon brachte dann zu Tage, dass bereits eine Instanz lief mit entsprechender PID. Mit kill PID wurde die Instanz geschlossen und habe dann erneut versucht, via icinga2 daemon zu starten. Auch das schlug fehl, da die Datenbank nicht ansprechbar war.

Dann dachte ich mir, ok, mache ich das Schemaupgrade manuell via:

mysql -u icinga2 -p icinga2 < /usr/share/icinga2-ido-mysql/schema/upgrade/2.6.0.sql

und das klappte soweit auch.

Dann das Schemaupgrade auf Version 2.8 via:

mysql -u icinga2 -p icinga2 < /usr/share/icinga2-ido-mysql/schema/upgrade/2.8.0.sql

Auch das schlug fehl wiederum mit dem Fehler:

ERROR 1728 (HY000) at line 17: Cannot load from mysql.proc. The table is probably corrupted.

Also kam mir mal die Idee, das eventuell der SQL Server noch ein Upgrade nötig hat, was man wie folgt anschieben kann:

mysql_upgrade -uroot -p --force

Da wurde dann tatsächlich noch alle Tabellen etc. angepasst und anschliessend klappte es auch mit dem Schemaupgrade.

mysql -u icinga2 -p icinga2 < /usr/share/icinga2-ido-mysql/schema/upgrade/2.8.0.sql

Ein weitere Punkt ist, dass an den Zertifikaten ein paar Änderungen vorgenommen wurden. Sicherheitshalbe habe ich noch mit

icinga2 api setup

die Einrichtung der API angeschubst.

Da der Browser ein Cookie abgelegt hat, meldet mich Icinga2 automatisch an. Beim Einsatz vom Director kann das nach dem Upgrade ein kleines Problem darstellen. Jede Änderung, bei der Director in die Datenbank schreiben muss, schlägt mit einer XXL-Meldung fehl:

Storing director_activity_log[] failed: SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'author' cannot be null, query was: INSERT INTO director_activity_log (object_name, action_name, object_type, old_properties, new_properties, author, change_time, checksum, parent_checksum) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?) {array ( 'id' => NULL, 'object_name' => 'Agent - Windows', 'action_name' => 'modify', 'object_type' => 'icinga_host', 'old_properties' => '{"object_name":"Agent - Windows","object_type":"template","check_command":"ping4","max_check_attempts":"2","check_interval":"60","retry_interval":"60","enable_notifications":"y","enable_active_checks":"y","enable_passive_checks":"y","enable_event_handler":"y","enable_perfdata":"y","volatile":"n","zone":"itmoni100.ogs.int","has_agent":"y","master_should_connect":"y","accept_config":"y","vars":{}}', 'new_properties' => '{"accept_config":true,"check_command":"ping4","check_interval":62,"enable_active_checks":true,"enable_event_handler":true,"enable_notifications":true,"enable_passive_checks":true,"enable_perfdata":true,"has_agent":true,"master_should_connect":true,"max_check_attempts":"2","object_name":"Agent - Windows","object_type":"template","retry_interval":"60","volatile":false,"zone":"itmoni100.ogs.int"}', 'author' => NULL, 'change_time' => '2017-11-30 15:44:21', 'checksum' => 'ſ���Ea�`�t��"���', 'parent_checksum' => '@;�g�Bp�(��C��e�}', )} (DbObject.php:814)

Der Teufel steckt im Detail und besagt: Column 'author' cannot be null. Ein kurzer Blick unten links im WebIf zeigt, dass er mich nicht mit meinem üblichen Benutzernamen anzeigt, sondern als "user". Das kann man einfach beheben mit abmelden und wieder anmelden am WebIf. So ist man wieder als Benutzer bekannt und die Änderungen werden wieder in die Datenbank geschrieben.


Drucken