Startseite
» Gewusst wie
»
Collabora CODE-Einstellungen wiederherstellen, ohne Bereitstellungsänderungen zu verlieren
Collabora CODE-Einstellungen wiederherstellen, ohne Bereitstellungsänderungen zu verlieren
Ein Collabora CODE-Container kann nach einem Neuaufbau mit Standardeinstellungen neu gestartet werden, oder ein Serverausfall kann dazu führen, dass keine funktionierende Kopie der Konfiguration mehr vorhanden ist. Sichern Sie daher die aktiven coolwsd.xmlDateien und die Bereitstellungsdateien, die die Einstellungen enthalten. Stellen Sie diese am selben persistenten Speicherort wieder her und überprüfen Sie anschließend die Datei und den Dienst, bevor die Benutzer die Bearbeitung fortsetzen.
Die Hauptdatei ist üblicherweise /etc/coolwsd/coolwsd.xml. Die maßgebliche Quelle unterscheidet sich je nach Installationsart (Paket, Docker oder Helm). Ermitteln Sie daher die jeweilige Bereitstellung, bevor Sie etwas kopieren.
1. Ermitteln Sie die aktive Konfigurationsquelle
Bei der Installation eines Pakets sollte die Host-Datei überprüft werden. Unter Docker ist die Datei im laufenden Container zu prüfen, um festzustellen, ob eine Host-Datei oder ein Verzeichnis darüber eingebunden ist. Auch Compose-, referenzierte Umgebungs- oder Helm-Werte müssen beibehalten werden: Die dort angegebenen Startoptionen werden nicht unbedingt in XML gespeichert.
sudo ls -l /etc/coolwsd/coolwsd.xml
docker ps --format 'table {{.Names}}\t{{.Image}}\t{{.Status}}'
docker exec collabora-code ls -l /etc/coolwsd/coolwsd.xml
Ersetzen Sie collabora-code<Containername> durch Ihren tatsächlichen Containernamen. Die Konfigurations- und Docker-Dokumentation von Collabora beschreiben diese Bereitstellungspfade, und das zugehörige Helm-Chart stellt Einstellungen auf Chart-Ebene bereit. Lesen Sie die Dokumentation für Ihre Version; Standardwerte und das Bereitstellungsverhalten können sich zwischen den Versionen ändern.
Die aktive Konfigurationsdatei befindet sich üblicherweise unter /etc/coolwsd/coolwsd.xml.
2. XML- und Bereitstellungsdateien sichern
Speichern Sie eine datierte Kopie in einem geschützten Verzeichnis. Die Konfiguration kann zulässige WOPI-Hosts, das Proxy-Verhalten, Zertifikatspfade oder administrative Einstellungen offenlegen. Behandeln Sie die Sicherung als sensible Betriebsdaten.
Bei der Paketinstallation müssen die Metadaten der Dateien erhalten bleiben:
sudo install -d -m 700 /var/backups/collabora/$(date +%F)
sudo cp -a /etc/coolwsd/coolwsd.xml \
/var/backups/collabora/$(date +%F)/coolwsd.xml
sudo stat /var/backups/collabora/$(date +%F)/coolwsd.xml
Für Docker kopieren Sie die Live-Datei aus dem Container auf den Host:
Wenn eine Bind-Mount-Datei die Datei bereitstellt, sichern Sie auch deren Quelldatei auf dem Host. Diese Datei kann Änderungen im Container beim Neustart überschreiben. Bewahren Sie die Compose-Datei und alle referenzierten .envDateien im selben geschützten Backup-Set auf. Speichern Sie für Helm die exakte Wertedatei und die Release-Identität sowie separat verwaltete Secrets oder ConfigMaps mithilfe Ihres bestehenden Secret-Handling-Prozesses.
Eine Compose-Datei kann persistente Mounts deklarieren und sollte zusammen mit der aktiven Konfiguration gesichert werden.
3. Stellen Sie sicher, dass das Backup reproduzierbar ist.
Notieren Sie das CODE-Image-Tag oder die Paketversion, den Containernamen, die Mount-Quelle und das Sicherungsdatum. Paketinstallationen können cp -adie Metadaten sichern. Die Dateiberechtigungen im Container können von denen des Hosts abweichen. Gehen Sie daher nicht davon aus, dass ein Host-Eigentümer oder -Modus für jede Image-Version geeignet ist.
Prüfen Sie für Compose, ob eine Datei oder ein ganzes Verzeichnis eingebunden ist /etc/coolwsd. Eine Verzeichniseinbindung kann im Image enthaltene Dateien verbergen; ein unvollständiges Verzeichnis kann dazu führen, dass erwartete Dateien nicht verfügbar sind. Sichern Sie alle Dateien im eingebundenen Verzeichnis, auf die CODE angewiesen ist. Bewahren Sie Umgebungseinstellungen separat auf und schützen Sie vertrauliche Informationen.
Bei Helm sollten Sie sich nicht darauf verlassen, einen generierten Pod zu bearbeiten: Upgrades können ihn neu erstellen. Bewahren Sie die Chart-Werte sowie alle externen Secrets oder ConfigMaps auf. Das Upstream-Chart von Collabora unterstützt Konfigurationsinhalte über Werte, daher ist seine deklarierte Quelle möglicherweise maßgebender als eine Kopie aus einem laufenden Pod.
Überprüfen Sie die Konfigurationsquelle, die Umgebungseinstellungen und den Dienststatus als separate Teile der Wiederherstellung.
4. Wiederherstellung an der persistenten Quelle
Stoppen Sie CODE oder nutzen Sie ein Wartungsfenster. Speichern Sie die aktuelle Datei, bevor Sie sie ersetzen. Stellen Sie bei der Installation eines Pakets die ausgewählte Sicherung wieder her und behalten Sie die vom Paket erwarteten Besitzrechte und Berechtigungen bei.
Der Beispielbesitzer und die Gruppe stimmen möglicherweise nicht mit Ihrem Paket überein. Überprüfen Sie die vorhandene Datei statund behalten Sie die erwarteten Besitzverhältnisse und Zugriffsrechte bei, anstatt Beispielwerte unreflektiert zu übernehmen. Stellen Sie bei einem per Bind-Mount eingebundenen Container die Host-Datei wieder her und folgen Sie Ihrem Workflow für einen Neustart oder eine Neuerstellung mit Compose. Wenn ein benutzerdefiniertes Image oder ein Helm-Wert die Konfiguration bereitstellt, aktualisieren Sie diese Quelle und stellen Sie den Container erneut bereit; Änderungen an einem temporären Container werden nicht beibehalten.
Überprüfen Sie die Konfiguration, bevor Sie sie nach einem Versionswechsel wiederherstellen. Optionen können sich zwischen den Versionen ändern. Vergleichen Sie daher die gespeicherte Datei mit der Vorlage und den Migrationshinweisen der Zielversion. Durch die Wiederherstellung von XML werden Zertifikate, private Schlüssel, benutzerdefinierte Schriftarten oder die Reverse-Proxy-Konfiguration nicht wiederhergestellt, es sei denn, diese wurden separat gesichert.
Die gewünschte datierte Kopie soll über ihren persistenten Host oder ihre Bereitstellungsquelle wiederhergestellt werden.
5. Vor dem erneuten Öffnen der Bearbeitung überprüfen.
Prüfen Sie, ob die Datei existiert, vom Dienst lesbar ist und wohlgeformtes XML darstellt. Falls installiert, xmllintprüfen Sie die Syntax:
xmllint --noout /etc/coolwsd/coolwsd.xml
Dies bestätigt lediglich die XML-Syntax; es beweist nicht, dass Ihre CODE-Version alle Optionen unterstützt. Überprüfen Sie die Protokolle auf Syntaxfehler und stellen Sie sicher, dass der Dienst weiterhin ausgeführt wird. Prüfen Sie bei Containern docker compose psdie aktuellen Protokolle. Prüfen Sie bei Paketen systemctl status coolwsddas Systemjournal.
Öffnen Sie abschließend ein Dokument über den üblichen WOPI-Host und prüfen Sie, ob es geladen und gespeichert wird. Falls CODE startet, Dokumente aber nicht geladen werden können, vergleichen Sie die wiederhergestellte Zulassungsliste, den externen Hostnamen, die TLS-Terminierung und die Proxy-Einstellungen mit der Bereitstellung. Sollte der Start fehlschlagen, stellen Sie die Version vor der Wiederherstellung wieder her und vergleichen Sie die Dateien, bevor Sie es erneut versuchen.
Bitte prüfen Sie, ob die Sicherungsversion und die Bereitstellungsversion übereinstimmen.
Prüfen Sie, ob die Mount- oder Helm-Werte auf die wiederhergestellte Quelle verweisen.
Bestätigen Sie, dass die XML-Analyse und der Dienststart erfolgreich waren.
Testen Sie das Öffnen und Speichern über die verbundene Speicherplattform.