Collabora CODE-Updateprüfungen und unerwünschte Verbindungen deaktivieren

Um zu verhindern, dass Collabora Online Development Edition (CODE) die geplante Versionsprüfung durchführt, setzen Sie die entsprechenden Einstellungen fetch_update_checkauf „true 0“ und allow_update_popup„false“ false. Bei einer Bereitstellung, die keine nicht genehmigten externen Dienste kontaktieren darf, deaktivieren Sie außerdem nicht verwendete Integrationen und erzwingen Sie eine ausgehende Zulassungsliste am Netzwerkrand. Das Ausblenden von Update-Benachrichtigungen allein blockiert den Netzwerkverkehr nicht.

Wissen, was Sie deaktivieren

Collaboras coolwsd.xml.inDokumentation vom Oktober 2026 sieht ein Aktualisierungsprüfungsintervall von 10 Stunden und eine separate Steuerung für Aktualisierungsbenachrichtigungen vor. Es gibt keine universelle Option zum Deaktivieren der Telemetrie. Aktualisierungsanfragen, optionale Cloud-gestützte Bearbeitung, lokale Diagnoseprotokolle und die notwendige WOPI-Verbindung zu einem Dokumentenspeicherserver sind unterschiedliche Dinge. Werden sie als eine einzige Einstellung behandelt, können Verbindungen entweder aktiv bleiben oder die Dokumentenbearbeitung beeinträchtigt werden.

Diese Anweisungen gelten primär für eine eigenständige collabora/codeDocker-Bereitstellung. Paketinstallationen verwenden dieselben Konfigurationskonzepte, erfordern jedoch in der Regel eine Bearbeitung /etc/coolwsd/coolwsd.xmlund einen Neustart des coolwsdDienstes. Bei integrierten CODE-Installationen, die von einem anderen Produkt verwaltet werden, können die Startoptionen neu generiert werden; ändern Sie diese daher im verwaltenden Produkt, anstatt temporäre Dateien zu patchen.

1. Laufende Einstellungen ermitteln und eine Wiederherstellungskopie erstellen

Ermitteln Sie zunächst, ob Ihr CODE-Dienst über Docker Compose, einen docker runBefehl oder ein natives Paket konfiguriert ist. Untersuchen Sie bei Docker den Container und seine aktuelle Umgebung, ohne die Ausgabe öffentlich zu posten, da Umgebungsvariablen Anmeldeinformationen enthalten können.

docker ps --format 'table {{.Names}}	{{.Image}}'
docker inspect --format '{{range .Config.Env}}{{println .}}{{end}}' code

Ersetzen Sie dies codedurch Ihren tatsächlichen Containernamen. Speichern Sie coolwsd.xmlvor der Änderung eine sichere Kopie der Bereitstellungsdatei oder der vorhandenen Datei. Falls Ihre Compose-Konfiguration bereits TLS-Terminierung, WOPI-Host-Zulassungen oder Authentifizierungsparameter enthält, behalten Sie diese Werte bei.

2. Deaktivieren Sie die Verbindung für regelmäßige Aktualisierungen.

Für Docker Compose

Fügen Sie diese Optionen dem vorhandenen extra_paramsWert unter dem Block Ihres CODE-Dienstes hinzu environment. Dies ist ein Fragment, keine vollständige Ersetzung der Compose-Datei:

services:
  code:
    environment:
      extra_params: >-
        --o:fetch_update_check=0
        --o:allow_update_popup=false

Führen Sie die beiden Flags mit vorhandenen extra_paramsFlags zusammen, anstatt sie zu überschreiben. Erstellen Sie anschließend nur den CODE-Dienst mit docker compose up -d --no-deps --force-recreate codeIhrem tatsächlichen Compose-Dienstnamen neu. docker runFügen Sie bei einer Bereitstellung dieselben Optionen der extra_paramsUmgebungsvariablen hinzu, wenn Sie den Container neu erstellen.

Für Linux-Pakete

Bearbeiten /etc/coolwsd/coolwsd.xml. Suchen Sie die vorhandenen Elemente und ändern Sie deren Werte, wobei die ursprünglichen Attribute erhalten bleiben:

<fetch_update_check>0</fetch_update_check>
<allow_update_popup>false</allow_update_popup>

Falls die vorhandenen Elemente Attribute enthalten, behalten Sie diese bei und ändern Sie nur die Textwerte. Prüfen Sie vor dem Neustart, ob die Datei gültiges XML ist; verwenden Sie beispielsweise `src`, xmllint --noout /etc/coolwsd/coolwsd.xmlfalls xmllint`src` installiert ist. Starten Sie den Computer mit `src` neu sudo systemctl restart coolwsd.

Wichtig: allow_update_popup=false Unterdrückt die Update-Benachrichtigung des Editors; es handelt sich nicht um eine Ausstiegskontrolle. Die fetch_update_check=0Einstellung betrifft die geplante Überprüfung. Ihre Organisation muss Sicherheitsupdates weiterhin im Rahmen ihres normalen Wartungsprozesses verfolgen.

3. Deaktivieren Sie optionale Dienste, die andere Hosts kontaktieren können.

Überprüfen Sie die aktive Konfiguration für Remote-Integrationen. In der aktuellen Upstream-Konfiguration ist das Remote-Korrekturlesen mit LanguageTool oder Duden standardmäßig deaktiviert. Auch die serverweiten KI- und DeepL-Optionen sind standardmäßig deaktiviert. Ein Administrator oder eine Integration kann diese aktiviert haben. Falls diese Optionen in Ihrer installierten CODE-Version vorhanden sind, lassen Sie sie deaktiviert, wenn Sie sie nicht benötigen.

--o:languagetool.enabled=false
--o:ai.enabled=false
--o:deepl.enabled=false

Berücksichtigen Sie nur die von Ihrer installierten Version unterstützten Optionen und führen Sie diese zusammen, extra_paramsanstatt einen zweiten, möglicherweise in Konflikt stehenden Wert zu erstellen. Dieselben Effekte lassen sich in den entsprechenden Abschnitten `<configuration>` <languagetool>, `<configuration> <ai>` und `<configuration>` <deepl>einer nativen XML-Installation konfigurieren.

Prüfen Sie die Einträge remote_config.remote_url, remote_font_config.urlbevor Sie sie löschen. Eine leere Remote-Konfigurations-URL verhindert das Abrufen der optionalen Konfiguration; eine Remote-Schriftart-URL kann legitim auf Ihre eigene Nextcloud-Installation verweisen. Das Entfernen dieser URL kann die Dokumenttypografie beeinträchtigen. Behalten Sie sie daher bei, wenn der Schriftartendienst genehmigt und erforderlich ist. Prüfen Sie außerdem alle konfigurierten Monitoring-WebSocket-Adressen und zusätzliche Plugins, wie z. B. einen Zitatmanager, entsprechend den Anforderungen Ihrer Bereitstellung.

Die Protokollierung ist ein separates Datenschutzthema und kein Beweis für externe Telemetriedaten. Überprüfen Sie die Dokumentation, logging.docstatswenn Sie lokale Kennungen in der Diagnose einschränken möchten. Protokollieren Sie ausreichend Sicherheits- und Betriebsdaten, um Vorfälle zu beheben; eine Änderung der Protokollierungsstufe blockiert keine ausgehenden Verbindungen.logging.userstatslogging.anonymize.anonymize_user_data

4. Ausgehenden Datenverkehr einschränken, ohne WOPI zu beeinträchtigen

Eine reine Konfigurationsänderung kann unerwartete ausgehende Verbindungen nicht vollständig ausschließen. Platzieren Sie CODE hinter einer Firewall oder einem Egress-Proxy, der die für Ihre Bereitstellung erforderlichen Ziele und Ports zulässt. Dies umfasst in der Regel Ihren genehmigten WOPI-Speicherhost, alle internen Schriftarten- oder Identitätsdienste, die Sie tatsächlich verwenden, sowie die erforderliche Infrastruktur wie internes DNS. Blockieren Sie andere Internetziele, einschließlich nicht genehmigter Update-Endpunkte, für die CODE-Workload.

Deaktivieren Sie die Netzwerkverbindung nicht unbedacht und stellen Sie das Docker-Netzwerk nicht auf „false“ ein internal: true. Je nach Ihrer Architektur kann dies verhindern, dass CODE seinen WOPI-Server erreicht oder dass erforderliche Integrationen funktionieren. Beachten Sie außerdem, dass der Browser des Benutzers Editorressourcen lädt und Anfragen unabhängig vom CODE-Server stellen kann; Server-Firewall-Regeln regeln den Browser nicht.

Bei Docker Engine-Installationen mit iptables-Backend dokumentiert Docker die DOCKER-USERChain als vorgesehenen Ort für Administrator-Weiterleitungsregeln. Mit dem nftables-Backend sollten Sie eine separate Basis-Chain implementieren, anstatt von DOCKER-USEReiner vorhandenen auszugehen. Entwerfen Sie Regeln für Ihr tatsächliches Bridge- oder Containernetzwerk, IPv4 und IPv6, DNS, Verbindungsstatus und legitimen WOPI-Verkehr; eine generische, eingefügte DROPRegel kann die Bearbeitung offline erschweren. Beachten Sie die Docker-Dokumentation zu iptables und nftables, bevor Sie Richtlinien durchsetzen.

5. Überprüfen Sie die Änderungen, einschließlich der tatsächlichen Netzwerkaktivität.

Nach einem Neustart oder der Neuerstellung eines Containers sollten Sie die Startprotokolle auf Konfigurationsfehler überprüfen und das Öffnen, Bearbeiten und Speichern eines Dokuments über die normale Speicherintegration testen. Ein reagierender Editor allein beweist nicht, dass alle nicht genehmigten Anfragen gestoppt wurden. Überprüfen Sie die laufenden Startparameter und analysieren Sie anschließend die DNS- und ausgehenden Verbindungsprotokolle Ihrer Firewall, Ihres Egress-Proxys oder Ihres Containernetzwerks während des Startvorgangs und der Dokumentbearbeitung.

docker logs --since 10m code
# Check configured flags without exposing unrelated environment secrets:
docker inspect --format '{{range .Config.Env}}{{println .}}{{end}}' code | grep '^extra_params='

Bei nativen Installationen verwenden sudo journalctl -u coolwsd --since '10 minutes ago'und prüfen Sie das lokale XML. Öffnen Sie im Browser die Entwicklertools und überprüfen Sie den Netzwerk-Tab beim Öffnen eines Dokuments. Unterscheiden Sie Anfragen an Ihre eigenen CODE- und WOPI-Hosts von Anfragen an Drittanbieter.

Erfolgskriterien: CODE lädt und speichert Dokumente normal; die Aktualisierungsprüfung ist deaktiviert; optionale Cloud-Integrationen bleiben deaktiviert, sofern sie nicht explizit genehmigt werden; und die Netzwerküberwachung zeigt während des Beobachtungszeitraums nur zulässige Ziele an. Falls das Laden von Dokumenten nach der Filterung des Datenverkehrs fehlschlägt, überprüfen Sie die gesperrten Ziele vorübergehend anhand der Liste der genehmigten WOPIs und der Infrastruktur, anstatt die TLS-Zertifikatsprüfung zu deaktivieren oder den ausgehenden Datenverkehr uneingeschränkt zu öffnen.

Primäre Referenzen: Die von Collabora bereitgestellte Serverkonfigurationsvorlage , die Nextcloud All-in-One CODE-Containerkonfiguration und die offizielle Beschreibung des CODE-Docker-Images . Diese Dokumente beschreiben die relevanten Einstellungen und Bereitstellungsmuster; sie ersetzen jedoch keine Netzwerkprüfung Ihrer spezifischen Installation.