AccueilTechniqueServices → Nextcloud

    Nextcloud

    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.

    Fonctionnement🔗

    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.

    Historique🔗

    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.

    Installation🔗

    Notre installation Nextcloud est séparée en 6 composantes interdépendantes :

    • La base de données PostgreSQL, que nous mutualisons avec nos autres services ;
    • Le cache Redis dont Nextcloud possède une instance dédiée ;
    • Le serveur FPM qui traite toutes les requêtes de manière dynamique ;
    • Le serveur HTTP, qui sert les ressources statiques et fait le lien avec notre reverse-proxy ;
    • Le sidecar Cron qui exécute les tâches récurrentes de Nextcloud ;
    • Le serveur Collabora dédié à l’édition de documents de manière collaborative.

    Pour l’installation de l’instance PostgreSQL et du cache Redis, nous vous invitons à consulter la documentation officielle de Nextcloud.

    Serveur FPM🔗

    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.

    Serveur HTTP🔗

    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.

    Sidecar Cron🔗

    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.

    Serveur Collabora🔗

    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.

    Tests🔗

    À 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.

    Statistiques d’utilisation🔗

    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éeRequêtesUtilisateur·ice·s uniquesBande passante
    20203 1939520 MB
    202115 1165938 MB
    202214 7318128 MB
    202324 75713777 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 :

    ConteneurConsommation de RAM
    nextcloud-fpm360 MB
    nextcloud-cron32 MB
    nextcloud-redis22 MB
    nextcloud-nginx86 MB
    collabora712 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.

    Précautions🔗

    Chiffrement des fichiers🔗

    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.

    Consommation de l’espace disque🔗

    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.

    Entretien🔗

    Hormis les mises à jour régulières, Nextcloud en lui-même ne nécessite que très peu d’entretien.

    Usage de RAM et rapidité🔗

    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.

    Applications🔗

    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.

    Nextcloud Mail : suppression des comptes invalides🔗

    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.

    Mise à jour🔗

    Nextcloud : version mineure🔗

    La mise à jour de Nextcloud vers une version mineure est assez triviale. Voici un guide étape par étape :

    1. Arrêter le conteneur nextcloud-cron ;
    2. Récupérer de la nouvelle image depuis DockerHub docker pull ;
    3. Reconstruire les images nextcloud-cron et nextcloud-fpm ;
    4. Redémarrer le conteneur nextcloud-fpm et surveiller les logs du conteneur.
    5. Si tout s’est bien passé et que Nextcloud est sorti du mode maintenance, redémarrer le conteneur nextcloud-cron.

    Pendant les mises à jour mineures, il arrive parfois que Nextcloud exécute un occ upgrade, ce qui peut prendre plusieurs minutes.

    Nextcloud : version majeure🔗

    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.

    Nextcloud : 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é.

    Infra V3: Nextcloud multitenant🔗

    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 :

    • le cache (Redis) ;
    • la BDD PostgreSQL ;
    • le reverse-proxy (Caddy) ;
    • le dossier d’installation ;
    • le serveur de données (S3, Garage), un bucket par instance.

    Elle ne partage pas :

    • la configuration ;
    • le serveur PHP-FPM ;
    • le sidecar Cron.

    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:upgrade --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…).

    Infra V3: Installer un nouveau Nextcloud🔗

    1. S’assurer que l’enregistrement DNS A (et éventuellement AAAA) soient bien configurés pour être utilisés sur le sous-domaine final (les migrations, c’est pénible).
    2. Sur la machine dédiée à l’hébergement des instances Nextcloud, créer le volume dédié à la configuration du nouveau Nextcloud : dv create local-nextcloud-{client}-config
    3. Éditer le script start.sh de l’image nextcloud-init et modifier le nom du volume de configuration
    4. Préparer les variables d’environnement runtime.env de l’image nextcloud-init. Commenter les lignes suivantes :
      • POSTGRES_DB
      • POSTGRES_USER
      • POSTGRES_PASSWORD
      • OBJECTSTORE_S3_BUCKET
      • OBJECTSTORE_S3_HOST (si besoin ; a minima vérifier l’adresse)
      • OBJECTSTORE_S3_KEY
      • OBJECTSTORE_S3_SECRET
      • NEXTCLOUD_TRUSTED_DOMAINS
      • …et éventuellement d’autres valeurs si besoin.
    5. Configurer Garage :
      • (Si besoin, créer une nouvelle instance de Garage, mais cela ne devrait pas être nécessaire.)
      • Créer un bucket {client}-nextcloud
      • Créer une clé {client}-nextcloud-key
      • Donner un accès RWO de cette clé sur le bucket
      • Ajouter un quota correspondant au service souscrit
    6. Ajouter les clés du bucket créé dans le runtime.env de nextcloud-init
    7. Configurer PostgreSQL :
      • Créer une nouvelle base de données et un nouveau compte
      • Ajouter le compte créé dans pg_hba.conf avec la bonne IP de connexion (calculer la bonne IP à définir en fonction des autres instances Nextcloud)
      • Exécuter SELECT pg_reload_conf();
      • Renseigner les informations de connexion à la DB dans le runtime.env
    8. Changer les IP dans le start.sh de nextcloud-init
    9. Définir les IP dans la configuration de Caddy et recharger Caddy ;
    10. Lancer brièvement le conteneur nextcloud-init pour que le Nextcloud s’initialise
    11. Faire un vimdiff sur la configuration du Nextcloud local-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.
    12. Dans le dossier du service nextcloud-fpm-orga, créer {client}.compose.yml, {client}.buildtime.env, {client}.runtime.env. Importer le contenu de {client}.runtime.env depuis nextcloud-init
    13. Lancer le conteneur Nextcloud : manager start nextcloud-fpm-orga {client}
    14. Tenter de se connecter dans l’interface admin de Nextcloud avec /login?direct=1 et les identifiants admin
      • Vérifier que la configuration est valide dans les options de l’UI, ajouter les éventuels index manquants
    15. Choisir la cron système dans les options de l’UI Nextcloud
    16. Créer {client}.compose.yml et {client}.buildtime.env dans nextcloud-cron-orga à partir des autres Nextcloud
    17. Activer et désactiver les bonnes applications dans l’UI Nextcloud (utiliser une autre installation de Nextcloud comme référence)
    18. Activer l’app Collabora Office et configurer une instance Collabora :
      • Ajouter l’URL de l’instance comme hôte autorisé dans les paramètres de Collabora
      • Vérifier que personne n’utilise l’instance (ou attendre) et redémarrer Collabora
      • Tester Collabora Office depuis un nouveau fichier créé sur le Nextcloud
    19. Configurer Keycloak :
      • Créer l’organisation {client} si elle n’existe pas déjà
      • Créer le client OAuth en se basant sur les autres clients Nextcloud
      • Créer le groupe {client}
      • Créer le sous-groupe {client}/nextcloud
      • [restrict-client-auth] Créer le rôle client restricted-access
      • Ajouter le rôle restricted-access au sous-groupe {client}/nextcloud
      • Créer le scope client realm-name-nextcloud-{client} et hardcoder le realm name en nom de groupe en imitant la configuration des autres instances Nextcloud
      • Ajouter le scope client au client Nextcloud par défaut
    20. Activer l’application OpenID Connect sur Nextcloud
      • Configurer l’app de la même manière qu’un autre Nextcloud
      • Utiliser un compte Keycloak sans privilèges pour essayer de se connecter sans le groupe requis (accès refusé attendu), puis avec le bon groupe
      • S’assurer que l’accès fonctionne bien, que l’utilisateur·ice peut créer des fichiers et dossiers, que son pseudonyme s’affiche bien dans l’interface
    21. Créer un dossier de groupe avec le compte admin, au nom de la structure, en autorisant le groupe {client} à y avoir accès, avec un quota correspondant à la souscription
    22. Fin. Sur Keycloak, créer les utilisateur·ices (si ce n’est pas déjà fait), leur envoyer un lien pour réinitialiser le mot de passe et leur informer que le Nextcloud est prêt.

    Collabora🔗

    Le 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.

    Autres mises à jour🔗

    Pour les mises à jour du serveur HTTP et du cache Redis, un simple redémarrage du conteneur mis à jour suffit.

    Évolutions envisagées🔗

    Utilisation de Nextcloud AIO🔗

    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.

    Augmentation de la limite d’espace disque🔗

    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.