Nextcloud est une suite logicielle collaborative développée par l’entreprise allemande Nextcloud GmbH. Elle constitue une alternative libre et open-source à la Google Suite et propose de nombreuses applications : stockage de fichiers (drive), édition collaborative de documents, création de formulaires, sondages, gestion d’agenda et d’autres fonctionnalités.
Nextcloud propose un catalogue d’applications créées par la communauté et installables en un clic par l’administrateur·ice. Ces applications proposent généralement des fonctionnalités conçues pour le travail en collaboration ou l’organisation personnelle.
Nous proposons un compte par personne et un compte spécial « organisation » pour les personnes morales qui souhaiteraient utiliser notre service.
Notre service Nextcloud est réservé à nos membres pour des raisons d’espace disque.
Le service Nextcloud a été inauguré le 24 décembre 2019 en utilisant initialement la variante apache de l’image Nextcloud officielle. Depuis 2020, nous utilisons la variante fpm pour des raisons de performance.
Notre installation Nextcloud est séparée en 6 composantes interdépendantes :
Pour l’installation de l’instance PostgreSQL et du cache Redis, nous vous invitons à consulter la documentation officielle de Nextcloud.
Notre serveur FPM utilise l’image library/nextcloud, variante XX-fpm (XX correspondant à la version majeure de Nextcloud). Cette image est légèrement modifiée pour y ajouter quelques paramètres PHP destinés à améliorer les performances du service. Notre Dockerfile est disponible sur le dépôt Core.
Il utilise plusieurs volumes : les assets statiques et fichiers PHP sont stockés en local sur notre serveur de calcul, tandis que les données des utilisateur·ice·s sont stockées sur un volume NFS.
Le serveur HTTP reçoit les requêtes depuis le reverse-proxy. Il répond directement aux requêtes de fichiers statiques, et redirige les requêtes pour des routes PHP vers le serveur FPM avec l’instruction fastcgi_pass. Nous utilisons à cette fin l’image library/nginx, variante mainline-alpine.
La configuration de Nginx est disponible sur la documentation officielle de Nextcloud.
Un conteneur « sidecar » fonctionne aux côtés d’un conteneur principal afin d’exécuter une tâche spécifique. Ce conteneur execute des tâches récurrentes nécessaires au fonctionnement de Nextcloud. Il y avait plusieurs approches pour exécuter des tâches, il y avait notamment la possibilité de passer par les Webcrons ou AJAX, mais ces autres approches impactent sérieusement les performances.
Nous utilisons l’image library/nextcloud à cette fin, en activant son mode « cron » en spécifiant entrypoint: /cron.sh dans la configuration du docker-compose.
Nous devons également modifier le fichier cron.sh manuellement à cause d’un bug dû aux droits sur les fichiers (qui n’appartiennent pas à www-data) à cause de la gestion des droits sur le serveur NFS. Retrouvez notre configuration sur le dépôt Core.
Nous hébergeons une instance de Collabora avec l’image collabora/code (variante latest) pour offrir la possibilité à nos utilisateur·ices d’éditer des documents en ligne et en collaboration.
Notre instance est limitée à une utilisation simultanée de 10 documents et 20 connexions, mais il est possible de passer outre cette limite en modifiant le code. Les performances du logiciel laissent toutefois à désirer.
Nextcloud interagit avec ce serveur à l’aide de son application dédiée.
À des fins de supervision, il convient d’envoyer une requête GET sur /status.php et de vérifier les informations renvoyées.
L’interface d’administration de Collabora peut également être utile pour consulter des statistiques ou vérifier le nombre de documents ouverts. Si activée, elle est disponible à l’adresse https://<COLLABORA_INSTANCE>/browser/dist/admin/admin.html.
Consultez ci-dessous les statistiques d’utilisation du service Nextcloud de La Contre-Voie.
Il s’agit de moyennes journalières mesurées pendant la 5e semaine (calendrier ISO) de chaque année listée.
| Année | Requêtes | Utilisateur·ice·s uniques | Bande passante |
|---|---|---|---|
| 2020 | 3 193 | 95 | 20 MB |
| 2021 | 15 116 | 59 | 38 MB |
| 2022 | 14 731 | 81 | 28 MB |
| 2023 | 24 757 | 137 | 77 MB |
Contrairement à d’autres services réservés à nos membres comme Git, le service Nextcloud ne propose pas d’interface consultable par des personnes ne possédant pas de compte, hormis pour quelques liens de partage de fichiers et de sondages, ce qui explique son trafic particulièrement faible.
En date d’avril 2023, notre instance Nextcloud compte 101 utilisateur·ices dont 66 adhérent·es. Les comptes non-adhérents ont été créés pour des organisations.
Tous les comptes sont limités à 100 MB de stockage et totalisent actuellement 2.0 GB d’utilisation de l’espace disque. Les assets statiques et les fichiers système de Nextcloud, nécessaires pour faire tourner l’instance, totalisent 1.2 GB d’espace disque.
La base de données PostgreSQL utilisée par Nextcloud pèse 186 MB.
Quant aux images Docker, l’image de Nextcloud FPM et de Nextcloud cron (la même image est utilisée) pèse 990 MB, tandis que Collabora pèse 1.55 GB.
Voici la consommation de RAM respective de chaque conteneur nécessaire pour le fonctionnement du service Nextcloud en date d’avril 2023 :
| Conteneur | Consommation de RAM |
|---|---|
| nextcloud-fpm | 360 MB |
| nextcloud-cron | 32 MB |
| nextcloud-redis | 22 MB |
| nextcloud-nginx | 86 MB |
| collabora | 712 MB |
| TOTAL (sans collabora) | 500 MB |
| TOTAL (avec collabora) | 1.2 GB |
Nextcloud est donc le service qui nécessite le plus de conteneurs pour son fonctionnement et qui consomme le plus de RAM, en particulier avec l’instance Collabora. C’est aussi le service dont les fichiers système consomment le plus d’espace disque.
En cas de manque de RAM ou d’espace disque sur une machine, il est facilement possible d’externaliser le service Collabora sur une autre machine.
Nextcloud dispose d’un module qui permet de chiffrer les fichiers déposés sur le serveur avec une clé de chiffrement pour chaque compte. Cette mesure protège les fichiers d’une examination ou extraction côté serveur, bien qu’elle n’empêcherait pas un·e administrateur·ice malveillant·e d’intercepter les mots de passe d’un compte lors de la connexion (ce n’est pas du chiffrement de bout-en-bout).
Ce module entre en conflit avec plusieurs outils de travail en collaboration : l’utilisation de Collabora/OnlyOffice ou des dossiers de groupe pourrait être impossible, parmi d’autres applications. Il y a peut-être eu une évolution ces dernières années sur cette question, mais c’est ce qui nous a poussé à désactiver le chiffrement côté serveur en 2020.
La grande difficulté dans l’utilisation de ce module est son caractère assez irréversible : pour faire marche arrière, nous avons dû solliciter chacun·e de nos membres pour leur demander d’activer une option de secours dans leurs options.
Nous préférons être transparent·es sur le sujet : nous n’avons pas de chiffrement côté serveur, et nous demandons à nos utilisateur·ices de nous faire confiance sur le fait que nous ne regarderons pas leurs données, en leur proposant éventuellement de les former à l’autohébergement d’une instance pour leur usage si cette situation ne leur convient pas.
La mise en place d’un Nextcloud implique de consacrer au service une quantité assez importante d’espace disque. Il est important de faire le point sur le nombre de personnes qui peuvent être accueillies par l’infrastructure avant d’ouvrir l’instance.
Hormis les mises à jour régulières, Nextcloud en lui-même ne nécessite que très peu d’entretien.
Nextcloud est assez lent « by design » et a tendance à consommer beaucoup de RAM (by design aussi). Il est nécessaire de s’assurer que le conteneur n’atteigne pas sa limite de RAM.
La particularité de ce service porte sur ses applications, qui sont mises à jour à travers son propre gestionnaire et pas par les images Docker. Vérifier la disponibilité des mises à jour sur les applications Nextcloud est une routine d’entretien qui permet de corriger d’éventuels bugs.
Si un·e membre connecte sa boîte mail à Nextcloud à travers l’application Nextcloud Mail, puis change le mot de passe de sa boîte mail ou la supprime, Nextcloud Mail réeesayera régulièrement de s’authentifier auprès du serveur mail pour récupérer les mails (à peu près toutes les 10 minutes).
Nextcloud Mail n’abandonnera pas de se connecter au bout d’un certain nombre de tentatives, consommant ainsi d’importantes ressources pour rien, générant des erreurs dans les logs de Nextcloud et risquant fortement de bannir l’IP de Nextcloud auprès du serveur mail (ce qui ne peut arriver sur notre propre serveur, car l’IP est volontairement autorisée).
Il est nécessaire de purger ces comptes invalides à la main si l’utilisateur·ice ne le fait pas.
Pour cela, il faut suivre les étapes ci-dessous.
Pour les boîtes mail hébergées chez nous : il nous suffit de récupérer, directement dans les journaux du service mail, les adresses des boîtes pour lesquelles Nextcloud ne parvient pas à se connecter, en partant du principe que l’IP de Nextcloud n’est pas partagée avec d’autres webmails.
grep -i <NEXTCLOUD_IP> mail.log | grep failed
Pour les autres boîtes (Gmail…) : se référer aux journaux de Nextcloud, qui vont indiquer un identifiant des comptes défectueux.
Se connecter à la base de données de Nextcloud :
de postgres-db psql -U <POSTGRES_ADMIN> -p <PORT> <NEXTCLOUD_DB>
Récupérer la table des adresses email (un WHERE permet d’affiner la recherche si besoin) :
SELECT id,user_id,name,email FROM oc_mail_accounts ORDER BY id;
Cela vous permet de faire correspondre les adresses email à des identifiants de boîte mail propres à Nextcloud Mail, et inversement.
Sur le serveur de Nextcloud, diagnostiquez les boîtes mail avec l’outil OCC à partir de leur identifiant :
de nextcloud-fpm ./occ mail:account:diagnose <ACCOUNT_ID>
Si le serveur vous répond :
Horde error occurred: Too many auth attempts. See nextcloud.log for more details.
Cela signifie que cette boîte est effectivement défectueuse. Vous pouvez alors procéder à sa suppression :
de nextcloud-fpm ./occ mail:account:delete <ACCOUNT_ID>
Répétez l’opération jusqu’à ce qu’il n’y ait plus de boîtes défectueuses.
La mise à jour de Nextcloud vers une version mineure est assez triviale. Voici un guide étape par étape :
docker pull ;Pendant les mises à jour mineures, il arrive parfois que Nextcloud exécute un occ upgrade, ce qui peut prendre plusieurs minutes.
Les versions majeures de Nextcloud posent un problème de compatibilité avec toutes les applications Nextcloud installées. Le procédé est le même que pour les mises à jour mineures, mais il est nécessaire de vérifier au préalable sur apps.nextcloud.com que toutes les applications installées sont compatibles avec la prochaine version majeure.
Si cette vérification n’est pas réalisée, les applications incompatibles seront désactivées après la mise à jour. Un tour sur les tickets ouverts sur chaque application qui n’aurait pas encore reçu de mise à jour permet de connaître le statut de la mise en conformité de ces applications.
Un petit tour régulier dans l’interface d’administration de Nextcloud peut être utile pour mettre à jour les applications. Certaines subissent parfois des bugs majeurs qui ne sont résolus qu’à travers les mises à jour.
Il est préférable d’exécuter les mises à jour dans le conteneur en ligne de commande via l’outil occ pour éviter le problème des timeouts HTTP et d’obtenir plus d’informations sur une mise à jour qui aurait échoué.
Attention : cette section s’applique à une nouvelle configuration qui n’a rien à voir avec le service tel qu’il est documenté. Cette section pourra être déplacée une fois que la page correspondante sera créée.
Il est possible de partager le même dossier /var/www/html pour plusieurs installations de Nextcloud, mais ce n’est pas prévu par les développeur·euses et cela nécessite un peu de bidouillage. Cette pratique sera documentée sur une page créée ultérieurement.
Cette configuration partage entre plusieurs Nextcloud les composants suivants :
Elle ne partage pas :
Voici les instructions pour mettre à jour un Nextcloud dans ces conditions :
Passer toutes les instances en mode maintenance.
de -u 33 nextcloud-fpm-<INSTANCE_1> ./occ maintenance:mode --on
de -u 33 nextcloud-fpm-<INSTANCE_2> ./occ maintenance:mode --on
...
Mettre à jour l’instance de staging dédiée à la mise à jour avec la dernière image disponible, puis lancer l’instance de staging.
docker pull nextcloud:<VERSION>-fpm
manager image start nextcloud-upgrade
Le processus de mise à jour du dossier des ressources se lance automatiquement. Il peut être complété par la mise à jour des applications :
de -u 33 nextcloud-upgrade ./occ app:update --all
Il est préférable de mettre à jour sélectivement les applications pour éviter des mises à jour non désirées.
Sur les autres instances : lancer la mise à jour de la BDD pour Nextcloud et les applications.
de -u 33 nextcloud-fpm-<INSTANCE_1> ./occ upgrade
de -u 33 nextcloud-fpm-<INSTANCE_2> ./occ upgrade
Une fois l’opération terminée, quitter le mode maintenance pour toutes les instances.
de -u 33 nextcloud-fpm-<INSTANCE_1> ./occ maintenance:mode --off
de -u 33 nextcloud-fpm-<INSTANCE_2> ./occ maintenance:mode --off
Enfin, redémarrer les conteneurs concernés pour ne plus utiliser l’ancienne image :
manager build nextcloud-fpm
manager restart nextcloud-fpm-<INSTANCE_1>
manager restart nextcloud-fpm-<INSTANCE_2>
manager restart nextcloud-cron-<INSTANCE_1>
manager restart nextcloud-cron-<INSTANCE_2>
Un coup d’œil à la page d’administration de Nextcloud sur https://<INSTANCE_URL>/settings/admin/overview permet de s’assurer que tout fonctionne comme prévu après le redémarrage, et d’exécuter éventuellement des commandes pour effectuer des conversions manuelles dans la BDD (index manquants…).
dv create local-nextcloud-{client}-configstart.sh de l’image nextcloud-init et modifier le nom du volume de configurationruntime.env de l’image nextcloud-init. Commenter les lignes suivantes :
POSTGRES_DBPOSTGRES_USERPOSTGRES_PASSWORDOBJECTSTORE_S3_BUCKETOBJECTSTORE_S3_HOST (si besoin ; a minima vérifier l’adresse)OBJECTSTORE_S3_KEYOBJECTSTORE_S3_SECRETNEXTCLOUD_TRUSTED_DOMAINS{client}-nextcloud{client}-nextcloud-keyruntime.env de nextcloud-initpg_hba.conf avec la bonne IP de connexion (calculer la bonne IP à définir en fonction des autres instances Nextcloud)SELECT pg_reload_conf();runtime.envstart.sh de nextcloud-initnextcloud-init pour que le Nextcloud s’initialiselocal-nextcloud-{client}-config/config.php avec une configuration d’un autre Nextcloud et ajouter les options manquantes ; mettre à jour les paramètres qui devraient être identiques.nextcloud-fpm-orga, créer {client}.compose.yml, {client}.buildtime.env, {client}.runtime.env. Importer le contenu de {client}.runtime.env depuis nextcloud-initmanager start nextcloud-fpm-orga {client}/login?direct=1 et les identifiants admin
{client}.compose.yml et {client}.buildtime.env dans nextcloud-cron-orga à partir des autres Nextcloud{client} si elle n’existe pas déjà{client}{client}/nextcloudrestricted-accessrestricted-access au sous-groupe {client}/nextcloudrealm-name-nextcloud-{client} et hardcoder le realm name en nom de groupe en imitant la configuration des autres instances NextcloudLe serveur Collabora peut être mis à jour très simplement en récupérant l’image depuis DockerHub et en redémarrant le conteneur.
Il peut être judicieux de vérifier au préalable que personne n’utilise le service au moment du redémarrage en accédant à son interface d’administration et en consultant le nombre de documents ouverts, et ce afin d’éviter des pertes de données.
Pour les mises à jour du serveur HTTP et du cache Redis, un simple redémarrage du conteneur mis à jour suffit.
Une configuration de déploiement de Nextcloud nommée « All-In-One » (AIO) a été conçu par les développeur·euses et est désormais recommandée pour toute nouvelle installation de Nextcloud, plutôt que d’utiliser l’image library/nextcloud.
Cette configuration basée sur Docker est toutefois particulièrement complexe à mettre en œuvre sans donner l’accès root au socket Docker de l’hôte. Elle promet néanmoins des améliorations de performances une meilleure intégration des outils Nextcloud.
Pour l’instant, chaque utilisateur·ice dispose d’un quota de 100 Mo, avec quelques exceptions pour les personnes morales qui disposent de groupes partagés.
Il est envisagé de relever ce quota lorsque nous aurons les capacités de garantir la sauvegarde de ces données.