Hallo Pascomteam,
ich habe probeweise unsere “Hauptanlage” exportiert und in die V7 migriert. Hierbei sind folgende Punkte aufgefallen:
Unser Patton Gateway hat die IP-Adresse 172.30.0.6/255.255.0.0 Die Migration läuft nur durch wenn ich vorher eine Netzwerkkarte passend konfiguriere. Ansonsten stirbt der Migrationsassistent (auch nach Stunden kein Output im Browser). Hier der Auszug aus dem migrations.log (via ssh)
Auszug LOGFILE Anfang:
2013-10-09 12:22:50 migration info : Starting Migration for Package md-patton
2013-10-09 12:22:50 migration info : Next Step is [md_patton_30000_01.php]
2013-10-09 12:22:50 migration info : Step [md_patton_30000_01.php] was successfull (SKIPPED)
2013-10-09 12:22:50 migration info : Next Step is [md_patton_30000_05.php]
2013-10-09 12:22:51 migration info : Step [md_patton_30000_05.php] was successfull (SKIPPED)
2013-10-09 12:22:51 migration info : Next Step is [md_patton_30000_10.php]
2013-10-09 12:22:51 migration info : Step [md_patton_30000_10.php] was successfull
2013-10-09 12:22:51 migration info : Next Step is [md_patton_30000_12.php]
2013-10-09 12:22:51 migration info : Step [md_patton_30000_12.php] was successfull
2013-10-09 12:22:51 migration info : Next Step is [md_patton_30000_13.php]
2013-10-09 12:22:51 md_patton_30000_13 info : Create patton gateway isdngate
2013-10-09 12:22:51 md_patton_30000_13 info : Add Port 0 bri
2013-10-09 12:22:51 md_patton_30000_13 info : Add Port 1 bri
2013-10-09 12:22:51 md_patton_30000_13 info : Add Port 2 bri
2013-10-09 12:22:51 md_patton_30000_13 info : Add Port 3 bri
2013-10-09 12:22:51 md_patton_30000_13 info : Add Port 4 bri
2013-10-09 12:22:51 migration emergency : Can not determine interface/ip to reach client 172.30.0.6
2013-10-09 12:22:51 migration error : Step [md_patton_30000_13.php] failed
2013-10-09 12:22:51 migration error : Running md_patton_30000_13.php failed, aborting.
2013-10-09 12:22:51 cache info : Flush cache: ok
2013-10-09 12:22:51 tsk050382 info : Child-Task 050382 wurde mit ] beendet
2013-10-09 12:22:51 tsk050381 info : Enable Webserver
2013-10-09 12:22:51 tsk050381 info : . Starte [mv /BACKUP/sites/* /etc/apache2/sites-enabled]
2013-10-09 12:22:51 tsk050381 info : . Exit: [0]
2013-10-09 12:22:51 tsk050381 info : . Starte [/etc/init.d/apache2 reload]
2013-10-09 12:22:51 tsk050381 info : … Reloading web server config: apache2.
2013-10-09 12:22:51 tsk050381 info : . Exit: [0]
2013-10-09 12:22:51 tsk050381 info : Starting services
2013-10-09 12:22:51 tsk050381 info : . Starte [/etc/init.d/xmppd start]
2013-10-09 12:22:51 tsk050381 info : … Starting xmppd: Delete plugin cache: mdarchive mobydick search.
2013-10-09 12:22:51 tsk050381 info : … xmppd.
2013-10-09 12:22:51 tsk050381 info : . Exit: [0]
2013-10-09 12:22:51 tsk050381 info : . Starte [/etc/init.d/asterisk start]
2013-10-09 12:22:51 tsk050381 info : … Starting Asterisk PBX: asterisk.
2013-10-09 12:22:51 tsk050381 info : . Exit: [0]
2013-10-09 12:22:51 tsk050381 info : . Starte [/etc/init.d/hylafax start]
2013-10-09 12:22:51 tsk050381 info : … Hylafax is disabled, see /etc/default/hylafax
2013-10-09 12:22:51 tsk050381 info : . Exit: [0]
Auszug LOGFILE Ende:
nächster Bug:
In den migrierten Rufgruppen ist die Strategie immer parallel auch wenn in der v6 die Strategie auf sequenziell steht.
In den Aktionen der Benutzer werden Abwürfe auf Rufgruppen gelöscht bzw. nicht übernommen. Dies steht zwar als Warnung im Logfile und ist somit nicht weiter tragisch. Allerdings sehe ich nicht bei welchem Benutzer ich diese Aktion wieder eintragen muss. Hier wären mehr Details im Log sinnvoll oder besser Rufgruppen sauber übernehmen.
Gerne stelle ich auch dieses md6-export.tgz File dem Support zur Verfügung.
Liebe Grüße
Maik