La Fibre
Télécom => Logiciels et systèmes d'exploitation => 
Linux => Discussion démarrée par: Pontus le 03 décembre 2021 à 07:54:27
-
Je n'arrive pas à installer de nouveaux paquets sur mon Ubuntu :
Err :13 http://fr.archive.ubuntu.com/ubuntu focal InRelease
Connexion à fr.archive.ubuntu.com: 80 (51.158.154.169) impossible, délai de connexion dépassé
Je me suis rendu compte que fr.archive.ubuntu.com était en fait sur lafibre.info :
Non-authoritative answer:
fr.archive.ubuntu.com canonical name = bouyguestelecom.ubuntu.lafibre.info.
Name: bouyguestelecom.ubuntu.lafibre.info
Address: 51.158.154.169
Il y a un soucis actuellement ?
-
Bonjour et bienvenue sur le forum,
J'en profite pour indiquer que depuis 3 semaines, le serveur https://ubuntu.lafibre.info/ qui distribue les mises à jour par défaut pour la France n'est plus hébergé par Bouygues Telecom, mais par Scaleway, qui a bien voulu prendre la relève avec un serveur Dedibox très performant proposé Scaleway's Open Source Program (https://www.scaleway.com/en/about-us/open-source-program/). Je vais faire un sujet dessus.
Il y a eu une coupure de trois quart d'heure ce matin comme le montre ce graphique du débit :
(https://lafibre.info/images/stats/202112_stats_ubuntu_fr.png)
J'ai effectué un reboot pour appliquer les mises à jour de sécurité, et.. il n'a pas redémarré, l'UEFI ne démarrant pas sur le NVMe.
Voici la vidéo prise par le KVM over IP (très pratique le KVM over IP) :
https://lafibre.info/videos/materiel/202112_scaleway_boot_dedibox.mp4
Ensuite on reste bloqué sur cet écran :
(https://lafibre.info/images/online/202112_scaleway_boot_dedibox.png)
Si on reste longtemps (plus de 10 minutes), le watchdog réinitialise le serveur.
J'ai également tenté le "Ctrl" + "Alt" + "Suppr", l’arrêt du serveur et son redémarrage, mais rien n'y fait, j'ai a chaque reboot ce message.
J'ai tenté d'avoir le boot menu, mais je tombe sur cet écran avant d'avoir le boot menu.
Ce qui m'a sauvé ? J'ai tenté l'appui sur "Echap" au moment du message "Press ESC key to abort PXE boot"
Le prochain redémarrage je le ferais de nuit afin de ne pas affecter les utilisateurs si cela ne se passe bien.
Edit : vidéo d’accès au BIOS
https://lafibre.info/videos/materiel/202201_scaleway_boot_dedibox.mp4
-
Ce qui m'a sauvé ? J'ai tenté l'appui sur "Echap" au moment du message "Press ESC key to abort PXE boot"
Peut-être intervenir dans l'ordre de démarrage dans le BIOS pour supprimer le boot sur le PXE ? Sur un serveur Dell, avec l'IDRAC, cela peut se faire maintenant dans l'IDRAC, sans rebooter, mais je suppose que dans ce cas, il faut un reboot ?
-
Les clients ne sont pas autorisés à modifier le paramétrage du BIOS, sinon j'aurais bien enlevé la tentative de boot sur le réseau qui ralenti bien le process de démarrage (il fait deux longues tentatives de boot sur le réseau).
J'imagine que cela pose problème quand le serveur est réattribué à un autre client et qu'il faut réinstaller le serveur (avec un boot réseau sur le système chargé d'installer le nouveau système d’exploitation)
-
Oui, je suppose que c'est effectivement pour l'installation à distance. Et c'est vrai que la recherche d'un serveur PXE sur le réseau est longue...
-
Merci pour l'accueil et le retour ! :)
-
Tiens le chemin m'intrigue à partir d'un FAI toulousain
traceroute to fr.archive.ubuntu.com (51.158.154.169), 30 hops max, 60 byte packets
1 * * 10.99.0.1 (10.99.0.1) 67.712 ms
2 h7.tetaneutral.net (91.224.148.1) 67.715 ms 72.044 ms *
3 te0-0-0-12.rcr01.tls01.atlas.cogentco.com (149.11.58.73) 72.948 ms 73.455 ms *
4 te0-2-1-2.rcr21.bod01.atlas.cogentco.com (154.54.56.213) 74.542 ms 78.646 ms 97.932 ms
5 * * be2698.ccr41.par01.atlas.cogentco.com (154.54.57.145) 99.930 ms
6 * be12266.ccr42.ams03.atlas.cogentco.com (154.54.56.173) 201.602 ms be12265.ccr41.ams03.atlas.cogentco.com (130.117.2.141) 201.538 ms
7 be2008.rcr22.ams06.atlas.cogentco.com (130.117.48.170) 198.956 ms be2154.rcr22.ams06.atlas.cogentco.com (130.117.50.206) 196.709 ms be3434.rcr21.ams06.atlas.cogentco.com (154.54.59.50) 196.179 ms
8 * * *
9 51.158.8.168 (51.158.8.168) 201.132 ms 51.158.8.25 (51.158.8.25) 72.729 ms 51.158.8.170 (51.158.8.170) 79.243 ms
10 51.158.143.11 (51.158.143.11) 83.630 ms 112.624 ms 112.862 ms
11 fr.archive.ubuntu.com (51.158.154.169) 114.294 ms 119.199 ms 120.612 ms
Vraiment nécessaire de passer par Amsterdam ?
-
Pour l'instant il est à Amsterdam, faute de capacité en France.
Il faut avoir de bon peering avec les opérateurs Français, le fait d'être à Amsterdam n'est pas problématique (cela rajoute quelques ms).
-
D'acc, merci pour la précision.
-
Ah, c'est bête, il faut absolument en parler au support !
En plus, ça me dit quelque chose, cette histoire. J'essaierai de poser la question aux collègues demain.
C'est l'OS d'origine installé par la console ?
-
Les clients ne sont pas autorisés à modifier le paramétrage du BIOS, sinon j'aurais bien enlevé la tentative de boot sur le réseau qui ralenti bien le process de démarrage (il fait deux longues tentatives de boot sur le réseau).
L'ordre peut être modifié depuis l'OS avec efibootmgr, qui peut même être appelé automatiquement (à l'installation de grub par exemple).
Si c'est supporté, on peut choisir sur quelle entrée on démarre pour le boot suivant (c'est donc temporaire), avec "efibootmgr --bootnext".
Par exemple, tu peux te faire un script de reboot avec :
sudo efibootmgr --bootnext=$(efibootmgr | awk '/BootCurrent/ { print $2 }')
sudo systemctl rebootIl est probablement possible d'en faire un service, pour que la commande soit lancée automatiquement.
-
C'est l'OS d'origine installé par la console ?
Oui, c'est l'OS installé par la console : Ubuntu 20.04 LTS (On n'a pas les droits pour charger un fichier ISO dans le KVM pour installer un OS manuel).
Je passé par contre sur un Kernel HWE (cf Tutoriel pour comprendre et changer de noyaux Linux avec Ubuntu 20.04 LTS (https://lafibre.info/serveur-linux/noyaux-linux/)), mais cela ne doit rien changer.
J'ai par contre un peu de mal à comprendre à quoi correspond ces "core_udp_sendto". Je n'avais pas eu ces problèmes lors de nombreux reboot précédents la mise en prod.
-
le serveur https://ubuntu.lafibre.info/ n'est plus hébergé par Bouygues Telecom, mais par Scaleway
C'est une demande de Bouygues Telecom de ne plus héberger ce serveur ? Est-ce que les raisons sont "politiques" ou "techniques" (ex: volume de trafic généré) ?
-
Le serveur de mis à jour Ubuntu Bouygues arrivait en fin d'espace disque (on va bientôt arrive à 2 To d'archive Ubuntu, les distributions LTS étant gardées plus longtemps avec l’allongement de leur durée de maintenance). Le serveur Bouygues était à Interixon PAR2 (Aubervilliers), espace qui est devenu dédié aux routeurs. Aujourd'hui c'est le seul serveur dans une grande salle avec des dizaines de baies remplis de routeurs et différents équipements réseaux. L'upgrade du serveur n'était pas possible car ils cherchaient à éliminer tout ce qui est dans des process spécifiques et les espaces d’hébergement sont regroupés au sein de plateforme de service dédiées et pas mis à coté de routeurs du cœur de réseau.
Bouygues Telecom était prêt a prêt à proposer gratuitement à Canonical une VM qui correspond aux besoins, mais pas à un particulier pour des questions de responsabilité juridique. On a eu une réunion avec le juridique de Bouygues, Canonical et moi sans trouver de solution. Bouygues Telecom est une boite où sortir du process est compliqué.
Bref, j'ai demandé à Scaleway si cela pouvait rentrer dans leur programme OPen Source et ils ont très rapidement acceptés et je les en remercie (a deux semaines prés, j'aurais manqué d'espace disque).
-
D'accord c'est dommage mais merci pour les détails et à Scaleway d'avoir pris le relais.
Je ne connaissais pas leur programme open source jusqu'à maintenant mais je pense que c'est bien d'avoir quelque chose de public/documenté là-dessus.
Je sais qu'OVH "sponsorise" aussi certaines organisations mais de mon impression rien n'est public et cela se fait un peu "au piston".
-
A nouveau HS ?
Edit : https cassé
-
A nouveau HS ?
Edit : https cassé
http fonctionnel chez moi, mais https HS aussi
-
Cette fois-ci c'est lié à Canonical qui ont redirigés fr.archive.ubuntu.com sur un autre serveur hier, le 17 décembre, à 3h du matin (vu l'heure je me demande où étaient ceux qui ont fait la modification).
J'ai contacté Canonical hier matin, mes interlocuteurs Français ont transmis aux collègues qui gère les miroirs, mais je n'ai pas eu de réponse.
Le http fonctionne parfaitement mais pas le https. J'ai remarqué que j'étais le seul à faire du https sur le nom de domaine pays.archive.ubuntu.com, les autres country miroir le font sur un autre nom de domaine. (j'ai longtemps poussé pour la mise en place du https avec plusieurs tickets cf Demander à Canonical de rajouter https pour les mises à jour d'Ubuntu ? (https://lafibre.info/tutoriels-linux/maj-https/) et Tutoriel pour mettre les dépôts logiciels d'Ubuntu en https (https://lafibre.info/tutoriels-linux/depots-ubuntu-https/)) c'est peut-être cela qui n'a pas été apprécié.
En attendant, le serveur Scaleway écoute sur un domaine séparé : https://ubuntu.lafibre.info/ et j'ai demandé la mise en place du CNAME fr.archive.ubuntu.com pour pointer sur ubuntu.lafibre.info au moins en http.
Si vous avez vos dépôts en https sur fr.archive.ubuntu.com :
- La commande pour passer en https sur ubuntu.lafibre.info est la suivante :
sudo sed -i -e "s/https:\/\/fr.archive.ubuntu.com/https:\/\/ubuntu.lafibre.info/g" /etc/apt/sources.list
- La commande pour passer en http sur fr.archive.ubuntu.com est la suivante :
sudo sed -i -e "s/https:\/\/fr.archive.ubuntu.com/http:\/\/fr.archive.ubuntu.com/g" /etc/apt/sources.list
-
A noter que https://fr.archive.ubuntu.com/ est de nouveau disponible en https.
Les miroirs sont gérés par Canonical depuis l'Australie, d'où le décalage horaire.
Je ne sais pas ce qui a posé problème, toutefois cela pourrait être le fait que sur dans les menus on peut choisir https avec https://fr.archive.ubuntu.com/
Une mise à jour va changer ça dans le futur : ce sera https://ubuntu.lafibre.info/ qui sera proposé dans ce même menu.
Le serveur par défaut sera toujours http://fr.archive.ubuntu.com pour la France, mais l'interface ne proposera pas de https (le https fonctionnera en pratique)
(https://lafibre.info/testdebit/ubuntu/202010_miroir_ubuntu_https_1.png)
-
Je ne sais pas ce qui a posé problème, toutefois cela pourrait être le fait que sur dans les menus on peut choisir https avec https://fr.archive.ubuntu.com/
Toujours ce problème du chiffrement en étant basé aux UK ?
-
Par défaut les mises à jour sont réalisées en http sur le serveur du pays déclaré : fr.archive.ubuntu.com pour la France et uk.archive.ubuntu.com pour les uk.
Des serveurs https sont proposés (dès que le serveur tiers fait du https, il est proposé en https). Cf liste sur https://launchpad.net/ubuntu/+archivemirrors
De mon coté, j'avais déclaré le serveur fr.archive.ubuntu.com comme serveur proposant du https et j'imagine que ce qui a posé problème.
J'ai donc proposé un nouveau nom domaine pour les connexions https : ubuntu.lafibre.info
ubuntu.lafibre.info et fr.archive.ubuntu.com pointent tous les deux sur le même serveur : fr.archive.ubuntu.com à un enregistrement CNAME vers ubuntu.lafibre.info
Les deux répondent en http et https.
Dans l'interface graphique pour choisir un serveur miror, il y aura par contre ubuntu.lafibre.info qui sera déclaré à la place de fr.archive.ubuntu.com actuellement.
-
Fin novembre j'ai eu un problème similaire de reboot avec un serveur Scaleway (Dedibox). Impossible de faire marcher l'ILO (trop vieux), et rien côté console directement branché au serveur. Malgré un support habituellement au top, ils n'ont rien pu faire, j'ai dû changer dans la nuit pour éviter un downtime trop important.