Update von 7.10.07 auf 7.11.04 schlägt fehl

sven-schmidt · June 10, 2016, 10:37pm

Hallo zusammen,

das Update unserer Mobydick von Version 7.10.07 auf 7.11.04 schlägt fehl. Ein Blick in die Logdatei zeigt, dass es wohl ein Problem bei der Migration einer Ansage gibt.
Vermutlich wird dieser Schritt auch zu der Fehlermeldung im Commander führen (siehe Scrennshot) bzw. dass der XMPP Server nach dem Update nicht wieder startet.

Wir haben zunächst ersteinmal auf unser Backup zurückgegriffen. Wie können wir das Problem beim Update vermeiden?

Log

2016-06-10 23:01:55           cache info     : Flush cache: ok
2016-06-10 23:01:55             sql info     : Connecting to database
2016-06-10 23:01:55           cache notice   : Closing memcache connection
2016-06-10 23:01:55       migration info     : Starting Migration for Package md-cmd
2016-06-10 23:01:55       migration info     : Next Step is [md_cmd_71100_01.php]
2016-06-10 23:01:56       migration info     : Step [md_cmd_71100_01.php] was successfull
2016-06-10 23:01:56       migration info     : Next Step is [md_cmd_71100_03.php]
2016-06-10 23:01:56       migration info     : Step [md_cmd_71100_03.php] was successfull
2016-06-10 23:01:56       migration info     : Next Step is [md_cmd_71100_04.php]
2016-06-10 23:01:56       migration info     : Step [md_cmd_71100_04.php] was successfull
2016-06-10 23:01:56       migration info     : Next Step is [md_cmd_71100_05.php]
2016-06-10 23:01:57       migration info     : Step [md_cmd_71100_05.php] was successfull
2016-06-10 23:01:58       migration info     : Next Step is [md_cmd_71100_07.php]
2016-06-10 23:01:58       migration info     : Step [md_cmd_71100_07.php] was successfull
2016-06-10 23:01:58       migration info     : Next Step is [md_cmd_71100_09.php]
2016-06-10 23:01:58       migration info     : Step [md_cmd_71100_09.php] was successfull
2016-06-10 23:01:58       migration info     : Next Step is [md_cmd_71100_15.php]
2016-06-10 23:01:58       migration info     : Step [md_cmd_71100_15.php] was successfull
2016-06-10 23:01:58       migration info     : Next Step is [md_cmd_71100_19.php]
2016-06-10 23:01:59       migration info     : Step [md_cmd_71100_19.php] was successfull
2016-06-10 23:01:59       migration info     : Next Step is [md_cmd_71100_20.php]
2016-06-10 23:01:59       migration info     : Step [md_cmd_71100_20.php] was successfull
2016-06-10 23:01:59       migration info     : Next Step is [md_cmd_71100_21.php]
2016-06-10 23:01:59 md_cmd_71100_21 info     : Update script default and custom for queue actions
2016-06-10 23:01:59       migration info     : Step [md_cmd_71100_21.php] was successfull
2016-06-10 23:01:59       migration info     : Next Step is [md_cmd_71100_22.php]
2016-06-10 23:01:59 md_cmd_71100_22 info     : Update script default and custom for queue actions
2016-06-10 23:01:59       migration info     : Step [md_cmd_71100_22.php] was successfull
2016-06-10 23:02:00       migration info     : Next Step is [md_cmd_71100_25.php]
2016-06-10 23:02:00       migration info     : Step [md_cmd_71100_25.php] was successfull
2016-06-10 23:02:00       migration info     : Next Step is [md_cmd_71100_30.php]
2016-06-10 23:02:00       migration info     : Step [md_cmd_71100_30.php] was successfull
2016-06-10 23:02:00       migration info     : Next Step is [md_cmd_71100_40.php]
2016-06-10 23:02:00       migration info     : Step [md_cmd_71100_40.php] was successfull
2016-06-10 23:02:00       migration info     : Next Step is [md_cmd_71100_41.php]
2016-06-10 23:02:00 md_cmd_71100_41 info     : prepare aastra basic configuration for call waiting feature
2016-06-10 23:02:00       migration info     : Step [md_cmd_71100_41.php] was successfull
2016-06-10 23:02:00       migration info     : Next Step is [md_cmd_71100_42.php]
2016-06-10 23:02:00 md_cmd_71100_42 info     : prepare snom basic configuration for call waiting feature
2016-06-10 23:02:00       migration info     : Step [md_cmd_71100_42.php] was successfull
2016-06-10 23:02:00       migration info     : Next Step is [md_cmd_71100_43.php]
2016-06-10 23:02:00 md_cmd_71100_43 info     : prepare yealink basic configuration for call waiting feature
2016-06-10 23:02:00       migration info     : Step [md_cmd_71100_43.php] was successfull
2016-06-10 23:02:01       migration info     : Next Step is [md_cmd_71100_44.php]
2016-06-10 23:02:01 md_cmd_71100_44 info     : extend account table for call waiting feature
2016-06-10 23:02:01       migration info     : Step [md_cmd_71100_44.php] was successfull
2016-06-10 23:02:01       migration info     : Next Step is [md_cmd_71100_50.php]
2016-06-10 23:02:01       migration info     : Step [md_cmd_71100_50.php] was successfull
2016-06-10 23:02:01       migration info     : Next Step is [md_cmd_71100_51.php]
2016-06-10 23:02:01 md_cmd_71100_51 info     : Found 2 duplicates for 'Hotline-aus-GF', fixing
2016-06-10 23:02:01       migration info     : Next Step is [md_cmd_71100_51.php]
2016-06-10 23:02:01 md_cmd_71100_51 info     : Found 2 duplicates for 'Hotline-aus-GF', fixing
2016-06-10 23:02:01 md_cmd_71100_51 info     : Found 2 duplicates for 'Hotline-in-GF', fixing
2016-06-10 23:02:01 md_cmd_71100_51 info     : Setting unique constraint for 035fil_name
2016-06-10 23:02:01       simplesql error    : Query Error: 23505; 7; FEHLER:  konnte Unique Index »idx_035fil_name« nicht erstellen
DETAIL:  Schlüssel ("035fil_name")=(Zentrale-aus-GF) ist doppelt vorhanden. CREATE UNIQUE INDEX idx_035fil_name ON public."035file" ("035fil_name");
2016-06-10 23:02:01       migration emergency : 23505; 7; FEHLER:  konnte Unique Index »idx_035fil_name« nicht erstellen
DETAIL:  Schlüssel ("035fil_name")=(Zentrale-aus-GF) ist doppelt vorhanden.
2016-06-10 23:02:01       migration error    : Step [md_cmd_71100_51.php] failed
2016-06-10 23:02:01       migration error    : Running md_cmd_71100_51.php failed, aborting.
2016-06-10 23:02:01           cache info     : Flush cache: ok

Gruß,
Sven

jlorenz · June 13, 2016, 12:07am

Hallo Sven,

ich würde als ersten Schritt einmal versuchen, die problematische Ansage zu löschen, und dann erst das Update durchzuführen. Hinterher kann man die Ansage dann ja wieder einspielen…

Grüße,
Jan

sven-schmidt · June 13, 2016, 12:35pm

Hallo Jan,

leider lässt sich diese Ansage nicht löschen, es folgt die Fehlermeldung “Der Datensatz konnte nicht gelöscht werden”. Seltsamerweise existieren die o.g. Ansagen doppelt unter gleichem Namen, aber auch unsere Ansagen für die Zentrale sind doppelt vorhanden und werden vermutlich ebenfalls zu Problemen beim Update führen. Interessanterweise war in den insgesamt vier Ansagen der Reiter “Verwendet in” nicht gefüllt. Erst als ich in der Warteschlange die Ansagen gewechselt und diese anschließend auf den Ursprungzustand zurückgesetzt habe, wurde der Reiter gefüllt. Kann es sein, dass noch verwaiste Einträge existieren, die ich über die Oberfläche nicht einsehen kann? Die Ansagen werden aktuell definitiv nur in zwei Warteschlangen verwendet.

Gruß,
Sven

jlorenz · June 14, 2016, 12:40am

Hallo Sven,

ich habe mir das Migrationslog nochmal genauer angesehen. Wir haben Code der beim Update auf 7.11 solche Duplikate “Aufräumen” sollte. Dieser scheint nicht 100% zu funktionieren. Ich habe dafür mal ein Bug-Ticket aufgenommen. Könntest du aber zwecks leichterer Reproduzierbarkeit / Problembehebung ein Datenbankbackup deiner Appliance an support@pascom.net senden?

Bitte füge in der E-Mail auch den Link auf diesen Thread ein und einen Verweis das das Backup für die Entwicklung bestimmt ist…

Grüße,
Jan

jlorenz · June 14, 2016, 7:40am

Hallo Sven,

vielen Dank für das schnelle zur Verfügung stellen des Backups, das Problem war dadurch recht leicht zu finden. Ein Fix dafür erscheint mit der 7.11.05.

Grüße,
Jan

sven-schmidt · June 14, 2016, 10:24pm

Hallo Jan,

prima, dann warten wir auf das Update.

Gruß,
Sven

jlorenz · June 15, 2016, 3:13am

Hallo Sven,

ein Hinweis noch für “nach dem Update”: Wenn ihr LDAP am Snom verwendet, solltet ihr eure Basis-Konfigurationen dann noch so anpassen, dass ldap_username und ldap_passwort mit “Geschützt” und einem Leerzeichen provisioniert wird. Ansonsten kann es sein das “alte mobydick 7.10” Einstellungen verhindern das die Telefone vernünftige LDAP-Abfragen machen.

Grüße,
Jan

sven-schmidt · June 23, 2016, 6:55am

Hallo,

kurze Rückmeldung. Das Update konnte nun problemlos ausgeführt werden. Die doppelten Einträge in den Ansagen wurden vom Updater umbenannt und vor mir im Anschluss gelöscht. Der Tipp mit dem LDAP Telefonbuch funtkioniert auch einwandfrei.

jlorenz · June 23, 2016, 6:58am

Hallo Sven,

schön wenn alles klappt!

Grüße,
Jan