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

Bonjour

Je vais devoir effectuer une mise à jour dans le week end. Il s’agit d’une mise à jour majeure avec des changement dans la configuration.
De ce fait la reprise de service pourrait être un peu plus longue que prévue. Le temps de identifier et déboguer les points de configuration.

Je reviens vers vous dès que c’est fini.

Encore désolé pour la gêne occasionnée au cours de ce week end.

1 « J'aime »

Bonjour

La coupure de service va démarrer dans les minutes à venir.

1 « J'aime »

Bonjour

Le service est rétabli pour le moment.
J’ai une contrainte de dépendance dans la mise à jour que je n’avais pas anticipé. Il faut que je vois comment faire sans avoir tout à casser trop longtemps.

Pour le moment le service est à nouveau actif.

1 « J'aime »

merci azerttyu !

1 « J'aime »

Merci @azerttyu

1 « J'aime »

Bonjour

Je fais faire l’opération de mise à jour serveur dans la journée. Je prévois une bonne heure de coupure et plusieurs redémarrages. Ce qui risque de rendre partiellement injoignable le service pendant 2 ou 3h.

Par conséquent pour ne pas faire de nuit et tout en limitant l’impact je vais intervenir à partir de 16h, ce 29/11/2023.

Km

1 « J'aime »

Bonjour

Je bloque accès aux dépôts à partir de maintenant. Je vous tiens au courant quand le service sera à nouveau disponible.

1 « J'aime »

Bonjour

Mon estimation est complètement à la ramasse. Je suis actuellement à 30% du process de mise à jour.

1 « J'aime »

Aïe, la soirée s’annonce longue. Bon courage et merci.

1 « J'aime »

Bonsoir

Je n’ai pas fini toutes mes étapes de mise à jour système. Toutefois je suis dans un état stable et fonctionne.

Les services de la forge sont à nouveau disponibles pour le moment. Je continuerai je pense dans la journée de jeudi.
De prévu j’ai encore une mise à jour de version Debian à effectuer. Ensuite je pourrais mettre à jour la forge.

Désolé encore pour la gêne occasionnée. A vouloir trop attendre je me suis manger la main.

1 « J'aime »

Hop, courage !

C’est un peu en lien avec Avenir de Gitea où l’on abordait le sujet d’une bascule vers forgejo, qui risque de poser problème si on attend trop, non ?

1 « J'aime »

Hello

Comme je l’ai déjà dit gitea vs forgejo est un faux débat. En l’"état c’est blanc bonnet et bonnet blanc.

Le problème vient d’une grosse mise à jour serveur, on était encore sur buster. À vouloir trop attendre pour les mises à jour majeures, j’ai accumulé un trop gros gap. C’est ce qui m’a mangé la main.

Ce retard de mise à jour bloquait la possibilité d’avoir des versions de go, node, … suffisamment récentes.

Comme ce socle applicatif est le même entre les 2 projets, on aurait rencontré exactement le même problème.

Nous sommes actuellement à une version de debian en retard, ce que je vais traiter dans la matinée. Comme ça je limite le cumul de retard :slight_smile:

1 « J'aime »

Hello

J’attaque la mise à jour serveur restante. Vu l’expérience de hier soir c’est bon pour encore une heure de service perturbé.

1 « J'aime »

Hello

La partie web du service git va subir des perturbations.
La partie SSH est coupée pour éviter tout commit malencontreux

1 « J'aime »

Bonjour

La mise à jour serveur est finie. Le système est maintenant à jour avec un Debian 12 toute propre.
Désolé pour ces coupures de services mais cela était nécessaire pour avoir en défaut les dépendances nécessaires pour la forge.

Je vais pouvoir m’occuper de mettre à jour le code de la forge, la coupure de service devrait être moindre.
Je regarde ceci dans le reste de la journée.

1 « J'aime »

Merci beaucoup azerttyu pour tout ça

1 « J'aime »

Bonjour

En complément, je viens de faire un changement de disque qui montrait un début de défaillance.
Le service risque d’être ralenti pour l’heure à venir, le temps de reconstruire le raid associé.

Bonjour

L’opération concernant le disque dur est finie. Normalement les services sont revenus à leur état nominal.

[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 »