La Fibre
Télécom => Logiciels et systèmes d'exploitation => 
Linux => Discussion démarrée par: vivien le 15 septembre 2017 à 09:20:14
-
Vendredi 25 août, j'ai du changer l'IPv4 et l'IPv6 du serveur qui distribue les mises à jour Ubuntu pour la France (http://fr.archive.ubuntu.com/)
Les DNS, qui ont un TTL de 15 minutes, donc en quelques minutes tout le trafic avait basculé.
Tout le trafic ?
Non, Il y a avait toujours des requêtes sur l'ancienne IP (où j'avais mis un serveur web vide - qui répond donc une erreur 404 a toutes les requêtes)
J'ai fini par grapher les requêtes pour voir si cela diminuait avec le temps :
(https://lafibre.info/testdebit/ubuntu/201709_changement_ip_archive_ubuntu.png)
Ce qui est inquiétant, c'est que c'est stable : j'ai toujours de 1 a 6 requête par seconde en fonction de l'heure.
J'ai regardé les IP, pour voir si c'est des IP étrangères ou des robot d'indexation (généralement, en cas de changement d'IP, ce sont des robots qui restent plusieurs jours sur l'ancienne IP).
Voici le fichier de log : 201709_log_changement_ip_archive_ubuntu.ods (https://lafibre.info/testdebit/ubuntu/201709_log_changement_ip_archive_ubuntu.ods) (fichier lisible avec Libre Office Calc ou Microsoft Excel)
J'ai agrégé chaque ensemble de requête généré par apt-get pour n'avoir qu'une seule ligne :
Comme vous pouvez-le voir malgré les dernières chiffres qu'il manque sur les IP, ce sont toutes des IP Françaises. Tous les FAI français sont représentés (Orange / SFR / Free / Bouygues Telecom / K-Net / ....) de même que les hébergeurs (Online / OVH / ...).
Les serveur DNS de ces opérateur pointant bien vers la bonne IP, je pense qu'il faut chercher la solution aillueur, mais je n'ai pas de piste...
Pourquoi certains PC continueraient pendant des semaines a utiliser un nom de domaine avec une ancienne adresse IP ?
(il y a bien un nom de domaine qui est passé, ce ne sont pas des clients qui ont mis l'IP en dur dans le fichier /etc/apt/source.list )
-
Il y a peut-être un cache DNS sur les machines qui n'ont pas été reboot?
-
Je ping 194.158.119.186 depuis un serveur cache dns non reboot depuis 115j
-
C'est bien la nouvelle IPv4.
Nouvelle IPv4 : 194.158.119.186
Ancienne IPv4 : 194.158.119.190
Nouvelle IPv6 : 2001:860:f70a::2
Ancienne IPv6 : 2001:860:f70a:100::2
-
Le changement sur les DNS a été fait le 25 août, mais j'ai toujours un nombre irréductible et stable de requêtes fait sur l'ancienne IP :
(https://lafibre.info/testdebit/ubuntu/201710_changement_ip_archive_ubuntu.png)
L'URL dans les log montre bien qu'ils recherchent des mises à jour Ubuntu.
Comme le montre le fichier de log : 201709_log_changement_ip_archive_ubuntu.ods (https://lafibre.info/testdebit/ubuntu/201709_log_changement_ip_archive_ubuntu.ods), tous les opérateurs sont concernés, je pense donc que ce n'est pas le DNS récursif coté opérateur qui est en cause.
-
Bah coupe franchement le service sur l'ancienne IP. Les apt et les yum sont allez intelligents pour prendre un autre mirroir si l'ancien ne répond plus.
-
Impressionnant le nombre d'IPS Orange sur ce document...
-
Bah coupe franchement le service sur l'ancienne IP. Les apt et les yum sont allez intelligents pour prendre un autre mirroir si l'ancien ne répond plus.
Le service est coupé depuis le 25 août, là ce sont des erreurs 404 qui sont renvoyés.
Orange est le plus grand FAI français, il est normal qu'il soit le plus représenté ici.
-
des caches dns internes a certaines boites....
-
Le volume de requêtes sur l'ancienne IP a diminué :
(https://lafibre.info/testdebit/ubuntu/201710_changement_ip_archive_ubuntu_2.png)
J'ai pris une capture Wireshark pour voir si on avait des informations supplèmentaires dans les en-têtes.
On voit bien qu'une partie importantes des requetes avec DNS pas à jour ne sont pas en direct :
Celui là utilise Squid avec une IP interne privée en 10.xxx.xxx.xxx :
GET /ubuntu/dists/trusty/restricted/source/Sources.gz HTTP/1.1
Host: fr.archive.ubuntu.com
If-Modified-Since: Thu, 08 May 2014 14:00:42 GMT
User-Agent: Debian APT-HTTP/1.3 (1.0.1ubuntu2)
Via: 1.1 server-60 (squid/3.3.8)
X-Forwarded-For: 10.67.200.1
Cache-Control: max-age=0
Connection: keep-alive
La réponse de mon serveur est bien sur du 404 :
HTTP/1.1 404 Not Found
Date: Fri, 27 Oct 2017 15:02:45 GMT
Server: Apache/2.4.27 (Ubuntu)
Content-Length: 333
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=iso-8859-1
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>404 Not Found</title>
</head><body>
<h1>Not Found</h1>
<p>The requested URL /ubuntu/dists/trusty/restricted/source/Sources.gz was not found on this server.</p>
<hr>
<address>Apache/2.4.27 (Ubuntu) Server at fr.archive.ubuntu.com Port 80</address>
</body></html>
Celui là semble aussi avoir des IP internes derrière un proxy, sauf que les IP internes sont des IP publiques apparentent à un autre réseau !
GET /ubuntu/dists/xenial/restricted/i18n/Translation-en.xz HTTP/1.1
Host: fr.archive.ubuntu.com
Cache-Control: max-age=0
If-Modified-Since: Thu, 14 Apr 2016 23:48:41 GMT
User-Agent: Debian APT-HTTP/1.3 (1.2.20)
X-Forwarded-For: 198.152.66.244
Encore un autre avec des en-têtes http qui sortent de l'habituel :
GET /ubuntu/dists/xenial/InRelease HTTP/1.1
Connection: keep-alive
Host: fr.archive.ubuntu.com
Cache-Control: max-age=0
Accept: text/*
User-Agent: Debian APT-HTTP/1.3 (1.2.24)
If-Modified-Since: Thu, 21 Apr 2016 23:24:48 GMT
X-IMForwards: 20
Via: 1.1 aer01-mda1-dmz-wsa-2.cisco.com:80 (Cisco-WSA/X)
X-Forwarded-For: 10.60.17.170
Une en-tête bien plus courte :
GET /ubuntu/dists/xenial-backports/multiverse/binary-all/Packages.lz4 HTTP/1.1
Host: fr.archive.ubuntu.com
Cache-Control: max-age=0
User-Agent: Debian APT-HTTP/1.3 (1.2.20)
Une en-tête avec If-Modified-Since, j'imagine que cela signifie qu'il y a un cache qq part...
GET /ubuntu/dists/xenial/multiverse/dep11/icons-64x64.tar.xz HTTP/1.1
Host: fr.archive.ubuntu.com
Cache-Control: max-age=0
If-Modified-Since: Wed, 20 Apr 2016 20:45:31 GMT
User-Agent: Debian APT-HTTP/1.3 (1.2.24)
-
C'est bizarre. Cela fait pas mal de machines qui ne trouvent pas leurs mises à jour, et malgré l'erreur 404, ne cherchent pas un autre serveur. Cela sent la mise à jour automatique. Avec un apt-get update manuel, l'administrateur verrait l'erreur.
Une possibilité, mais étrange quand même, l'IP de fr.archive.ubuntu.com dans le fichier hosts ?
-
A mon avis, Proxy dans une entreprise + entrée Hosts...
-
Oui, avec proxy, seuls des serveurs DNS internes sont consultables, qui ne sont peut-être pas très fiables.
-
Cela sent la mise à jour automatique. Avec un apt-get update manuel, l'administrateur verrait l'erreur.
Par défaut Ubuntu desktop et serveur cherche les mise à jour tous les jour, sans les installer (notification de mises à jour disponibles)
Oui, avec proxy, seuls des serveurs DNS internes sont consultables, qui ne sont peut-être pas très fiables.
Le comportement par défaut d'un DNS est de faire des requêtes récursive si l'information n'est pas en cache ou si le cache est expiré.
Là cela fait plus de 2 mois que l'entrée DNS a changée...
-
Si l'adresse est dans le fichiers hosts, tant qu'elle ne sera pas changée, c'est elle qui sera consultée avant les DNS.
Pour le comportement d'Ubuntu, oui, c'est vrai qu'il recherche s'il y en a de disponibles.
P.S : quand je dis pas très fiable, je veux dire qu'ils ne répondent pas tout le temps (je parle d'expérience, je connais le cas), car il n'y en a qu'un, qui peut-être inaccessible en cas de mise à jour , maintenance, ou autre incident.
-
Possible de renvoyer autre chose que le 404 ?
Parce que comme le dit alain_p, en manuel ça se verrait.
C'est une réponse faite pour un humain pas pour une machine.
Là, la machine trouve rien mais continue surtout ses requêtes sur un repertoire vide et interpréte ça comme une absence de MAJ.
Si c'est possible, il faut lui envoyer "un coup de pelle" que l'admin soit au courant du changement.
Tu vois ce que je veut dire ?
-
La réponse 404 est parfaitement interprété par le système
Tu voudrai que j'utilise quel code ?
https://fr.wikipedia.org/wiki/Liste_des_codes_HTTP
-
La réponse 404 est parfaitement interprété par le système
Tu voudrai que j'utilise quel code ?
https://fr.wikipedia.org/wiki/Liste_des_codes_HTTP
Ah, le serveur se dit tout seul : ah merde, il y a rien, je vais donc fouiller sur google où est ce fichu fichier ?
Même si le seveur reçoit le 404, il le log et affiche un message préformaté si l'apt get est manuel.
Ex : Retour 404 -> mec y a rien sur le serveur.
Je vais pas t'apprendre, tu doit t'y connaitre mieux que moi en linux mais c'est du bon sens.
Le système reçoit un 404 mais il est comme une poule devant un couteau, ce n'est qu'une vieille variable qui déclenche un affichage sur le client ou une ligne de log, il n'y a pas d'action concrète de prévue.
Si le serveur est down le système reçoit autre chose qu'un 404 et change bien de dépôt non ?
Parce que là le 404 c'est juste interprété comme : pas de maj revient plus tard par le système à priori mais affiche un message personnalisé selon le client.
Sur la page wiki 404, ils indiquent préférable d'utiliser 410 même si ça doit rien faire de plus.
https://fr.m.wikipedia.org/wiki/Erreur_HTTP_404
Il faut trouver autre chose à renvoyer.
Quelque chose qui prévienne de façon brutale l'admin ou qui indique au système : coucou, j'ai changer l'adresse IP du serveur, fait la Maj boulet !!!!
Il y a sûrement moyen avec un ex dépôt officiel d'agir sur le système en lui indiquant de modifier l'IP du serveur.
Je donne des pistes de réflexion pour régler le souci parce que là le topic est dans un cul de sac.
Faut un dev qui tombe sur ce topic et apporte une soluce.
-
Ce que je ferais, c'est une mise en situation :
Tu reproduis l'expérience (ex IP en dure) avec un de tes systèmes.
Et tu vois ce que ça fait avec le retour 404.
Et tu bidouilles (renvoi autre que 404 etc) jusqu'à ce que la maj se fasse :D
-
Quel est le problème ?
Des gens font n'importe quoi et obtiennent n'importe quoi
Tout va donc parfaitement bien