Die Migration durchführen
Zum Durchführen der Migration gehen Sie schrittweise wie folgt vor:
KIX 17 und KIX 18 unterstützen einen PSK-Modus (PSK = Pre-Shared-Key). Der PSK ist ein Prüfschlüssel zur Absicherung der Datenübertragung. Er verhindert den unautorisierten Zugang zur Datenbank. Nur wenn beiden Systemen dieser vorher vereinbarte Schlüssel bekannt ist, erfolgt die Migration. KIX 17 weist Anfragen zurück wenn kein oder ein falscher PSK übermittelt wird.
Der PSK wird in der Konfigurationsdatei Config.pm von KIX 17 hinterlegt und der Migration in KIX 18 dem Konsolenkommando als Parameter mitgegeben.
Warnung
Ist der PSK-Modus aktiviert, ist das System für den Zugriff von Außen geöffnet. Unbefugte Dritte können sich Zugang zur Datenbank verschaffen, wenn ihnen der Schlüssel bekannt ist.
Für die Benennung des Schlüssels sind daher die Konventionen zur Vergabe eines sicheren Passwortes bindend!
Löschen Sie nach Abschluss der Migration den Schlüssel in beiden Systemen und deaktivieren Sie den PSK-Modus, um den Zugriff von Außen zu unterbinden!
Verwenden Sie einen PSK, der keine zu URL-codierenden Zeichen beinhaltet (https://www.w3schools.com/tags/ref_urlencode.asp) oder führen bei Verwendung solcher Zeichen selbst eine Quotierung aus.
So aktivieren Sie den PSK-Modus
Öffnen Sie die Konfigurationsdatei im Dateisystem von KIX 17.
Diese finden Sie unter:
/opt/kix/Kernel/Config.pm.Suchen Sie den Abschnitt
insert your own config settings "here".Fügen Sie innerhalb des Abschnitts nachfolgende Codezeilen ein.
Entfernen Sie die Kommentare im Code.
Vergeben Sie statt "my_PSK_Password" ein eigenes, sicheres Passwort und speichern Sie Ihre Änderungen.
# PSK-Modus aktivieren $Self->{'Migration::Active'} = 1; # PSK benennen $Self->{'Migration::PSK'} = 'my_PSK_Password';
Navigieren Sie im Admin Modul von KIX 18 zu.
Wählen Sie im Auswahlfeld den Befehl Console::Command::Admin::Installation::Migrate::Run
Tragen Sie die Übertragungsparameter (s. Tabelle unten) in die Befehlszeile ein.
Verwenden Sie folgendes Schema:
--source ... --source-id ... [--options ...] [--type ...] [--mapping-file ...] [--filter ...(+)] [--workers ...]
Beispiele:
--source KIX17 --source-id mykix17 --options URL=http://myKIX17domain:Port/kix/migration.pl,PSK=my_PSK_Password --type ticket
--source KIX17 --source-id mykix17 --options URL=http://172.17.0.1:9990/kix/migration.pl,AutoDeps=1,PSK=test123
Starten Sie die Migration mit Klick auf "Ausführen". Die Migration kann einige Zeit in Anspruch nehmen.
Die Konsole informiert Sie nach Abschluss über die migrierten Daten.
Tipp
Hilfe zu den Konsolenbefehlen erhalten Sie durch Eingabe von --help oder Klick auf
Mögliche Parameter
Verwenden Sie die nachfolgenden Parameter mit 2 vorangestellten Bindestrichen (z. B. --source). Mit einem * gekennzeichnete Parameter sind Pflichtangaben.
Parameter | Beschreibung |
|---|---|
source* | Die Art des Quellsystems, von dem die Daten migriert werden sollen (z. B. --source KIX 17).Das muss eine von KIX 18 unterstützte Quelle sein. |
source-id* | Identifikator für das konkrete Quellsystem (z. B. --source-id myKIX17). In KIX 18 kann von mehreren Quellen migriert werden. Anhand der source-id unterscheidet KIX 18, von welchem System es welche Daten migriert hat. |
options* | Optionen für die Migration, bspw. Server/Host des Quellsystems und PSK:--options URL=http://172.17.0.1:9990/kix/migration.pl,AutoDeps=1,PSK=test123
Mögliche Optionen:
|
type | Durch Angabe dieses Parameters können Sie die Migration auf ausgewählte Objekte (Tickets, Organisationen, Assets, etc.) beschränken. Trennen Sie mehrere Typen durch Komma (z. B. --type ticket,customer_company,configitem). Ist kein Typ angegeben, werden alle unterstützten Objekte migriert. Verwendbare Typen sind (Abhängigkeiten untereinander beachten!):
TippDer Konsolenbefehl Console::Command::Admin::Installation::Migrate::ListTypes --source KIX17 listet alle verfügbaren Typen auf. |
mapping-file | Die JSON-Datei, die für Zuordnungen verwendet werden soll (verwenden Sie ein vorhandenes Objekt, anstatt ein neues zu erstellen). Die wichtigsten Mappings (z. B. Priorität, Status etc.) sind intern schon vorhanden. |
filter | Ein oder mehrere Filterausdrücke. Format und Inhalt hängen von der ausgewählten Quelle ab. Pro Objekttyp kann eine SQL-Where-Klause angeben werden. Format: --filter "ticket{user_id = 123 AND responsible_id in [1,2,3]} |
workers | Anzahl der parallelen Prozesse, die für die Massenobjekte wie Tickets usw. verwendet werden sollen. Standard: 1 Mit der Anzahl der Worker bestimmen Sie die zur Verfügung stehende Systemleistung. Dies hat Einfluss auf die Performance Ihres Servers. Je höher die Anzahl der Worker desto schneller der Migrationsprozess bei stärkerer Belastung des Systems. Vermeiden Sie eine Überlastung Ihres Systems! Bereits 4 Worker können einen Host zu 100% auslasten. Daher sind KIX.Cloud-Umgebebungen auf max. 2 Worker begrenzt. Ist dieser Parameter nicht angegeben, wird der Standardwert 1 verwendet. |
help | Hilfe zu einem Befehl anzeigen. |
quiet | Unterdrückt die Anzeige allgemeiner Informationen. Nur Fehlermeldungen werden in der Konsole angezeigt. |
Wichtig
Bei aktiviertem PSK-Modus können sich unbefugte Dritte Zugang zur Datenbank verschaffen, sobald sie in Besitz des Schlüssels gelangen.
Es ist daher zwingend erforderlich, nach Abschluss der Migration (oder nach Abbruch) den Zugriff auf die Datenbank wieder zu unterbinden!
Löschen Sie dazu den Schlüssel und deaktiveren Sie den Pre-Shared Modus wie folgt:
Öffnen Sie die Konfigurationsdatei im Dateisystem von KIX 17.
Diese finden Sie unter:
/opt/kix/Kernel/Config.pm.Suchen Sie den Abschnitt
insert your own config settings "here"Löschen Sie innerhalb des Abschnitts die von Ihnen eingefügten Codezeilen und speichern Sie diese Änderung.
Die migrierten Daten werden mit einem Migrations-Präfix gekennzeichnet, wenn im Zielsystem bereits eine gleichnamiges Objekt existiert, z. B. Klasse Migration-Computer oder Migration-Nutzername.
Überprüfen Sie die übertragenen Daten, Platzhalter, Signaturen etc. und passen Sie diese ggf. an. Sie können diese einzeln manuell oder durch Anwendung eines Jobs automatisiert bearbeiten.
Anmerkung
Nachdem die Daten übertragen wurden, stehen diese zur Verfügung. Der Aufbau der Indizes für Volltextsuchen oder Anzahl von Tickets pro Team, Assets pro Klasse o.ä. kann jedoch einige Zeit in Anspruch nehmen. Je nach Umfang der Daten (mehrere 100.000 Tickets) kann dies auch mehrere Stunden erfordern.
Anmerkung
Nach Abschluss der Migration ist auf der KIX 18 Umgebung eine Cache-Bereinigung durchzuführen, um inkonsistente Datendarstellung zu vermeiden. Führen Sie dazu im Menü das Kommando Maint::Cache::Delete aus, melden sich von der GUI ab und wieder an.
Für die Übertragung von weiteren Konfigurationen wie Ticket- oder Antwortvorlagen, "Generic Agents", etc. wird ein Tool bereit gestellt. Es wird kontinuierlich weiterentwickelt und kann im Forum bezogen werden: https://forum.kixdesk.com/index.php?topic=11882.0.