Comment configurer les délais d'inactivité pour les sessions d'édition Collabora

Collabora Online propose plusieurs paramètres qui ressemblent à un « délai d'inactivité », mais ils contrôlent des comportements différents. Si un éditeur s'assombrit ou cesse de se mettre à jour pendant qu'un utilisateur travaille, ajustez le paramètre d'inactivité par vue. Si un document reste chargé après le départ de tous les utilisateurs, ajustez le délai d'expiration par document. Si l'éditeur se déconnecte, vérifiez le délai d'expiration WebSocket du proxy inverse avant de modifier la politique d'inactivité de Collabora.

Le modèle de configuration actuel de Collabora Online prévoit un délai d'inactivité de 15 minutes par vue, de 5 minutes lorsque l'onglet du navigateur n'est pas au premier plan, et d'une heure avant le déchargement d'un document inactif. Ces valeurs par défaut peuvent varier selon la version et le package ; il est donc conseillé de vérifier la configuration fournie avec votre version installée avant d'apporter des modifications. Les valeurs ci-dessous se réfèrent au modèle utilisé dans ce guide et ne constituent pas une garantie pour tous les déploiements CODE ou d'entreprise.

Choisissez le paramètre en fonction du comportement souhaité.

Collabora documente la signification et les valeurs par défaut des options dans son modèle de configuration coolwsd et sa documentation de référence . Un délai d'inactivité par vue est différent de la fermeture d'un compte ou de la révocation d'un accès : il assombrit la vue et interrompt les mises à jour. Un délai d'inactivité par document interrompt le processus du document inactif ; il ne s'agit pas d'un minuteur qui doit interrompre l'activité d'un utilisateur en cours d'édition.

Points de départ recommandés

• Pour éviter que les onglets actifs des utilisateurs ne s'assombrissent trop rapidement : augmentez per_view.idle_timeout_secsl'intervalle par rapport à la valeur par défaut et choisissez une durée mesurée, par exemple 1 800 secondes (30 minutes). Il s'agit d'un point de départ pratique, et non d'une recommandation universelle.
• Autorisez les utilisateurs à changer d'onglet tout en conservant un document ouvert : augmentez le délai per_view.out_of_focus_timeout_secsséparément. N'augmentez pas ce délai simplement parce que les utilisateurs sont inactifs dans un onglet actif.
• Réduisez l'utilisation de la mémoire après l'abandon des documents : ne modifiez pas les valeurs par vue et envisagez de les abaisser per_document.idle_timeout_secs, après avoir confirmé que le document est effectivement inactif et que les sauvegardes de stockage sont saines.
• Pour résoudre une déconnexion différée : vérifiez le délai d’expiration WebSocket du proxy, du serveur d’entrée ou de l’équilibreur de charge. Modifier le paramètre de gradation par vue ne résoudra pas un problème de connexion WebSocket interrompue par le proxy.
• Conservez les sauvegardes fréquentes : laissez les valeurs de sauvegarde en veille et de sauvegarde automatique à leurs valeurs actuelles, sauf si vous avez une raison particulière de les modifier.

Modifiez les paramètres dans coolwsd.xml

Pour une installation par paquet, repérez le coolwsd.xmlfichier actif utilisé par le service en cours d'exécution. Les emplacements courants incluent ` /etc/coolwsd/coolwsd.xml/etc/services/lib/services`, mais les chemins varient selon les distributions et les versions antérieures. Ne présumez pas que la modification d'un fichier de test ou d'une copie montée inutilisée modifie le service en cours d'exécution.

Sauvegardez le fichier actif, puis modifiez uniquement les valeurs pertinentes dans les sections existantes <per_view>. <per_document>Par exemple, cet extrait configure un délai d'inactivité de 30 minutes pour l'utilisateur, un délai d'expiration de 15 minutes pour les onglets en arrière-plan et un déchargement des documents inactifs après deux heures :

<per_view>
    <idle_timeout_secs>1800</idle_timeout_secs>
    <out_of_focus_timeout_secs>900</out_of_focus_timeout_secs>
</per_view>
<per_document>
    <idle_timeout_secs>7200</idle_timeout_secs>
</per_document>

Ceci est un extrait, et non une configuration de remplacement complète. Conservez les attributs, commentaires, imbrications et autres éléments du fichier fourni avec votre version ; certaines versions requièrent des attributs XML supplémentaires. Si vous souhaitez modifier la luminosité uniquement lorsque l’onglet est actif, modifiez uniquement la valeur de veille par vue. Augmenter simultanément les valeurs par vue et la valeur de déchargement du document complique l’identification du paramètre à l’origine du problème.

Validez le fichier XML à l'aide des outils de configuration fournis avec votre déploiement, puis redémarrez ou rechargez Collabora en suivant la méthode documentée pour ce package. Consultez les journaux de démarrage pour détecter les erreurs d'analyse de la configuration et vérifiez que le processus en cours a bien chargé le fichier prévu. Toute modification de paramètre absente du processus actif sera sans effet.

Configurez les mêmes options dans Docker ou Kubernetes

Dans l'image Docker de Collabora, les administrateurs transmettent généralement les options de configuration via extra_paramsla --o:syntaxe `option`. L'exemple suivant, de type Compose, illustre ce même principe :

extra_params=--o:per_view.idle_timeout_secs=1800 --o:per_view.out_of_focus_timeout_secs=900 --o:per_document.idle_timeout_secs=7200

N'utilisez cette méthode que si votre image et votre graphique de déploiement le permettent extra_params. Pour Kubernetes, Helm ou une installation gérée par un opérateur, indiquez les options dans le champ de configuration pris en charge du graphique ou de la ressource personnalisée plutôt que de modifier un fichier de conteneur généré. Lorsque vous modifiez des variables d'environnement dans Compose, recréez ou redéployez le service pour que les nouvelles valeurs soient prises en compte par le conteneur ; un simple redémarrage peut réutiliser la configuration existante du conteneur.

Ne définissez pas la même option à des endroits conflictuels, comme dans un fichier XML monté et comme paramètre d'environnement, sans vérifier les règles de priorité de cette version. Après le redéploiement, examinez les journaux de démarrage du conteneur et la configuration active. Le dépôt source du projet Collabora et la documentation de déploiement correspondant à la version sont les références appropriées en cas de différences dans les noms d'options ou le comportement du conteneur.

Vérifier séparément les délais d'expiration du proxy inverse

L'éditeur de Collabora utilise les WebSockets pour la communication continue avec le navigateur. Un proxy peut interrompre une connexion WebSocket pourtant valide, même si les délais d'expiration des documents et de l'affichage Collabora sont beaucoup plus longs. Dans ce cas, les utilisateurs peuvent voir une déconnexion, une invite de reconnexion, ou l'éditeur cesser de recevoir des mises à jour, au lieu d'un simple affichage grisé.

Comparez les délais d'expiration de lecture/envoi du proxy, les délais d'inactivité des serveurs d'entrée ou des équilibreurs de charge cloud, et le comportement de session prévu par Collabora. Ces délais doivent être compatibles sur l'ensemble du chemin. Le guide de configuration des proxys de Collabora inclut des exemples de configuration de proxy WebSocket et de connexions persistantes. Appliquez les recommandations correspondant à votre proxy et à votre version ; ne copiez pas aveuglément un ancien bloc Nginx dans un autre proxy ou sur un chemin non pertinent.

Un indice utile est le schéma de défaillance. Si les utilisateurs voient seulement l'écran d'inactivité s'assombrir, examinez les per_viewjournaux. Si tous les utilisateurs se déconnectent à peu près au même moment, consultez les journaux du proxy et de l'équilibreur de charge à cet horodatage. Si un document ne se ferme qu'après le départ de tous les participants, le délai d'expiration par document est plus pertinent.

Tester un délai d'attente à la fois

1. Enregistrez les valeurs actuelles de la configuration active et notez votre version de Collabora ainsi que votre méthode de déploiement.
2. Ouvrez un document de test avec deux utilisateurs ou deux sessions de navigateur afin de pouvoir observer une vue active et une vue inactive.
3. Modifiez uniquement le délai d'attente correspondant au problème. Par exemple, pour éviter l'assombrissement de la luminosité dans un onglet actif mais silencieux, ajustez per_view.idle_timeout_secsuniquement la valeur correspondante.
4. Redémarrez ou redéployez via la méthode prise en charge, puis vérifiez que la nouvelle valeur apparaît dans la configuration active ou les journaux de démarrage.
5. Attendez au-delà du seuil précédent. Vérifiez si l'affichage s'assombrit toujours, si le deuxième utilisateur reçoit toujours les mises à jour et si les modifications continuent d'être enregistrées.
6. Fermez toutes les vues du document de test et observez si le document inactif se décharge dans la plage prévue.
7. Consultez les journaux de Collabora et du proxy pour détecter les fermetures WebSocket, les erreurs d'analyse XML, les échecs d'enregistrement ou les nettoyages de processus inattendus.

Ne testez pas la modification sur un document de production non enregistré. Assurez-vous que les fichiers modifiés sont bien enregistrés dans le système de stockage avant de laisser un processus de document inactif se terminer. Si le problème ne se manifeste qu'avec des modifications non enregistrées, vérifiez les erreurs d'enregistrement automatique et de stockage séparément, plutôt que d'allonger systématiquement le délai d'expiration.

Concilier commodité, utilisation des ressources et fiabilité

Des délais d'expiration plus longs pour chaque vue conviennent aux équipes qui consultent des documents par intermittence ou qui travaillent sur plusieurs onglets. Des valeurs plus courtes peuvent accélérer l'arrêt de la mise à jour des vues inactives, ce qui peut réduire l'activité en arrière-plan, mais risque d'interrompre un lecteur qui consulte encore le document. Le délai d'expiration par document est un paramètre de gestion des ressources distinct : l'allonger permet de conserver plus longtemps les documents inutilisés chargés, tandis que le raccourcir peut nécessiter un nouveau chargement lorsque l'utilisateur revient.

Pour la plupart des déploiements, modifiez le minimum de paramètres nécessaires pour reproduire le comportement observé. Conservez les intervalles d'enregistrement, définissez une durée d'inactivité raisonnable par vue pour l'équipe, maintenez le délai d'expiration des onglets en arrière-plan et ajustez les limites WebSocket du proxy uniquement si les journaux ou les temps de réponse indiquent un problème de connexion. Après les mises à niveau, vérifiez à nouveau le modèle de configuration de la version installée, car les valeurs par défaut et les paramètres pris en charge peuvent changer.