{"id":205,"date":"2014-12-28T13:41:55","date_gmt":"2014-12-28T12:41:55","guid":{"rendered":"http:\/\/almin.tf\/blog\/?p=205"},"modified":"2020-05-03T14:36:35","modified_gmt":"2020-05-03T13:36:35","slug":"apt-get-406-not-acceptable","status":"publish","type":"post","link":"https:\/\/almic.fr\/blog\/2014\/12\/28\/apt-get-406-not-acceptable\/","title":{"rendered":"Quand apt-get \u00e9choue avec <br \/> \u00ab 406 Not Acceptable \u00bb"},"content":{"rendered":"<p style=\"text-align: justify;\">J\u2019ai remis en service un conteneur VZ qui n\u2019avait pas \u00e9t\u00e9 d\u00e9marr\u00e9 depuis plusieurs mois. Je le laisse en squeeze tant que le support de squeeze-lts continue, \u00e0 cause d\u2019un logiciel qui exige de vieilles d\u00e9pendances. En voulant appliquer les mises \u00e0 jour de s\u00e9curit\u00e9, <i>apt-get update<\/i> \u00e9chouait, et les messages d\u2019erreur n\u2019\u00e9taient pas clairs.<\/p>\n<p><!--more--><\/p>\n<p style=\"text-align: justify;\">En fait, le bon message d\u2019erreur \u00e9tait noy\u00e9 dans la masse :<\/p>\n<p><code>W: Impossible de r\u00e9cup\u00e9rer http:\/\/ftp.fr.debian.org\/debian\/dists\/wheezy\/contrib\/binary-i386\/Packages  406  Not Acceptable [IP : 212.27.32.66 80]<br \/>\nW: Impossible de r\u00e9cup\u00e9rer http:\/\/ftp.fr.debian.org\/debian\/dists\/wheezy\/non-free\/binary-i386\/Packages  406  Not Acceptable [IP : 212.27.32.66 80]<br \/>\nW: Impossible de r\u00e9cup\u00e9rer http:\/\/security.debian.org\/dists\/squeeze\/updates\/contrib\/binary-i386\/Packages  404  Not Found [IP : 212.211.132.32 80]<br \/>\nW: Impossible de r\u00e9cup\u00e9rer http:\/\/ftp.fr.debian.org\/debian\/dists\/squeeze\/main\/binary-i386\/Packages  406  Not Acceptable [IP : 212.27.32.66 80]<br \/>\nW: Impossible de r\u00e9cup\u00e9rer http:\/\/ftp.fr.debian.org\/debian\/dists\/squeeze\/contrib\/binary-i386\/Packages  406  Not Acceptable [IP : 212.27.32.66 80]<br \/>\nE: Le t\u00e9l\u00e9chargement de quelques fichiers d'index a \u00e9chou\u00e9, ils ont \u00e9t\u00e9 ignor\u00e9s, ou les anciens ont \u00e9t\u00e9 utilis\u00e9s \u00e0 la place.<\/code><\/p>\n<p style=\"text-align: justify;\">Premier r\u00e9flexe : vider le cache BIND (<i>rndc flush<\/i>), pour v\u00e9rifier si l\u2019un des noms de domaine ne pointerait pas vers un mauvais serveur, apr\u00e8s un changement de DNS.<\/p>\n<pre>% ping -c3 ftp.fr.debian.org\r\nPING debian.proxad.net (212.27.32.66) 56(84) bytes of data.\r\n64 bytes from debian.proxad.net (212.27.32.66): icmp_req=1 ttl=57 time=17.5 ms\r\n64 bytes from debian.proxad.net (212.27.32.66): icmp_req=2 ttl=57 time=17.8 ms\r\n64 bytes from debian.proxad.net (212.27.32.66): icmp_req=3 ttl=57 time=17.7 ms\r\n\r\n% ping -c3 security.debian.org\r\nPING security.debian.org (212.211.132.32) 56(84) bytes of data.\r\n64 bytes from villa.debian.org (212.211.132.32): icmp_req=1 ttl=52 time=38.6 ms\r\n64 bytes from villa.debian.org (212.211.132.32): icmp_req=2 ttl=52 time=39.4 ms\r\n64 bytes from villa.debian.org (212.211.132.32): icmp_req=3 ttl=52 time=43.7 ms<\/pre>\n<p style=\"text-align: justify;\">Mais tout le monde r\u00e9pond, et les reverses sont concordants (<i>villa<\/i> c\u2019est bien la machine habituelle vers laquelle pointe <i>security.debian.org<\/i>).<\/p>\n<p style=\"text-align: justify;\">En faisant une recherche, je me suis aper\u00e7u que ceux qui avaient le m\u00eame probl\u00e8me \u00e9taient aussi chez Free. Et ils utilisaient aussi le d\u00e9p\u00f4t <i>ftp.fr.debian.org<\/i>. Or, comme le r\u00e9sultat du ping le montre, Free r\u00e9pond aux requ\u00eates allant vers <i>ftp.fr.debian.org<\/i> avec son propre miroir.<\/p>\n<p style=\"text-align: justify;\">J\u2019ai alors test\u00e9 avec <i>ftp.debian.org<\/i> : je n\u2019avais plus qu\u2019une seule erreur, la 404 sur <i>security.debian.org<\/i>. Avec un message d\u2019erreur clair, on peut avancer : effectivement, le fichier <i>http:\/\/security.debian.org\/dists\/squeeze\/updates\/contrib\/binary-i386\/Packages<\/i> n\u2019existe plus. Cette <a href=\"https:\/\/wiki.debian.org\/fr\/LTS\/Using\">page d\u2019explication sur squeeze-lts<\/a> donne la raison :<\/p>\n<p><code>Le d\u00e9p\u00f4t security n'est plus n\u00e9cessaire dans la mesure o\u00f9 la derni\u00e8re version interm\u00e9diaire de squeeze a \u00e9t\u00e9 publi\u00e9e. Tous les paquets du d\u00e9p\u00f4t security ont \u00e9t\u00e9 copi\u00e9s dans le d\u00e9p\u00f4t main avec cette version.<\/code><\/p>\n<p style=\"text-align: justify;\">Donc dans le cas suivant :<\/p>\n<ul style=\"text-align: justify;\">\n<li>votre FAI est Free<\/li>\n<li>vous avez choisi le d\u00e9p\u00f4t <i>ftp.fr.debian.org<\/i><\/li>\n<li>un autre d\u00e9p\u00f4t utilis\u00e9 par votre <i>\/etc\/apt\/sources.list<\/i> retourne une erreur 404.<\/li>\n<\/ul>\n<p style=\"text-align: justify;\">On peut se retrouver avec ces erreurs \u00ab 406 Not Acceptable \u00bb, ce qui signifie un \u00e9chec de n\u00e9gociation entre client et serveur sur le type de r\u00e9ponse. Ce qui est \u00e9trange, c\u2019est que d\u2019une part en s\u00e9lectionnant le d\u00e9p\u00f4t <i>ftp.debian.org<\/i> (ce qui revient \u00e0 aller sur un autre miroir que celui de Free) on n\u2019obtient plus les erreurs 406, alors que la 404 est toujours l\u00e0. D\u2019autre part, en admettant que le miroir de Free ait une configuration particuli\u00e8re, les erreurs 406 ne surviennent que lorsque un autre d\u00e9p\u00f4t renvoit une 404.<\/p>\n<p style=\"text-align: justify;\">En conclusion, il vaut mieux pointer vers <i>ftp.debian.org<\/i>, et mettre son propre cache APT pour soulager les serveurs Debian.<\/p>\n<p style=\"text-align: justify;\">Je vous conseille apt-cacher-ng. Par le pass\u00e9, j\u2019avais eu des ennuis avec d\u2019autres outils faisant cache APT. Depuis que je suis pass\u00e9 \u00e0 apt-cacher-ng, tout marche de mani\u00e8re transparente (ou presque, je dois le relancer une ou deux fois par an quand un <i>apt-get update<\/i> bloque, \u00e7a se limite \u00e0 \u00e7a).<\/p>\n","protected":false},"excerpt":{"rendered":"<p>J\u2019ai remis en service un conteneur VZ qui n\u2019avait pas \u00e9t\u00e9 d\u00e9marr\u00e9 depuis plusieurs mois. Je le laisse en squeeze tant que le support de squeeze-lts continue, \u00e0 cause d\u2019un logiciel qui exige de vieilles d\u00e9pendances. En voulant appliquer les mises \u00e0 jour de s\u00e9curit\u00e9, apt-get update \u00e9chouait, et les messages d\u2019erreur n\u2019\u00e9taient pas clairs.<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[5],"tags":[],"class_list":["post-205","post","type-post","status-publish","format-standard","hentry","category-debian","radius"],"_links":{"self":[{"href":"https:\/\/almic.fr\/blog\/wp-json\/wp\/v2\/posts\/205","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/almic.fr\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/almic.fr\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/almic.fr\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/almic.fr\/blog\/wp-json\/wp\/v2\/comments?post=205"}],"version-history":[{"count":29,"href":"https:\/\/almic.fr\/blog\/wp-json\/wp\/v2\/posts\/205\/revisions"}],"predecessor-version":[{"id":512,"href":"https:\/\/almic.fr\/blog\/wp-json\/wp\/v2\/posts\/205\/revisions\/512"}],"wp:attachment":[{"href":"https:\/\/almic.fr\/blog\/wp-json\/wp\/v2\/media?parent=205"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/almic.fr\/blog\/wp-json\/wp\/v2\/categories?post=205"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/almic.fr\/blog\/wp-json\/wp\/v2\/tags?post=205"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}