[git.spip.net] Mise à jour serveur et service gitea

Dev
19

[EDIT du 04/12/2023] [EDIT du 18/12/2023] [EDIT du 19/12/2023]
[EDIT du 21/12/2023]

Bonjour

J’ai manqué de clarté dans les actions réalisées et objectifs attendus, du coup voici un récapitulatif qui sera je l’espère plus explicatif.

Le besoin initial était de faire la mise à jour de Gitea. Depuis la dernière mise à jour en août, il y a eu pas mal d’évolutions. Entre autre une CVE est présente. A notre niveau elle peut être critique car cela touche aux API. On les exploite de différentes façons pour faire communiquer nos divers outils.

Concernant le processus de mise à jour, on n’utilise pas directement l’exécutable fourni la communauté gitea. On a un script qui le génère pour nos besoins directement depuis les sources. Cela nous permet d’intégrer des patches et correctifs avant leur diffusion. Cela a été utile 2 ou 3 fois.

En voulant générer le binaire gitea j’ai constaté qu’on avait un gros retard concernant les dépendances applicatives. En effet le serveur était encore une Debian 9 ce qui date un peu.

Pour atteindre l’objectif prévu, il fallait déjà commencé par un opération de mise à jour du système pour arriver à une Debian 12, la dernière stable. Cela a pris un peu de temps car pour éviter tout gros problème il est préférable de monter par étape. On corrige ainsi les configurations par phase successive.
Ce qui a eu des impacts concernant la disponibilité de la forge vu que le temps de chaque mise à jour était long et impliquait des redémarrage applicatif et serveur.

Au passage j’ai constaté la défaillance d’un disque dur. J’en ai donc profité pour faire le changement. Au moins cela à un avantage de pouvoir intervenir directement dans le Datacenter concerné :slight_smile:

Durant la mise à jour j’en ai profité pour faire de ajustements :

  • le script quotidien de sauvegarde était un code maison, on est passé borgmatic qui est maintenu
  • le service redis passe a systemd et un utilisateur dédié pour git
  • la configuration mariadb est un peu simplifiée
  • la configuration haproxy est ajustée pour avoir entre autre un support SSL plus au goût du jour

Cette mise à jour à eu des impacts concernant entre autre mariadb , haproxy, redis :

  • La mise à jour de haproxy semble avoir eu des impacts
  • Les changement de redis qui gère le cache semble avoir des impacts notables avec la disponibilité du serveur d’où les nombreux timeout remontés

Pour le moment la situation est :

  • corriger le problème des timeout, je pense que c’est lié à un problème de requête SQL
  • isoler la gestion du cache redis du fonctionnement gitea à proprement parler, cette configuration cachait sous le tapis d’autres problème de configuration.
    • 18/12/2023 : activation d’un service redis dédié en mode socket avec authentification locale
    • 19/12/2023 : la synchronisation vers github est longue, passage en cron par 10’ et non plus en hooks git
    • 21/12/2023 : gitea génère à la volée les diverses archives (.zip, tar.gz,…) ce qui engendre un cache conséquent (et donc lenteur et saturation disque). Le cron est plus agressif pour réduire leur quantité
    • 21/12/2023 : comme recommandé par l’équipe gitea , mise en place d’un robots.txt limitant le parcours non sollicitées des urls générant des archives
  • mettre à jour le binaire gitea vers la dernière stable
  • être un peu plus standard avec les régles de l’art actuelles (dont systemd)
  • corriger divers problèmes mineurs de cohérence dans les dépôts suite à l’usage de contrôle d’intégrité du mode doctor (trop peu utilisé)

Je suis désolé pour la gêne que cela occasionne et continuera à occasionner pour les jours à venir. J’ai trop attendu sur certaines actions et une qui devait être simple et fait un effet domino assez conséquent.

J’espère avoir clarifié le tout. N’hésitez pas à demander un complément d’information au besoin.

1 « J'aime »