restore Script Funktionalität

[NidintuBel]

Hallo,
ich wollte heute unser KIX auf einen neuen Server umziehen. Auf dem neuen Server habe ich deshalb KIX vorinstalliert und dann am alten System ein komplettes Backup gemacht mit dem Backup Script. Danach habe ich auf dem neuem Server das Restorescript gestartet. Es hat scheinbar aucgh geklappt obwohl ich viele Fehlermeldungen bekommen habe das bestimmte Promär und Fremdschlüssel nicht erstellt werden konnten, da diese bereits existieren würden. Mein Custom Skin , Logo und die Einstellungen in der Sysconfig scheinen auch alle da zu sein. Es fehlt aber alles andere wie dynamische Felder, Prozesstickets, Benutzer, Queues, Tickets u.s.w. . Muss ich das wirklich alles manuell importieren?
Außerdem bekomme ich jetzt manchmal eine Fehlermeldung  FATAL:  Passwort-Authentifizierung für Benutzer »kix« fehlgeschlagen FATAL:  Passwort-Authentifizierung für Benutzer »kix« fehlgeschlagen
VG Jakob

[NidintuBel]

Hallo,
vielleicht kann mir ja doch jemand helfen.
Ich versuche die Migration mit folgenden Schritten.
Auf beiden Servern:
root@kix:~# service apache2 stop
kix@kix:~# ./opt/kix17/bin/Cron.sh stop
Alter Server:
root@kix:~# ./opt/kix17/scripts/backup.pl -d /home/foo
Neuer Server:
root@kix:~# ./opt/kix17/scripts/restore.pl -b /home/<Time>/ -d /opt/kix17
Beim Restore bekomme ich aber immer folgende Fehlermeldung:
[Thu Jul 11 09:27:25 2019] restore.pl: DBI connect('dbname=kix17;host=localhost;','kix',...) failed: FATAL:  Passwort-Authentifizierung für Benutzer »kix« fehlgeschlagen
[Thu Jul 11 09:27:25 2019] restore.pl: FATAL:  Passwort-Authentifizierung für Benutzer »kix« fehlgeschlagen at /opt/kix17/Kernel/System/DB.pm line 207.
ERROR: OTRS-restore.pl-10 Perl: 5.24.1 OS: linux Time: Thu Jul 11 09:27:25 2019

Message: FATAL:  Passwort-Authentifizierung für Benutzer »kix« fehlgeschlagen
FATAL:  Passwort-Authentifizierung für Benutzer »kix« fehlgeschlagen

Traceback (2774):
   Module: Kernel::System::DB::Prepare Line: 670
   Module: /opt/kix17/scripts/restore.pl Line: 124

Can't call method "fetchrow_array" on an undefined value at /opt/kix17/Kernel/System/DB.pm line 750.

In der Config.pm habe ich aber den gleichen Datenbankbenutzer kix und auch das gleiche Passwort drin.

[NidintuBel]

Ich habe mich jetzt bei postresql angemeldet und mit der Datenbank kix verbunden. Dann habe ich dort für den benutzer kix manuell das Passwort auf den Wert aus der Config.pm gesetzt. Jetzt startet er auch das Auslesen der Datenbank. Allerdings kommen jetzt dann tausende Fehlermeldungen. Im Ergebnis wurde dann am Ende wieder nichts aus der Datenbank übernommen.
FEHLER:  mehrere Primärschlüssel für Tabelle »ticket_lock_type« nicht erlaubt
FEHLER:  mehrere Primärschlüssel für Tabelle »ticket« nicht erlaubt
FEHLER:  Relation »ticket_priority_name« existiert bereits
FEHLER:  mehrere Primärschlüssel für Tabelle »ticket_priority« nicht erlaubt
u.s.w.
Muss ich den Datenbankdump besser selbst machen ohne das restore Script?
VG Jakob

[Tino Voigt]

Hallo NidintuBel

Eine Ähnlich Anfrage besteht bereits unter: https://forum.kixdesk.com/index.php?topic=135.msg290#msg290

Eventuell hilft dir diese bereits weiter.

Viele Grüße, Tino Voigt

[NidintuBel]

Hallo Tino,
nein hilft mir nicht weiter denn mein Passwort steht nicht verschlüsselt in den Config.pm. Wie ich auch schon geschrieben hatte, konnte ich das Passwortproblem dadurch lösen, dass ich das Passwort für den Benutzer kix manuell in postresql auf den Wert in der Config.pm gesetzt habe. Jetzt beginnt er auch mit der Wiederherstellung der Datenbank aber es kommen hunderte Fehlermeldungen zu bereits bestehenden Schlüsseln in der Datenbank.
Was mir helfen würde, wäre eine detaillierte Anleitung wie ein Backup mit dem Script erstellt werden kann. Ich habe jetzt alles manuell migriert. Das hat mich einen ganzen Arbeitstag gekostet. Zukünftig mache ich lieber ein Backup der kompletten VM, da das Backupscript offensichtlich nicht funktioniert. Der manuelle Umzug war super nervig, da selbst kleinste Versuche Dateien einfach von einer Instanz in die andere zu kopieren stets zum Crash geführt haben und sich auch nicht wieder beheben ließen.

Mal ein Beispiel. Ich hatte in unserer Testversion einen Custom Skin für die Agents drin. Den Custom Ordner habe ich dann auf dem neuen Server direkt nach /opt/kix17/var/httpd/htdocs/skins/Agent kopiert. Danach habe ich den Cache gelöscht (sudo -u www-data bin/kix.Console.pl Maint::Cache::Delete), aufgeräumt (sudo -u www-data bin/kix.Console.pl Maint::Loader::CacheCleanup) und neu erstellt (sudo -u www-data bin/kix.Console.pl Maint::Loader::CacheGenerate).

Dabei bekam ich aber plötzlich die Fehlermeldung  Error: mkdir /opt/kix/var/httpd/htdocs/skins/Agent/default/css-cache/img/: Permission denied at /opt/kix17/Kernel/Output/HTML/Layout/Loader.pm line 475.
Wenn ich jetzt im Browser versuche kix zu öffnen, bekomme ich nur noch einen http500 . Besonders nett ist dabei, dass nach dem Löschen des Custom Ordners das Problem natürlich weiter besteht und ich keine Möglichkeit gefunden habe es zurückzunehmen, obwohl ich vorher noch ein Backup der Originaldateien gemacht habe. Also alles von vorn.
Am Ende habe ich dann wirklich fast alles manuell neu angelegt und nur die CI-Items und User per CSV importieren können. Den Custom Skin muss ich jetzt neu schreiben vermutlich.

VG Jakob

[Tino Voigt]

Anbei eine Anleitung zum Backup und Restore:

Backup

Für ein Backup von KIX inklusive Datenbank kann das Backup Script aus dem Ordner ,,scripts" verwendet werden.
Bevor dieses ausgeführt wird, sollte der KIX Daemon gestoppt werden.

    • sudo -u www-data /opt/kix/bin/kix.Daemon.pl stop
    • perl /opt/kix/scripts/backup.pl -d /tmp/ -c gzip -t fullbackup


Restore

Für den Restore des Kix Backup, kann dann das Restore Script aus dem ,,scripts" Ordner verwendet werden.
Bevor dieses ausgeführt werden kann, sind jedoch einige vorbereitende Schritte notwendig.

Zuerst müsste KIX und ggf. KIX Pro mit dem gleichen Datenbanksystem wie das des Quellsystem
installiert werden.
Hier muss das Kennwort der Datenbank aus der Datei opt/kix/Kernel/Config.pm entnommen werden. Dies wird für die nachfolgenden Schritte benötigt.

Das Restore Script erwartet eine leere Datenbank, daher müssten die Tabellen und Views der eben installierten Datenbank geleert werden.

Anbei ein Beispiel zum leeren der Tabellen und Views unter MySql, dieses müsste für andere Datenbank Systeme angepasst werden:

Inhalt der Tabellen der KIX Datenbank leeren:

for TABLE in $(mysql -h <Datenbank Host> -u kix --password=<Passwort> kix17 --skip-column-names -e 'SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA="kix17" AND TABLE_TYPE="BASE TABLE"';); do mysql -h <Datenbank Host> -u kix --password=<Passwort>  kix17 -e "SET FOREIGN_KEY_CHECKS=0; DROP TABLE $TABLE; SET FOREIGN_KEY_CHECKS=1;"; done

Leeren der Views:

for VIEW in $(mysql -h <Datenbank Host> -u kix --password=<Passwort>  kix17 --skip-column-names -e 'SELECT TABLE_NAME FROM INFORMATION_SCHEMA.VIEWS WHERE TABLE_SCHEMA="kix17"';); do mysql -h <Datenbank Host> -u kix --password=<Passwort> kix17 -e "DROP VIEW $VIEW"; done

Die Kennwörter und der Datenbank Host müssten auf Ihr System angepasst werden.

Hinweis: Bei diesen Vorgang erscheint folgende Meldung auf der Eingabe Konsole:

[Warning] Using a password on the command line interface can be insecure.
Diese kann jedoch ignoriert werden.


Jetzt kann das Restore Script mit folgenden Befehl ausgeführt werden:

perl /opt/kix/scripts/restore.pl -b /<Pfad zur Backup Datei>/ -d /opt/kix/

Auch hier müssten wieder die Pfade angepasst werden.


Abschluss des Restores:

Das Passwort der Datenbank muss in der Config.pm mit dem vorher notierten ersetzt werden.

Den Cache leeren und den Webserver neu starten:

    • sudo -u www-data /opt/kix/bin/kix.Console.pl Maint::Cache::Delete
    • sudo -u www-data /opt/kix/bin/kix.Console.pl Maint::Loader::CacheCleanup
    • sudo -u www-data /opt/kix/bin/kix.Console.pl Maint::Config::Rebuild
    • service apache2 restart


Viele Grüße, Tino Voigt