Quand apt-get échoue avec
« 406 Not Acceptable »

J’ai remis en service un conteneur VZ qui n’avait pas été démarré depuis plusieurs mois. Je le laisse en squeeze tant que le support de squeeze-lts continue, à cause d’un logiciel qui exige de vieilles dépendances. En voulant appliquer les mises à jour de sécurité, apt-get update échouait, et les messages d’erreur n’étaient pas clairs.

En fait, le bon message d’erreur était noyé dans la masse :

W: Impossible de récupérer http://ftp.fr.debian.org/debian/dists/wheezy/contrib/binary-i386/Packages 406 Not Acceptable [IP : 212.27.32.66 80]
W: Impossible de récupérer http://ftp.fr.debian.org/debian/dists/wheezy/non-free/binary-i386/Packages 406 Not Acceptable [IP : 212.27.32.66 80]
W: Impossible de récupérer http://security.debian.org/dists/squeeze/updates/contrib/binary-i386/Packages 404 Not Found [IP : 212.211.132.32 80]
W: Impossible de récupérer http://ftp.fr.debian.org/debian/dists/squeeze/main/binary-i386/Packages 406 Not Acceptable [IP : 212.27.32.66 80]
W: Impossible de récupérer http://ftp.fr.debian.org/debian/dists/squeeze/contrib/binary-i386/Packages 406 Not Acceptable [IP : 212.27.32.66 80]
E: Le téléchargement de quelques fichiers d'index a échoué, ils ont été ignorés, ou les anciens ont été utilisés à la place.

Premier réflexe : vider le cache BIND (rndc flush), pour vérifier si l’un des noms de domaine ne pointerait pas vers un mauvais serveur, après un changement de DNS.

% ping -c3 ftp.fr.debian.org
PING debian.proxad.net (212.27.32.66) 56(84) bytes of data.
64 bytes from debian.proxad.net (212.27.32.66): icmp_req=1 ttl=57 time=17.5 ms
64 bytes from debian.proxad.net (212.27.32.66): icmp_req=2 ttl=57 time=17.8 ms
64 bytes from debian.proxad.net (212.27.32.66): icmp_req=3 ttl=57 time=17.7 ms

% ping -c3 security.debian.org
PING security.debian.org (212.211.132.32) 56(84) bytes of data.
64 bytes from villa.debian.org (212.211.132.32): icmp_req=1 ttl=52 time=38.6 ms
64 bytes from villa.debian.org (212.211.132.32): icmp_req=2 ttl=52 time=39.4 ms
64 bytes from villa.debian.org (212.211.132.32): icmp_req=3 ttl=52 time=43.7 ms

Mais tout le monde répond, et les reverses sont concordants (villa c’est bien la machine habituelle vers laquelle pointe security.debian.org).

En faisant une recherche, je me suis aperçu que ceux qui avaient le même problème étaient aussi chez Free. Et ils utilisaient aussi le dépôt ftp.fr.debian.org. Or, comme le résultat du ping le montre, Free répond aux requêtes allant vers ftp.fr.debian.org avec son propre miroir.

J’ai alors testé avec ftp.debian.org : je n’avais plus qu’une seule erreur, la 404 sur security.debian.org. Avec un message d’erreur clair, on peut avancer : effectivement, le fichier http://security.debian.org/dists/squeeze/updates/contrib/binary-i386/Packages n’existe plus. Cette page d’explication sur squeeze-lts donne la raison :

Le dépôt security n'est plus nécessaire dans la mesure où la dernière version intermédiaire de squeeze a été publiée. Tous les paquets du dépôt security ont été copiés dans le dépôt main avec cette version.

Donc dans le cas suivant :

  • votre FAI est Free
  • vous avez choisi le dépôt ftp.fr.debian.org
  • un autre dépôt utilisé par votre /etc/apt/sources.list retourne une erreur 404.

On peut se retrouver avec ces erreurs « 406 Not Acceptable », ce qui signifie un échec de négociation entre client et serveur sur le type de réponse. Ce qui est étrange, c’est que d’une part en sélectionnant le dépôt ftp.debian.org (ce qui revient à aller sur un autre miroir que celui de Free) on n’obtient plus les erreurs 406, alors que la 404 est toujours là. D’autre part, en admettant que le miroir de Free ait une configuration particulière, les erreurs 406 ne surviennent que lorsque un autre dépôt renvoit une 404.

En conclusion, il vaut mieux pointer vers ftp.debian.org, et mettre son propre cache APT pour soulager les serveurs Debian.

Je vous conseille apt-cacher-ng. Par le passé, j’avais eu des ennuis avec d’autres outils faisant cache APT. Depuis que je suis passé à apt-cacher-ng, tout marche de manière transparente (ou presque, je dois le relancer une ou deux fois par an quand un apt-get update bloque, ça se limite à ça).

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *