Probleme bei Migration mit Kölns Skripten
Jan Koppe
ich kämpfe momentan mit einer Migration unserer bestehenden Aufnahmen
aus einem Opencast 2.2.3 in unser neues Opencast 3.3 System. Dazu
verwende ich die Migrationsskripte der Kölner:
https://bitbucket.org/uni-koeln/oc-tools
Leider scheinen bei uns in allen MP die catalog.xml abhanden gekommen zu
sein. In den Ordnern finden sich auch keine entsprechenden XML Dateien
die als catalog.xml durchgehen könnten. Es scheint, als wäre da etwas
mächtig kaputt.
Wenn ich die URL manuell abrufe werden mir die Daten passend
zurückgegeben, also irgendwo muss diese Datei wohl existieren. Hat
jemand eine Idee, wo man die Dateien auf Dateisystem-Ebene finden kann?
Notfalls muss ich im Script als "letzte Lösung" einen Download der Datei
aus dem Opencast als Alternative zum kopieren einbauen, aber wirklich
glücklich macht mich so eine Lösung auch nicht.
Relevante Log-Zeilen:
2017-10-09 09:40:39,368 | DEBUG | (root) - Attempting to migrate
mediapackage 'c8803973-f268-4f84-af66-aef54357e679'
2017-10-09 09:40:39,410 | DEBUG | (ArchiveServiceExport) - Filtering
element '210fc794-b53a-445c-b81d-a14c8289a3c3' because of its flavor:
'presenterfull/backup
2017-10-09 09:40:39,435 | DEBUG | (root) - Creating file flag:
'/tmp/migration/b93cf96a-d4e1-4b34-a93a-03ff045a7918/c8803973-f268-4f84-af66-aef54357e679/.failed'
2017-10-09 09:40:39,435 | DEBUG | (root) - Created file flag:
'/tmp/migration/b93cf96a-d4e1-4b34-a93a-03ff045a7918/c8803973-f268-4f84-af66-aef54357e679/.failed'
2017-10-09 09:40:39,435 | ERROR | (root) - The path
'/mnt/data/opencast-data-2017-10-02/opencast/data/opencast/archive/mh_default_org/c8803973-f268-4f84-af66-aef54357e679/7/s-a5d1c011-e256-439e-8010-fa887795fe24.xml'
corresponding to the URL path
'/archive/archive/mediapackage/c8803973-f268-4f84-af66-aef54357e679/s-a5d1c011-e256-439e-8010-fa887795fe24/7/catalog.xml'
could not be found in the archive
2017-10-09 09:40:39,444 | INFO | (root) - Marking series
b93cf96a-d4e1-4b34-a93a-03ff045a7918 as FAILED
2017-10-09 09:40:39,444 | DEBUG | (root) - Creating file flag:
'/tmp/migration/b93cf96a-d4e1-4b34-a93a-03ff045a7918/.failed'
2017-10-09 09:40:39,444 | DEBUG | (root) - Created file flag:
'/tmp/migration/b93cf96a-d4e1-4b34-a93a-03ff045a7918/.failed'
Gruß
--
Jan Koppe
eLectures / LearnWeb
Westfälische Wilhelms-Universität
Georgskommende 25 - Room 310
48143 Münster/Westf. - Germany
E-mail: jan....@wwu.de
Rüdiger Rolf
die Migrationsskripte sind für die Migration von 1.x zu 2.x bzw 3.x.
Für das Update von 2.3 auf 3.x ist in allen Fällen bisher die Datenbank
Migration erstaunlich unproblematisch gewesen.
Wenn du das Migrationsskript verwenden willst, wirst du es an 2.x
anpassen müssen. Ich denke z.B. das catalog.xml in dublincore.xml
umbenannt wurde. Es gibt wahrscheinlich auch noch etliche andere
angepasste Pfade un Variablen.
Gruß
Rüdiger
Am 09.10.17 um 09:50 schrieb Jan Koppe:
Jan Koppe
ja, ein zwei Anpassungen habe ich schon vornehmen müssen. In lokalen
Tests war eine Migration von 2.2.3 zu 3.3 mit jeweils frischen Instanzen
in Docker containern auch möglich - leider nicht die published-Dateien,
aber das wäre zu verschmerzen.
Ein direktes Datenbank-Backup wollen wir nicht machen, da unsere
Datenbank scheinbar nicht mehr richtig gesund war. Wir hatten mehrere
Aufzeichnungen die komplett feststeckten, bzw. im System total korrupt
und nicht mehr verarbeitbar waren. Daher wollen wir mit einer richtigen
Migration in das neue System auch wieder Ordnung schaffen.
Ich werde jetzt erstmal einen Download fehlender Dateien versuchen als
Ausweichlösung. Im Dateisystem selber finde ich auf die schnelle keine
Datei mit dem Inhalt. :( Evtl. generiert die Opencast direkt aus der
Datenbank?
Gruß
Rüdiger Rolf
so ich hab noch einmal geschaut.
Im Archive liegen die Snapshots rum. Die sind durchnummeriert. Neben
einer manifest.xml solltet ihr da auch eine oder mehrere <guid>.xml
Dateien haben. Zusätzlich sollte unter
<content-dir>/downloads/mh_default_org/engage-player/<event-id>/<guid>/dublincore.xml
liegen.
Wie gesagt, bei 1.x war die Struktur eine andere. Die Dateien selber
sollten zweimal verfügbar sein. Im downloads Bereich müssen sie liegen.
Im Archive eigentlich auch, aber das könnte man falsch konfiguriert haben.
Gruß
Rüdiger
Am 09.10.17 um 10:38 schrieb Jan Koppe:
Rubén Pérez
Hallo zusammen,
Ich möchte zuerst sagen, die Skripts nehmen keine feste Dateinamen an. Das heißt, die Skripts lessen die URLs aus den XML-Antworten von Opencast und übersetzen sie in Dateisystempfade. Deswegen eine Änderung von "catalog.xml" zu "dublincore.xml" wirkt die Skripts absolut nicht.
Das Fehler hat nicht zu tun mit der Publicationen sondern mit dem
Archiv. Die relevante Metode fängt in der zeile
307 der 'migration.py' Datei [1] an. Die
Dokumentation der Methode erklärt das angenommene Format der URLs
und der Archivpfaden. Ich weiß aber nicht, ob das Archivformat
sich zwischen 1.x und 2.x verändert ist. Dass die Archive-URLs
nicht mehr "/episode/..." sondern "archive/..." sind, betrifft die
Auflösung der Pfade nicht.
Falls die Pfad- oder URL-Struktur anders ist, kann man einfach
die Methode anpassen.
Ich hoffe, dass hilft, und Entschuldigung für mein gebrochenes Deutsch.
Grüße
Rubén Pérez Vázquez
Universität zu Köln
Regionales Rechenzentrum (RRZK)
Weyertal 121, Raum 4.05
D-50931 Köln
✆: +49-221-470-89603
[1] https://bitbucket.org/uni-koeln/oc-tools/src/cf018173cf72da3521f811e90afc1a113d6b52e7/migration/migration.py?at=master&fileviewer=file-view-default#migration.py-307
Jan Koppe
dein Deutsch ist mal wieder super gewesen! Da brauchst du keine Sorgen
haben. Ich habe inzwischen das Skript erfolgreich um einen
"download-schritt" erweitert - wird die Datei im lokalen Dateisystem
nicht gefunden, versucht das Skript die Datei direkt über HTTP
herunterzuladen. Das funktioniert auch ziemlich gut, die ZIP Pakete
konnten nun erstellt werden. Wir arbeiten gerade noch am sauberen Import
der ZIP Dateien im neuen Opencast, aber ich bin zuversichtlich, dass wir
heute noch mit der Migration durchstarten können.
Vielen Dank für die Hilfe und Gruß,
Jan
On 09.10.2017 13:45, Rubén Pérez wrote:
>
> Hallo zusammen,
>
> Ich möchte zuerst sagen, die Skripts nehmen keine feste Dateinamen an.
> Das heißt, die Skripts lessen die URLs aus den XML-Antworten von
> Opencast und übersetzen sie in Dateisystempfade. Deswegen eine
> Änderung von "catalog.xml" zu "dublincore.xml" wirkt die Skripts
> absolut nicht.
>
> Das Fehler hat nicht zu tun mit der Publicationen sondern mit dem
> Archiv. Die relevante Metode fängt in der zeile 307 der 'migration.py'
> Datei
> /Regionales Rechenzentrum (RRZK)/
> D-50931 Köln
> ✆: +49-221-470-89603
>
> [1]
> https://bitbucket.org/uni-koeln/oc-tools/src/cf018173cf72da3521f811e90afc1a113d6b52e7/migration/migration.py?at=master&fileviewer=file-view-default#migration.py-307
> You received this message because you are subscribed to the Google
> Groups "Deutschsprachige Opencast Community" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to anwender+u...@opencast.org
> <mailto:anwender+u...@opencast.org>.
Rubén Pérez
Hallo Jan,
Ich freue mich darüber, dass ihr eine Lösung gefundent habt!
Trotzdem kann ich nicht verstehen, warum der Elementpfad falsch
gerechnet wird, wenn das Element durch HTTP erreichbar ist. Hat
die Archivstruktur sich geändert? Wo liegt genau die Datei, die
heruntergeladen wird?
Grüße
Universität zu Köln
Regionales Rechenzentrum (RRZK)
Lars Kiesow
meine *Vermutung* wäre, dass es das Mediapackage ist welches in der
Datenbank liegt und von dort ausgeliefert wird.
–Lars
Rubén Pérez
Hallo Lars,
Meine auch. Deswegen bearbeitet das Skript die URLs in keiner "komischen" Weise: es uberstetzt nur die URLs in Pfade genau so wie die entsprechenden Services in Opencast. Ich habe sogar das Prozess direkt im Skript dokumentiert. Deswegen fragte ich, ob die Archivstruktur sich geändert hat. Dann sollte man selbstverständlich die Umwandlung der URLs auf Pfade im Skript modifizieren, sodass die realen und die vom Skript gerechneten Archivpfade zusammenpassen. Aber wenn es das Problem wäre, wären statt nur einige alle Elemente betroffen.
Wenn ich ein Beispiel der realen Archivstruktur hätte, um sie mit der, die das Skript erwartet, zu vergleichen, könnte ich etwas konkreter sagen.
Grüße
Rubén
Rubén Pérez Vázquez
Universität zu Köln
Regionales Rechenzentrum (RRZK)