Suite au changement de HD sur mon NAS, j’ai été amené à réinstaller mes containers Docker. L’occasion d’en apprendre un peu sur les sauvegardes d’images que je faisais et comment les restaurer.
Pour Nextcloud, j’ai finalement décidé d’en profiter pour installer la dernière version disponible, et d’oublier l’idée d’une restauration. J’étais en v21.0.4, et c’est actuellement la v23.0.0 qui est disponible sur linuxserver.io. Allons-y pour une installation toute neuve, mais en gardant mon fichier config.php, spécifique à mon réseau.
Tout n’a pas été simple, loin de là. J’ai pu constater que l’installation avait pas mal changé depuis la première installation (v20), et que la restauration de mon dossier de configuration devait se faire plus tard, sinon l’installation bloquait ! J’ai aussi noté quelques trucs utiles en cas de problème sur les logs et l’accès à la Base de Données. Pour finir, j’ai aussi eu une erreur de type « mise à jour » ! 😡
Revoyons un peu tout ça…
Fichier CAN_INSTALL
J’ai tout d’abord repris ma « stack » de l’installation précédente, celle qui inclut nextcloud/mariadb/swag (voir cet article). J’ai juste modifié le nom des images qui avait changé dans l’exemple fournit par linuxsserver.io/nextcloud : on passait de « linuxserver/xxx » à « lscr.io/linuxserver/xxx » pour chaque composant.
J’avais aussi remarqué que pour MariaDB, il y avait trois paramètres supplémentaires : MYSQL_DATABASE, MYSQL_USER et MYSQL_PASSWORD. Mais je ne les ai pas ajoutés, ce qui m’amènera à une erreur (voir plus bas) : il est donc préférable de les ajouter à la stack de base (l’utilisateur de la base à renseigner est le nom de l’administrateur nextcloud). Bref, j’aurais tout aussi bien fait de reprendre la nouvelle stack proposée, et d’y modifier mes paramètres, que de faire l’inverse…
Pour la suite de cet article, le container MariaDB s’appelle nextclouddb (container_name dans la stack). C’est aussi le nom que je donne à la base de données lors du setup de Nextcloud.
J’ai donc déployé la nouvelle stack (avec nouvelle version des softs, au moins pour Nextcloud). Puis j’ai arrêté le container Nextcloud et recopié tout le dossier « config » de ma version précédente défini dans la stack : « /srv/dev-disk-by-label-DATA/AppData/Nextcloud/config:/config« .
Mais en relançant Nextcloud, j’ai eu un beau message sur la page du navigateur (dommage, je n’ai pas fait de capture), me disant grosso-modo:
Il semble que vous essayez de réinstaller votre Nextcloud. Cependant le fichier CAN_INSTALL est manquant dans votre répertoire de configuration. Veuillez créer le fichier CAN_INSTALL dans votre répertoire de configuration pour continuer.
Je me suis dit que j’étais sur la bonne voie, il ne restait qu’à créer un fichier CAN_INSTALL vide dans le répertoire de config. Hélas, j’ai eu beau créer ce fichier dans /srv/dev-disk-by-label-DATA/AppData/Nextcloud/config/www/nextcloud/config, impossible de finir l’installation qui restait bloquée sur cette page d’erreur.
Après quelques recherches sur le web, il semble que ce message soit un « faux ami », et n’ait en fait rien à voir avec la vraie source de l’erreur, qui serait plutôt lié à la base de donnée pas encore accessible.
Le fichier config.php
J’ai alors redéployé ma stack, mais cette fois sans recopier mon dossier config, me disant que finalement, je pouvais repartir d’une installation propre et recréer ce dont j’avais besoin facilement (je n’utilise Nextcloud que pour le partage de dossiers).
Mais je voulais tout de même réutiliser mon fichier /srv/dev-disk-by-label-DATA/AppData/Nextcloud/www/nextcloud/config/config.php (voir la première installation) pour correspondre à mon environnement réseau (les « trusted_domains » notamment, ce fichier n’est pas évident à configurer).
Et c’est là que je me suis rendu compte que le fichier config.php n’existait pas encore. Je le créais donc, mais c’était quand même inattendu !? Du coup, la page Nextcloud affichait une belle erreur « Internal Server error ».
J’ai fini par comprendre que je ne devais pas créer ce fichier config.php à ce stade (contrairement à la v20). Dès le déploiement de la stack, sans modifier quoique ce soit, la page de Nextcloud était disponible pour y fournir les informations de connexion habituelles : compte admin, infos base de données, avant de cliquer sur le bouton « Terminer l’installation ».
Ce n’est qu’une fois que l’on a fournit ces infos et cliqué sur le bouton « Terminer… » que l’installation se termine et que le fichier config.php est téléchargé, comme beaucoup d’autres fichiers d’ailleurs. Ce n’était pas le cas avec la v20, la procédure d’installation a vraiment changé depuis cette version, et la copie de fichiers semble se faire désormais en deux étapes.
Les Logs
Avant de continuer, un petit mot sur les logs. Le premier endroit à aller voir est celui du container. Soit via Portainer, soit en mode commande (nextcloud étant le nom du container) :
sudo docker logs -f nextcloud
Si l’on ne trouve rien à ce niveau (attendre parfois quelques minutes, j’ai observé des messages qui arrivaient avec un certain délai), il faut alors se tourner vers les logs Nextcloud.
Le fichier à consulter est celui-ci (dans ma config) : /srv/dev-disk-by-label-DATA/AppData/Nextcloud/data/nextcloud.log.
On peut modifier le niveau de log en allant éditer le fichier config.php mentionné plus haut. Le paramètre ‘loglevel’ est à 2 par défaut, on peut éventuellement le passer à DEBUG pour avoir le maximum d’informations (source).
Base de données
Une fois l’installation terminée, je peux enfin y copier mon fichier config.php en lieu et place de celui fournit par défaut.
Je ne sais plus trop à quel moment j’ai encore une erreur liée à la base de donnée. C’est en fait lié aux trois paramètres supplémentaires que je n’ai pas indiqué dans la stack : MYSQL_DATABASE, MYSQL_USER et MYSQL_PASSWORD. Là aussi, c’est nouveau par rapport à la v20. Et comme je ne les ai pas déclarés, Nextcloud se retrouve incapable d’accéder à la Base de Données avec l’utilisateur « pascal ». Cette fois, j’ai un message clair dans le log du container Nextcloud :
Doctrine\DBAL\Exception: Failed to connect to the database: An exception occurred in the driver: SQLSTATE[HY000] [1045] Access denied for user 'pascal'@'172.21.0.1' (using password: YES) in /config/www/nextcloud/lib/private/DB/Connection.php:87
Heureusement, la solution est assez facile pour résoudre ce problème, à savoir créer la BdD, l’utilisateur pascal et lui accorder les droits. On peut accéder à l’interface MySQL soit via la console de Portainer, soit dans un terminal avec la commande suivante :
$ pascal@odroidhc2:~$ sudo docker exec -it nextclouddb bash
[sudo] password for pascal:
root@cdd5100474d7:/#
root@cdd5100474d7:/# mysql -u root -p
Enter password:
Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MariaDB connection id is 42838
Server version: 10.5.13-MariaDB-log MariaDB Server
Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
MariaDB [(none)]>
Si l’on choisit la console Portainer du container MariaDB (appelé ici nextclouddb), on ne tape que la commande mysql bien sûr. Une fois que l’on a le prompt MariaDB on exécute les commandes suivantes :
MariaDB [(none)]> CREATE USER 'pascal' IDENTIFIED BY 'password';
MariaDB [(none)]> CREATE DATABASE IF NOT EXISTS nextclouddb;
GRANT ALL PRIVILEGES ON nextclouddb.* TO 'pascal' IDENTIFIED BY 'password';
FLUSH PRIVILEGES;
exit
Voilà, avec ces changements, l’installation de Nextcloud peut enfin se terminer correctement.
Mise à jour
Cette fois, la page d’accueil de Nextcloud s’ouvre enfin : je crois alors en avoir fini avec cette installation, mais un message m’informe qu’une mise à jour va avoir lieu… Pourquoi pas, je valide, et un message d’erreur apparaît alors :
Cette fois, j’ai tout de suite le bon réflexe : je vais voir le fameux fichier config.php que j’ai recopié de l’ancienne version (pour ma configuration réseau). Et il y a bien une ligne : 'version' => '21.0.4.1', (soit mon ancienne version Nextcloud) que je transforme tout de suite en 'version' => '23.0.0.0',.
Je rafraîchis la page et la mise à jour s’effectue alors sans problème :
Et voilà, mon nouveau Nextcloud est enfin opérationnel !! 😎
Conclusion
Cela n’a pas été sans mal, mais je suis finalement assez satisfait : j’ai appris quelques nouveaux trucs utiles : la phase d’installation en deux temps, aller voir les logs, accéder à la Base de Données… Ça peut servir dans l’avenir !
Et j’ai aussi vu que pour l’utilisation que j’en fais (partage de dossiers), une réinstallation n’est pas un gros souci. Je n’utilise aucune APP, mes contacts et calendriers sont sauvegardés d’une autre manière, etc… Recréer les dossiers de partage, et y recopier les fichiers (qui sont synchronisés sur le PC) n’est pas un problème et ne prend pas tant de temps que ça.
Je rappelle tout de même que l’on peut à priori mettre à jour son container Nextcloud assez facilement, voir cet article. J’avoue que je l’avais un peu oublié quand je me suis lancé dans ma restauration, j’aurais sans doute pu m’en inspirer et me simplifier la vie ! 😐