Désactiver les vérifications de mise à jour du code Collabora et les connexions indésirables

Pour empêcher Collabora Online Development Edition (CODE) d'effectuer sa vérification de version planifiée, définissez les paramètres fetch_update_checksur `true` 0et allow_update_popup`false` false. Pour un déploiement qui ne doit pas contacter de services externes non approuvés, désactivez également les intégrations inutilisées et appliquez une liste blanche sortante au niveau du réseau ; masquer les notifications de mise à jour ne suffit pas à bloquer le trafic réseau.

Sachez ce que vous désactivez

En octobre 2026, coolwsd.xml.inla documentation de Collabora mentionnait un intervalle de vérification des mises à jour de 10 heures et une option distincte pour les notifications de mise à jour. Elle ne mentionnait pas de paramètre unique permettant de désactiver la télémétrie. Une demande de mise à jour, l'édition assistée par le cloud (optionnelle), les journaux de diagnostic locaux et la connexion WOPI indispensable à un serveur de stockage de documents sont des éléments distincts. Les considérer comme un seul et même paramètre peut soit maintenir les connexions actives, soit interrompre l'édition des documents.

Ces instructions concernent principalement un collabora/codedéploiement Docker autonome. Les installations de paquets utilisent les mêmes concepts de configuration, mais nécessitent généralement la modification /etc/coolwsd/coolwsd.xmlet le redémarrage du coolwsdservice. Les installations CODE intégrées et gérées par un autre produit peuvent régénérer les options de lancement ; il est donc préférable de les modifier dans le produit gestionnaire plutôt que de modifier des fichiers temporaires.

1. Identifiez les paramètres en cours et conservez une sauvegarde.

Commencez par déterminer si votre service CODE est configuré via Docker Compose, une docker runcommande ou un package natif. Dans le cas de Docker, examinez le conteneur et son environnement actuel sans publier la sortie, car les variables d'environnement peuvent contenir des informations d'identification.

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

Remplacez ` code<nom_du_conteneur>` par le nom réel de votre conteneur. Avant toute modification, conservez une copie sécurisée du fichier de déploiement ou du fichier existant coolwsd.xml. Si votre configuration Compose inclut déjà la terminaison TLS, les autorisations d'hôtes WOPI ou des paramètres d'authentification, conservez ces valeurs.

2. Désactiver la connexion de mise à jour périodique

Pour Docker Compose

Ajoutez ces options à la extra_paramsvaleur existante sous le bloc de votre service CODE environment. Il s'agit d'un extrait, et non d'un fichier Compose complet :

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

Fusionnez les deux options avec les extra_paramsoptions existantes au lieu de les écraser. Recréez ensuite uniquement le service CODE en docker compose up -d --no-deps --force-recreate codeutilisant le nom réel de votre service Compose. Lors du docker rundéploiement, incluez les mêmes options dans la extra_paramsvariable d'environnement lors de la recréation du conteneur.

Pour les paquets Linux

Modifier /etc/coolwsd/coolwsd.xml. Repérez les éléments existants et modifiez leurs valeurs en conservant leurs attributs d'origine :

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

Si les éléments existants contiennent des attributs, conservez-les et modifiez uniquement leurs valeurs textuelles. Vérifiez que le fichier est un XML valide avant de redémarrer ; par exemple, utilisez la commande `git add` xmllint --noout /etc/coolwsd/coolwsd.xmlsi xmllint`git add` est installé. Redémarrez en utilisant `git add` sudo systemctl restart coolwsd.

Important : allow_update_popup=false désactive la notification de mise à jour de l’éditeur ; il ne s’agit pas d’un contrôle de sortie. Ce fetch_update_check=0paramètre concerne la vérification planifiée. Votre organisation doit toujours assurer le suivi des mises à jour de sécurité via son processus de maintenance habituel.

3. Désactivez les services optionnels qui peuvent contacter d'autres hôtes.

Vérifiez la configuration active des intégrations distantes. Dans la configuration amont actuelle, la correction d'épreuves à distance avec LanguageTool ou Duden est désactivée par défaut, de même que les options d'IA et de DeepL au niveau du serveur. Il est possible qu'un administrateur ou une intégration les ait activées. Si ces options sont présentes dans votre version de CODE installée, laissez-les désactivées si vous n'en avez pas besoin.

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

N'incluez que les options prises en charge par votre version installée et fusionnez-les extra_paramsplutôt que d'ajouter une seconde valeur conflictuelle. Les mêmes effets peuvent être configurés dans les sections correspondantes <languagetool>d' <ai>une <deepl>installation XML native.

Vérifiez remote_config.remote_url-les remote_font_config.urlavant de les supprimer. Une URL de configuration distante vide évite la récupération de cette configuration optionnelle ; une URL de police distante peut légitimement pointer vers votre propre installation Nextcloud. La supprimer peut affecter la typographie du document ; conservez-la donc si le service de polices est approuvé et requis. Examinez également les adresses WebSocket de surveillance configurées et les plugins supplémentaires, tels qu'un gestionnaire de citations, en fonction des besoins de votre déploiement.

La journalisation soulève des questions de confidentialité distinctes et ne constitue pas une preuve de télémétrie externe. Consultez les ressources suivantes logging.docstatssi logging.userstatsvous logging.anonymize.anonymize_user_datasouhaitez limiter les identifiants locaux dans les diagnostics : [insérer les ressources ici]. Conservez suffisamment de journaux de sécurité et d'exploitation pour le dépannage des incidents ; la modification du niveau de détail des journaux n'empêche pas les connexions sortantes.

4. Limiter le trafic sortant sans enfreindre le WOPI

Une simple modification de la configuration ne peut garantir l'absence de connexions sortantes inattendues. Placez CODE derrière un pare-feu ou un proxy de sortie autorisant les destinations et les ports spécifiques requis par votre déploiement. En général, cela inclut votre serveur de stockage WOPI approuvé, les services de polices ou d'identité internes que vous utilisez, ainsi que l'infrastructure nécessaire, comme votre DNS interne. Bloquez les autres destinations Internet, y compris les points de terminaison de mise à jour non approuvés, pour la charge de travail CODE.

Ne désactivez pas le réseau sans raison valable et ne configurez pas le réseau Docker de manière à ce qu'il ne fonctionne pasinternal: true : selon votre architecture, cela pourrait empêcher CODE d'accéder à son serveur WOPI ou perturber le fonctionnement des intégrations requises. N'oubliez pas non plus que le navigateur de l'utilisateur charge les ressources de l'éditeur et peut effectuer des requêtes indépendamment du serveur CODE ; les règles du pare-feu du serveur ne s'appliquent pas au navigateur.

Pour les installations de Docker Engine utilisant iptables, Docker indique que la DOCKER-USERchaîne `iptables` est l'emplacement prévu pour les règles de redirection administrateur. Avec nftables, il est recommandé de créer une chaîne de base distincte plutôt que de supposer DOCKER-USERson existence. Concevez des règles adaptées à votre réseau de ponts ou de conteneurs, aux protocoles IPv4 et IPv6, au DNS, à l'état de la connexion et au trafic WOPI légitime ; une DROPrègle générique copiée-collée peut rendre la modification impossible hors ligne. Consultez la documentation Docker relative à iptables et à nftables avant d'appliquer une politique de redirection.

5. Vérifier les modifications, y compris l'activité réelle du réseau

Après un redémarrage ou une recréation de conteneur, examinez les journaux de démarrage pour détecter les erreurs de configuration et testez l'ouverture, la modification et l'enregistrement d'un document via l'intégration de stockage standard. Un éditeur réactif ne garantit pas à lui seul l'arrêt de toutes les requêtes non autorisées. Vérifiez les paramètres de démarrage en cours, puis consultez les journaux DNS et de connexions sortantes de votre pare-feu, de votre proxy de sortie ou de votre réseau de conteneurs pendant le démarrage et la modification du document.

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='

Sur les installations natives, utilisez sudo journalctl -u coolwsd --since '10 minutes ago'et examinez le code XML local. Côté navigateur, ouvrez les outils de développement et consultez l'onglet Réseau lors de l'ouverture d'un document. Distinguez les requêtes adressées à vos hôtes CODE et WOPI de celles adressées à des destinations tierces.

Critères de réussite : CODE charge et enregistre les documents normalement ; l’option de vérification des mises à jour est désactivée ; les intégrations cloud optionnelles restent désactivées sauf autorisation explicite ; et la surveillance réseau n’affiche que les destinations autorisées pendant la période d’observation. Si le chargement des documents échoue après le filtrage du trafic, vérifiez temporairement les destinations refusées par rapport à la liste WOPI et à l’infrastructure approuvées, plutôt que de désactiver la vérification des certificats TLS ou d’autoriser la sortie sans restriction.

Références principales : le modèle de configuration serveur maintenu par Collabora , la configuration du conteneur Nextcloud All-in-One CODE et la description officielle de l’image Docker CODE . Ces documents présentent les paramètres et les modèles de déploiement pertinents ; ils ne remplacent pas un audit réseau de votre installation spécifique.