Anmerkung: (Ende 2024) Diese Dokumentseite ist sehr veraltet, sollte aber dennoch einen gewissen Wert haben - insbesondere wenn ein TKLBAM-Backup auf eine deutlich neuere TurnKey-Version migriert wird.

Bitte sehen Sie sich die TKLBAM-Dokumente für allgemeinere und aktuellere TKLBAM-Informationen. Unterstützung bekommen Seite für Optionen und Informationen, wenn Sie mehr maßgeschneiderte und aktuelle Unterstützung benötigen.

Es gab einige signifikante Änderungen in Debian Jessie (auf dem TurnKey Linux v14.x basiert) gegenüber früheren Versionen. Diese Seite soll einen allgemeinen Überblick und einige Informationen zu einigen gemeinsamen Themen geben, die nicht erschöpfend sind und auf die Sie möglicherweise stoßen.

Wenn Sie seltsame Dinge nach der Migration von einer früheren Version von TKL zu v14.x haben, dann posten Sie bitte auf der Support Foren und jemand wird mit dabei sein, um ASAP zu helfen. Hub Benutzer (oder) AWS Marktplatz Abonnent) dann zögern Sie bitte auch, unser Support-Portal auszuprobieren (zugänglich, wenn Sie im Hub angemeldet sind.

Es wird vorgeschlagen, dass Sie diese ganze Seite durchlesen, bevor Sie beginnen. Vorgeschlagener Workflow oder Semimanual/Stagnierte TKLBAM MigrationSo oder so, Sie werden wahrscheinlich noch einige machen müssen Manuelle Anpassungen für spezifische Software.

Vorgeschlagener Migrationsworkflow

Es wird vorgeschlagen, dass Sie von älteren (pre v14.x) Versionen von TurnKey in einem gestaffelten Prozess migrieren, so etwas wie dieses:

Beachten Sie die spezifischen Punkte, wie sie am Ende dieser Seite beschrieben sind.
Audit wiederhergestellte Daten auf einem neuen Server - überprüfen Sie, was funktioniert und was nicht.
Beheben Sie Probleme, die in Ihrem Audit festgestellt wurden, und dokumentieren Sie, während Sie gehen.
Machen Sie die letzte Migration.

1. Erstmalige Wiederherstellung und Prüfung

Es wird empfohlen, dass Sie Ihren Produktionsserver (woher Ihr Backup stammt) nicht berühren, bis die Migration abgeschlossen ist und Sie zu 100% zufrieden sind.

Überprüfen Sie zunächst, ob Ihr letztes Backup relativ neu ist. Angenommen, Sie haben innerhalb des letzten Monats keine wesentlichen Änderungen an Ihrem Appliance vorgenommen; ein Backup innerhalb dieses Zeitrahmens sollte für unsere ursprünglichen Zwecke ausreichen. Stellen Sie dann Ihre Daten auf einem Einweg-Testserver (z. B. einer lokalen VM oder einem neuen AWS-Server usw.) wieder her und führen Sie eine vollständige Überprüfung durch. Sobald Sie das Audit abgeschlossen haben, nehmen Sie sich etwas Zeit, um etwas über alles zu recherchieren, mit dem Sie nicht vertraut sind.

Bei der Suche nach Dokumentationen / Hinweisen zu bestimmten Themen ist Google in der Regel Ihr Freund. Denken Sie daran, dass unter der Haube TurnKey auf Debian aufgebaut ist, also gilt im Allgemeinen auch für Debian. v14.x basiert auf Debian Jessie alias Debian 8.

Bitte beachten Sie, dass, wenn Appliances Software enthält, die von vorgelagerten installiert wird (z.B.) TurnKey installiert WordPress direkt von WordPress selbst, so dass normalerweise die gesamte Anwendung in Ihrem Backup enthalten ist. Wenn Sie also Ihre v13.0 WordPress-Site migrieren (geben wir vor, dass WordPress v3.2 ausgeführt wird) auf eine v14.2 WordPress Appliance, werden Sie immer noch die alte Version der Software ausführen. Mit anderen Worten, obwohl TurnKey v14.2 mit WordPress v4.4 geliefert wird, wird Ihre alte 3.2-Site sie überschreiben.

Da die meisten unserer Appliances LAMP-basiert sind, verwende ich PHP als Beispiel, aber dies gilt im Allgemeinen auch für andere Software. Wenn Sie von v13.x kommen und die Software nicht aktiv aktualisiert haben, sollten die meisten PHP-Anwendungen, die auf v13.x laufen, immer noch in Ordnung sein, da der Unterschied zwischen PHP in v13.x (PHPv5.4) und v14.x (PHPv5.6) sind nicht zu signifikant. Es besteht jedoch die Möglichkeit, dass ältere Software, die unter v13.x gut lief, auf v14.x ein bisschen fehlerfrei ist oder vielleicht überhaupt nicht funktioniert.

Wenn die von Ihnen verwendete Software auf der neueren Version von PHP (oder welcher Sprache/Plattform auch immer) nicht ordnungsgemäß unterstützt wird, müssen Sie möglicherweise auch die Software selbst aktualisieren (z.B. WordPress). Auch wenn Sie dies nicht brauchen, möchten Sie vielleicht auf eine neuere Version aktualisieren. Neuere Versionen enthielten oft neue Funktionen und laufende Sicherheitskorrekturen.

Wenn Sie Software von Drittanbietern von Upstream aktualisieren, ist das erste, was Sie tun müssen, das Lesen der Dokumente. Projekte bieten (fast) immer Migrationsanweisungen oder Skripte von einer Version zur anderen. Bevor Sie etwas tun, lohnt es sich, alle relevanten Dokumentationen zu lesen, die Sie finden können. Sofern Sie während Ihres Audits keine Probleme haben, empfehle ich Ihnen im Allgemeinen, die Aktualisierung der Software von Drittanbietern einen zusätzlichen Schritt später durchzuführen, anstatt sie jetzt anzugehen ...

2. Bearbeitung von Problemen, die bei der Prüfung festgestellt wurden

Wenn du etwas schlimmer machst oder die Dinge unordentlich werden (z.B. wenn du etwas verschlimmerst, wenn du etwas verschlimmerst, wenn du etwas verschlimmerst, wenn du etwas verschlimmerst, wenn du etwas verschlimmerst, wenn du etwas verschlimmerst, wenn du etwas verschlimmerst, wenn du etwas verschlimmerst, wenn du etwas verschlimmerst, wenn du etwas verschlimmerst, wenn du etwas verschlimmerst, wenn du etwas verschlimmerst, wenn du etwas verschlimmerst, wenn du etwas verschlimmerst, wenn du etwas verschlimmerst, wenn du etwas verschlimmerst, wenn du etwas verschlimmerst, wenn du etwas verschlimmerst, wenn du etwas verschlimmerst, was dir nicht gefällt). Trial and Error ohne saubere Auflösung), dann können Sie einfach Ihren Testserver wegwerfen und erneut mit einer neuen Wiederherstellung beginnen (zu einem neuen Server, wenn Sie Dinge zu viel kaputt gemacht haben.

Stellen Sie sicher, dass Sie alles dokumentieren, was Sie tun, insbesondere Dinge, die funktionieren. Versuchen Sie, sich auf ein Problem nach dem anderen zu konzentrieren und arbeiten Sie weiter, bis jede Lösung abgeschlossen ist. Wenn Sie am Ende ein neues, unabhängiges Problem beginnen, das Sie bereits vollständig gelöst haben (was keine Konsequenzen für andere Probleme hat), müssen Sie nicht erneut angewendet werden Alle Probleme, die Sie teilweise gelöst haben oder die erneut behoben werden müssen (um andere Probleme aufzudecken, die Sie noch angehen müssen), können mit Ihren Dokumenten als Referenz wiederholt werden.

3. Endgültige Migration

Sie haben alle in Ihrem Audit aufgedeckten Probleme durchgearbeitet und ihre Lösung dokumentiert. Zurück auf Ihrem Produktionsserver, wo relevant und möglich; legen Sie ihn in den "Wartungsmodus" oder sperren Sie ihn anderweitig (damit keine neuen Inhalte hinzugefügt werden).

Stellen Sie Ihr neues Backup auf einen neuen Server wieder her. Folgen Sie Ihren Dokumenten, um die Migration abzuschließen, damit alles gut funktioniert. Nehmen Sie es aus dem "Wartungsmodus" (usw.).

Sobald Sie 100% zufrieden sind, dann tun Sie alle letzten Tweaks (z.B. konfigurieren DNS auf die neue Maschine zuzuordnen usw.), um es in Produktion zu setzen und eine vollständige TKLBAM-Backup Ihres neuen Servers zu tun:

tklbam-backup --full-backup now

Wenn Sie bereit sind, können Sie den alten Server zerstören. Beachten Sie, dass einige den alten Server für eine Weile laufen lassen, nur für den Fall. Auch wird empfohlen, dass, bevor Sie den Server zerstören; innerhalb des Hubs "max Backups" auf 1 setzen und ein endgültiges vollständiges Backup erzwingen. Dadurch werden alle vorherigen Backups gelöscht und Sie erhalten ein endgültiges Legacy-Backup für Archiv- / historische Zwecke.

TKLBAM semimanuelle/gestaffelte Migration

Wenn Sie eine Idee haben, wo sich die wichtigen Dateien befinden, die Sie wiederherstellen müssen, ist eine gute Alternative eine manuelle (oder halbmanuelle) Wiederherstellung. Das kann Dinge kurzschließen und auf lange Sicht weniger Arbeit bedeuten, ist ideal für die Migration von sehr alten Servern oder stark angepassten oder besonders komplexen Setups. TKLBAM kann jedoch immer noch eine sehr nützliche Möglichkeit sein, Ihre Daten auf den neuen Server zu übertragen und den Prozess halbmanuell und nicht vollständig manuell zu gestalten. Es ist immer noch ratsam, einen etwas ähnlichen Workflow zu befolgen, der dem entspricht, was oben angegeben.

Anstatt jedoch eine vollständige Wiederherstellung durchzuführen, führen Sie einfach einen Download und Dump durch:

mkdir /tklbam-dump
tklbam-restore BACKUP_ID --raw-download=/tklbam-dump

Verwendung tklbam-restore, können Sie weiterhin bestimmte Teile Ihres Backups mit dem --limits= Um z.B. alle /var/www/ und es ist Inhalt, plus eine MySQL-Datenbank namens 'DATABASE_1', aber keine Pakete, können Sie diese Zeile verwenden:

tklbam-restore /tklbam-dump --skip-packages --limits="/var/www mysql:DATABASE_1"

Alternativ Pakete zu überspringen und alles wiederherstellen, außer /etc (und es ist Inhalt) und /boot (und es ist Inhalt), verwenden Sie diese Zeile:

tklbam-restore /tklbam-dump --skip-packages --limits="-/etc -/boot"

Bitte sehen Sie sich die tklbam-Wiederherstellung Man Page für weitere Infos.

Wenn Sie etwas brechen, können Sie mit tklbam-Wiederherstellungs-RollbackBitte beachten Sie, dass TKLBAM nur einen Rollback speichert. Es ist also am besten, alles, was Sie brauchen/wollen, auf einmal wiederherzustellen. Eine gute Option kann sein, bei jedem Schritt des Prozesses manuell TKLBAM-Backups dieses neuen Servers zu erstellen.

Sie können auch Dateien aus dem /tklbam-dump-Verzeichnis manuell wiederherstellen, wenn Sie möchten. Die heruntergeladenen Dateien sollten sich an Orten befinden, die relativ zum Download-Verzeichnis sind. Dateien, die von /var/www sollte gefunden werden in /tklbam-dump/var/wwwBitte beachten Sie, dass standardmäßig Berechtigungen beim manuellen Verschieben von Dateien nicht beibehalten werden, so dass Berechtigungsanpassungen erforderlich sein können.

In jedem Fall müssen Sie immer noch entscheiden, was Sie bewegen und was nicht, aber es kann eine manuelle Migration ein wenig einfacher machen. Es wäre sicherlich einfacher, als eine vollständige manuelle Migration durchzuführen!

Spezifische Software

Webmin (alle Appliances)

Ab v14.0 ist Webmin jetzt hinter dem Tunnel versteckt, was bedeutet, dass Sie, wenn Sie von einer früheren Version wiederherstellen, einige Änderungen vornehmen müssen, bevor Webmin wieder funktioniert. In der Webmin Server-Konfigurationsdatei (/etc/webmin/miniserv.conf) stellen Sie sicher, dass Sie diese Einträge haben (fügen Sie sie hinzu oder ändern Sie sie gegebenenfalls):

port=10000
ssl=
listen=10000
inetd_ssl=1
bind=127.0.0.1
sockets=
no_resolv_myname=0
ipv6=0

Überprüfen Sie auch, ob die Tunnelkonfiguration (/etc/stunnel/stunnel.conf) hat dies (höchstwahrscheinlich am Ende):

[webmin]
accept  = 12321
connect = 127.0.0.1:10000

Wenn Sie SSL-Zertifikate für Webmin (und/oder Webshell) konfiguriert haben, müssen Sie höchstwahrscheinlich auch den Tunnel konfigurieren, um sie stattdessen zu verwenden. Passen Sie die Zeilen in /etc/stunnel/stunnel.conf an, die dies sagt:

cert = /etc/ssl/private/cert.pem

Apache (inc LAMP und etwa 70% der Bibliothek)

Apache config hat einige signifikante Änderungen gehabt, obwohl diejenige, die Dinge brechen wird, tatsächlich TurnKey verwandt ist. Wir haben das SSL in v14.0 gehärtet und den Standard-Zertifikatsspeicherplatz verschoben.

Der einfachste Weg, das wichtigste Problem zu vermeiden, ist, die ssl.conf-Datei von Apache von Ihrer Wiederherstellung auszuschließen.

tklbam-restore --limits="-/etc/apache2/mods-available/ssl.conf"

Wenn Sie ein CA-Zertifikat eines Drittanbieters haben, sollte dies Sie nicht betreffen (obwohl Sie Ihr Zertifikat verschieben können, wenn Sie dies wünschen). Wenn Sie selbst signierte Zertifikate verwenden, entfernen Sie einfach den Verweis auf das alte Zertifikat aus Ihren Apache-Vhost-Site-Dateien (in /etc/apache2/sites-available) sollte der Trick gemacht werden. z.B. Hier ist das Update in Aktion auf dem Trac Appliance.

Es gibt auch andere Änderungen, die wahrscheinlich vorgenommen werden sollten (obwohl Apache immer noch ohne sie funktionieren sollte).

Mehr Infos:

Apache-Dokumente: https://httpd.apache.org/docs/2.4/upgrading.html
Toller Beitrag zu Digital Ocean: https://www.digitalocean.com/community/tutorials/migrating-your-apache-c...

MySQL

Nichts von Bedeutung sollte sich in Bezug auf MySQL geändert haben, so dass erwartet wurde, dass die Mehrheit der Benutzer in Ordnung sein wird. Bug in PHPMyAdmin, haben wir auf die leichtere MySQL Web UI umgestellt; Adminer.

Sie können gerne mit PHPMyAdmin fortfahren, wenn Sie es vorziehen, aber Sie müssen den Adminer deaktivieren und PHPMyAdmin optimieren, um ein Unterverzeichnis zu verwenden. https://YOUR_DOMAIN.COM/phpmyadmin (d.h. als Unterverzeichnis Ihrer Website und nicht über einen bestimmten Port).

Darüber hinaus (ich glaube nicht, dass es verwandt ist, aber nicht sicher) haben einige Benutzer berichtet, dass ihr MySQL-Root-Passwort nach der Wiederherstellung nicht funktioniert. Das kann leicht zurückgesetzt werden, indem der MySQL-Inithook erneut ausgeführt wird:

/usr/lib/inithooks/bin/mysqlconf.py

Fileserver

Samba ist von v3.x in allen vorherigen Versionen von TKL zu v4.1/v4.2 in v14.x gegangen, also wieder einige signifikante Änderungen. Ein hilfreiches Community-Mitglied hat die wichtigsten Probleme gelöst und eine klare Gliederung in den Foren veröffentlicht Hier.

Der Dateizugriff WebUI hat sich ebenfalls geändert. Leider müssen Benutzerkonten, die Sie möglicherweise in der alten Version des Fileservers WebUI eingerichtet haben, möglicherweise neu erstellt werden. OTOH die neue WebUI verwendet Samba-Benutzer, so dass bestehende Benutzer sie automatisch mit ihrem bestehenden Konto und Passwort verwenden können.

MediaWiki

Ab v14.2 wird MediaWiki direkt von den Entwicklern installiert (anstatt eines Debian-Pakets). Anweisungen für die Migration von v14.1 nach v14.2 sind dokumentiertEs gibt keine bestätigten Anweisungen für frühere Versionen, aber sie sollten sehr ähnlich sein.