L’équipe du projet Debian a publié le 10 juin 2023 la douzième version de sa distribution : Debian 12 Bookworm. Comme d’habitude, je ne suis pas très en avance, et je n’ai toujours pas mis à jour la moindre de mes machines vers cette nouvelle version, ni même créé de modèle de machine en version 12. Je vais donc passer ici ma première machine vers Bookworm; c’est la machine qui héberge mon cloud perso basé sur nextcloud qui va y passer.
Comme je suis chaud, je vais en profiter pour mettre à jour mon nextcloud de la version 25 vers la version 27.
Suite à la mise à jour de ma bonne vieille instance Nextcloud vers la version 21, j’ai noté que les tâches cron n’étaient plus exécutées. Cependant, à part cette alarme, il n’y avait pas de problème particulièrement bloquant de remonté par l’auto-diagnostique de l’application.
En creusant un peu, on voit qu’en fait, il y a un problème avec l’utilitaire php occ, qui génère l’erreur ci-dessous dès qu’on l’invoque:
sudo -u www-data php occ maintenance:mode --on
PHP Warning: Module 'apc' already loaded in Unknown on line 0
An unhandled exception has been thrown:
OC\HintException: [0]: Memcache \OC\Memcache\APCu not available for local cache (Is the matching PHP module installed and enabled?)
Vouloir s’auto-héberger peut paraître un peu à contre courant des modes actuelles. En effet, une écrasante majorité des personnes utilise massivement les plateformes cloud des grandes entreprises de l’internet. Pour les quelques autres qui souhaitent disposer de leur propre cloud personnel, les plupart se tournent vers des serveurs dédiés ou mutualisés chez de grands fournisseurs. Cet article n’a pas pour objet de discuter du pourquoi il faudrait héberger (ou louer) son cloud perso (de très bons articles en parlent déjà) mais de donner un exemple de comment auto-héberger son cloud perso. La solution logicielle qui sera utilisée est Nextcloud.
En effet, le projet Nextcloud distribue un package de la version communautaire du serveur OnlyOffice Document Server, installable en un clic, mais c’est une version orientée tests. En conséquence, il est déconseillé d’utiliser ce package pour de la production, même si c’est juste pour un petit cloud perso. Perso ne veut pas dire pas fiable ou de mauvaise qualité. De plus, dans certaines situations, il n’est pas possible d’utiliser ce package, par exemple quand la plateforme qui fait tourner l’instance Nextcloud n’est pas 64 bits. Dans ce cas, il faut en venir à réaliser sur une machine dédiée l’installation d’un serveur OnlyOffice Document Server pour l’associer à une instance Nextcloud qui tourne sur une autre machine.
Le but ici sera bien sûr de pouvoir utiliser l’éditeur en ligne de documents bureautique de OnlyOffice Document Server directement depuis l’interface web de Nextcloud.
L’installation va se faire sur un serveur motorisé par Debian Buster.
Dans l’optique de migrer l’instance de nextcloud 15 de mon petit auto-hébergement perso vers la version 16, afin de maximiser les chances de réussite, il est préférable de corriger tous les avertissements remontés dans le panel administrateur. Parmi ceux-ci, il peut y avoir le message suivant, demandant de changer le charset des tables avec mariadb.
MySQL est utilisée comme base de données mais ne supporte pas les caractères codés sur 4 octets. Pour pouvoir manipuler les caractères sur 4 octets (comme les émoticônes) sans problème dans les noms de fichiers ou les commentaires par exemple, il est recommandé d’activer le support 4 octets dans MySQL.
Il semble que ce message aurait du apparaître depuis longtemps, mais il se trouve que sur cette instance il n’est apparu que récemment.
Debian GNU/Linux est la distribution qui a ma préférence pour les machines linux de mon micro-datacenter. La sortie d’une nouvelle version est toujours une bonne nouvelle, et c’est récemment que la version 9 (Stretch) de Debian a quitté la branche stable pour passer oldstable, en laissant la place à la version 10 : Buster. C’est l’occasion d’une mise à jour de Debian Stretch vers Buster
L’expérience d’une mise à niveau d’une version de Debian vers la suivante est très variable d’un cas à l’autre, suivant la configuration initiale (environnement de bureau ou pas, services réseau avec un niveau minimal de technologie de chiffrement, interpréteur de langage de programmation qui n’accepte plus certaines fonctionnalités anciennes ne sont que quelques points de surveillance parmi tant d’autres…).
Dernièrement je me suis aperçu que suite à une mise à jour, mon instance de nextcloud essayait de m’expliquer que la configuration de l’auto-découverte des ressources avec nextcloud n’était pas bien configurée.
Les url /.well-known/caldav et /.well-known/cardav sont inaccessibles…
Ce service de découverte s’appuie sur des redirections : le client qui ne connaît que le nom d’hôte du serveur nextcloud requête alors les url suivantes : https://nom_du_serveur/.well-known/caldav et https://nom_du_serveur/.well-known/carddav . Quand c’est correctement configuré, le serveur renvoie un 301 accompagné du bon chemin pour accéder aux ressources de l’utilisateur.
Nextcloud est livré en standard avec un fichier .htaccess contenant les directives nécessaires aux redirections, mais ça ne fonctionne que si nextcloud est à la racine du serveur web.
