cClaude.rocks ☕ Le blog

Le long travail sur la plateforme est toujours en cours. Il s’agit notamment des mises à jour des serveurs gitea et Nextcloud.

Gitea

Quelques jours après la migration vers le nouveau serveur, le serveur gitea a été mis à jour avec la dernière version disponible : 1.18.5

Cela devrait corriger les derniers problèmes identifiés sur ce service.

En soit, cette mise à jour a été une formalité, entraînant une sauvegarde supplémentaire en journée et une interruption de service de moins d’une minute.

Nextcloud

La version actuelle de Nextcloud n’est plus maintenu. Il n’y aura donc plus de mise à jour, mais plus aucun changement dans les applications.

Il y a des conflits avec certaines applications Nextcloud qui gèrent mal le fait de ne pas être mise à jour. En fait, je pense que c’est Nextcloud qui gère cela mal…

Le plan de migration de Nextcloud est assez lourd, et plutôt compliqué l’automatisation.

D’abord, il y a un changement de stratégie. Depuis l’installation initiale, j’ai mis en place un système d’installation d’une base logicielle LAMP (Linux, Apache, MySQL, PHP).

C’est donc tous le code d’installation qui est à revoir.

Par ailleurs, depuis la précédente mise à jour de la base système, il s’est passé pas mal de choses sur les paquets de base.

Voici les changements en cours de réalisation:

• Suppression du compte 'pi' sur la machine, il n’est même plus créé.
• De MySQL à MariaDB.
• De PHP 7.3 à PHP 8.0, idéalement PHP8.2.
• De Nextcloud 23.0.12 à Nextcloud 24.0.10 et ensuite vers 25.0.4 et plus.
• D’une machine 32 bits avec 4 Go à une machine 64 bits et 8 Go de mémoire.
• Double l’espace disque.

Mais il y a de nombreuses contraintes :

• Actuellement les paquets Debian s’arrête à PHP 7.4, il faut donc utiliser des paquets externes. Je n’aime pas trop cette solution, puisqu’il faut faire très attention à l’arrivée des paquets 8.x sur RaspiOS…

• La version Nextcloud 23.0.12 supporte au maximum la version PHP 8.0.

• La migration MySQL à MariaDB a été faite, il y a plus de 3 ans et cela à d’ailleurs coûter l’instance, les fichiers ont été récupérés, mais pas la configuration. Cependant, à l’époque, il s’agissait des paquets MySQL contenant le moteur MariaDB.

• Cette migration utilisera les paquets MariaDB nativement, et tentera de faire disparaître le plus de liens possible à MySQL.

• Autre changement et pas le moindre, la base de donnée actuelle est une base de donnée centralisée, cette migration (conformément au schéma LAMP) prévoit une base de donnée locale. Cela simplifiera et sécurisera les futures mise à jours.

• On change de machine, compte tenu du volume de donnée, cela doit se faire sur plusieurs jours. Pour éviter une interruption de service, elle est déjà en cours et une synchronisation des données entre la prochaine machine et la machine actuelle est à mettre en place. J’ai imaginé deux stratégies possibles :

  • Mettre à jour la base donnée et faire un rsync entre les disques (cela impose une configuration strictement identique entre les instances, et amène pas mal de contraintes potentiels : même URL (?) ,
  • Faire uniquement un rsync en termes de synchronisation et faire une réparation de la structure disque dans la base de donnée… Cette solution, même si elle sera sans doute plus longue à ma préférence, puisqu’il est ainsi possible de faire toutes les mises à jour souhaitées avant la mise en production.

Une instance de test avec les données réelles est maintenant disponible, elle est installée avec :

• PHP 8.0
• MariaDB 10.5
• Nextcloud 25.0.4

Elle contient les grosses nouveautés de Nextcloud HUB II et le passage en 64 permet l’installation de nouvelles applications.

Lors de la migration de ce service, le niveau d’automatisation de l’installation/migration/mise-à-jour a été grandement augmenté. La configuration a été beaucoup simplifiée et se base essentiellement sur du JSON.

ᦿ