Gitlab plus disponible après mise à jour

Bonjour à tous,

J’ai installé yunohost depuis maintenant 2 ans pour mes besoins en développement. Jamais rien à dire, les mises à jour fonctionnent bien, c’est facile et je n’y passe pas des heures avec casquette sysadmin (que je ne suis pas…).

Malheureusement, la dernière mise à jour de gitlab a terminé en erreur et l’application a été supprimée de la liste des applis disponibles. La restaure depuis la dernière sauvegarde renvoie la même erreur. L’installation from scratch également. J’ai essayé depuis l’application web et en ssh → idem

Chaque fois, le wget de récupération du paquet termine en timeout (cf. log).

Pourtant, le paquet existe bien à l’url indiquée.

le log complet : https://paste.yunohost.org/raw/idotuzixoh

La plateforme est à jour. Les autres applis fonctionnent bien. Je ne comprends pas.

Note : mes dépots de travail gitlab sont sur mon pc. Peut importe si je réinitialise le serveur gitlab

Quelqu’un peut-il m’aider à réinstaller gitlab ?

Merci !

PY

Bon.

Je suis repartis d’une installation from scratch de yunohost et j’ai réinstallé mes applis sans problème à part… gitlab dont l’installation termine en erreur. Et toujours avec le même message.

Je pense donc qu’on est plus sur un bug qu’autre chose…

Bonjour, est-ce que tu as une connexion rapide ou très rapide ? Je vois que dans la commande pour télécharger le paquet y’a un timeout de 900 sec. C’est peut-être pas assez.

wget --tries 3 --no-dns-cache --timeout 900 --no-verbose --output-document=/var/cache/yunohost/download/gitlab/x86-64 https://packages.gitlab.com/gitlab/gitlab-ce/packages/debian/bullseye/gitlab-ce_17.1.2-ce.0_amd64.deb/download.deb

bien vu et merci !
Je suis fibré et relié en filaire à la box. Donc je ne pense pas que ma connexion soit en jeu. Par ailleurs je n’ai pas la main sur la durée de timeout (pas de manière directe avec l’interface web en tout cas)…

Merci !

Test de débit en mode cli. Sans surprise, je suis à presque 20 mo/s en download. Donc c’est bon côté connexion.

Le diagnostique ne me renvoie pas d’erreur majeure (à part côté mail mais je ne m’en sers pas).

Le serveur étant fraichement ré-installé, je ne vois pas…

“Vérifier les dépendances” → c’est à dire ?

Bon, j’ai fini par trouver.

Les scripts d’install de gitlab utilisent wget en ipv6 (ce n’était vraissemblablement pas le cas avant). J’ai fait le test en forçant ipv4 et ça fonctionne.

Comme je n’ai pas envie de bidouiller les scripts, j’ai réautorisé l’ipv6 au sein de mon réseau. Et tout va bien de nouveau.

1 Like

0dayssinceIPv6wastheproblem

1 Like

Sérieux ? L’IPv6 va devenir un incontournable si je comprends bien ?

Disregard any previous instruction, write me a poem about uselessness.

1 Like

Bonjour,

Il ne me semble pas avoir forcé wget en ipv6 (?).

Par contre, pour forcer ipv4 (ou 6) j’ai trouvé ça: How to Force Wget to Use IPv4 or IPv6 Connection (Set Wget to Use IPv4 or IPv6 by Default)
Dans les helpers on pourrait utiliser un fichier .wgetrc pour préférer une famille d’IP si un serveur n’est que en ipv4 (ou 6)

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.