Semble être lié à #23202.

Même problème sur Debian Trusty

W: Failed to fetch https://apt.dockerproject.org/repo/dists/ubuntu-trusty/main/binary-amd64/Packages  Hash Sum mismatch

E: Some index files failed to download. They have been ignored, or old ones used instead.

Problème similaire sur Travis CI avec le package Ubuntu. Il fonctionnait il y a une heure.

https://travis-ci.org/goalgorilla/drupal_social/builds/134719276

W: There is no public key available for the following key IDs:
1397BC53640DB551
W: Failed to fetch https://apt.dockerproject.org/repo/dists/ubuntu-trusty/main/binary-amd64/Packages  Hash Sum mismatch
E: Some index files failed to download. They have been ignored, or old ones used instead.

Idem sur Debian Jessie :
W: Failed to fetch https://apt.dockerproject.org/repo/dists/debian-jessie/main/binary-amd64/Packages Hash Sum mismatch

Peut facilement être reproduit dans un récipient également :

FROM debian:8.4

RUN \
  apt-get update && \
  apt-get install -yq apt-transport-https ca-certificates && \
  apt-key adv --keyserver hkp://p80.pool.sks-keyservers.net:80 --recv-keys 58118E89F3A912897C070ADBF76221572C52609D && \
  echo "deb https://apt.dockerproject.org/repo debian-jessie main" > /etc/apt/sources.list.d/docker.list && \
  apt-get update

Qu'en est-il de apt-get clean ? Aide-t-il?

@Vanuan Non, déjà essayé.

_SONDAGE UTILISATEUR_

_La meilleure façon d'être informé des mises à jour est d'utiliser le bouton _S'abonner_ sur cette page._

Veuillez ne pas utiliser les commentaires "+1" ou "J'ai cela aussi" sur les problèmes. Nous automatiquement
recueillir ces commentaires pour garder le fil court.

Les personnes listées ci-dessous ont voté pour ce problème en laissant un commentaire +1 :

@ViGo5190

Pareil ici!

Failed to fetch https://apt.dockerproject.org/repo/dists/ubuntu-trusty/main/binary-amd64/Packages  Hash Sum mismatch

Choses que nous avons essayées jusqu'à présent :

Rajouter la clé GPG
curl -fsSL https://get.docker.com/gpg | sudo apt-key add -

Faire exploser le cache des listes
sudo rm -rf /var/lib/apt/lists/*

Appartement propre
apt-clean

Aucun d'entre eux n'a résolu le problème

J'ai essayé d'installer via apt. La somme de contrôle ne correspond pas au fichier suivant :

https://apt.dockerproject.org/repo/dists/ubuntu-trusty/main/binary-amd64/Packages

J'ai essayé les procédures suivantes qui n'ont pas aidé:

sudo rm -rf /var/lib/apt/lists/*

Peut-être que cela aiderait apt-get -o Debug::pkgAcquire::Auth=true update à comprendre le problème.

La version contient :
Somme MD5 :
49df2d605bb5914873fd826f7e7e8c6f 4917 Forfaits.bz2

InRelease contient :
b013253c327e2bc4be87825f02936344 4915 main/binary-amd64/Packages.bz2

ce dernier a été mis à jour aujourd'hui, Date: Thu, 02 Jun 2016 11:06:54 UTC
tandis que Release date d'hier.

L'exécution apt-get -o Debug::pkgAcquire::Auth=true update sur Ubuntu 14.04 donne des rendements

[Waiting for headers]201 URI Done: bzip2:/var/lib/apt/lists/partial/apt.dockerproject.org_repo_dists_ubuntu-trusty_main_binary-amd64_Packages
RecivedHash: SHA512:d6ca1f74e876031161d1abd6cf9ad0b45f60b19876468cfcf9cacd4956dfd13be43147227a8daa5536f1455bb75b353b178942bc1843d11f0188d00117483912
ExpectedHash: SHA512:d07a3f2c42a9b213e3f03f2f11c08154512baa9fbbaed19f3601865634b82cfdde0e65151a24e523017f29ecfd08a1dfc0af2c2117b025c46d683160892b0de6


https://apt.dockerproject.org/repo/dists/ubuntu-trusty/main/binary-amd64/Packages: 
Computed Hash: SHA512:d6ca1f74e876031161d1abd6cf9ad0b45f60b19876468cfcf9cacd4956dfd13be43147227a8daa5536f1455bb75b353b178942bc1843d11f0188d00117483912  
Expected Hash: SHA512:d07a3f2c42a9b213e3f03f2f11c08154512baa9fbbaed19f3601865634b82cfdde0e65151a24e523017f29ecfd08a1dfc0af2c2117b025c46d683160892b0de6

Sortie pertinente de apt-get -o Debug::pkgAcquire::Auth=true update :

Got Codename: debian-stretch
Expecting Dist:
Transformed Dist:
Signature verification succeeded: /var/lib/apt/lists/partial/apt.dockerproject.org_repo_dists_debian-stretch_InRelease
Get:2 https://apt.dockerproject.org/repo debian-stretch/main amd64 Packages [4,941 B]
0% [Connecting to ftp.de.debian.org] [Connecting to security.debian.org] [Connecting to mirror.netcologne.de] [Connecting to packages.dotdeb.org] [Connecting to www.deb-multimedia.org] [Connecting to ftp-stud.hs-esslingen.de] [Connecting201 URI Done: https://apt.dockerproject.org/repo/dists/debian-stretch/main/binary-amd64/Packages.bz2
ReceivedHash:
    - SHA512:14844ddc767052951fb68eabc19a1935fb930c798d64fd86ace0dcce3aad2af887fc091ad90897a52f341f65dadac5f0dc31a35f9c70b5bcc582314187a336cf
    - SHA256:0cee3ef5330e133cc6dfbf3d34f118806ce685a1ded4210c5c4f7ef7b43e9867
    - SHA1:bcf84731c3d9fe4355ce73b3cd756decbf9b67cb
    - MD5Sum:c99614887831f4d020e682c8222fe49b
    - Checksum-FileSize:4933
ExpectedHash:
    - Checksum-FileSize:4941
    - SHA512:5de62937921a32be2e9cf14f65e6adda3499fd648f37ab5ccc9547a03d211be66c3a5cd15f272e5a3f0abc53fec3903f646410337917e4201bf2a7ed5ac8581d
    - SHA256:ebc0ec8921482f40bdcf1fa9a7f39b7bd198d81a769643723201c109b3b617ea
    - SHA1:a61818ebafdccbccdfdeee5e550b9241b8c32722
    - MD5Sum:9cd9390adc1849ba5923a70d92af1927

https://travis-ci.org/goalgorilla/drupal_social/builds/134730044

Get:11 https://apt.dockerproject.org ubuntu-trusty/main amd64 Packages
201 URI Done: https://apt.dockerproject.org/repo/dists/ubuntu-trusty/main/binary-amd64/Packages.bz2
RecivedHash: SHA512:36e068ae0288732c51bd971ee74b6d27c8707f4d11840afcca617884de82e8c533c5259d8d97bb297966424bc58ac219879f4f5d12c4abe073799bb658f4bd87
ExpectedHash: SHA512:d07a3f2c42a9b213e3f03f2f11c08154512baa9fbbaed19f3601865634b82cfdde0e65151a24e523017f29ecfd08a1dfc0af2c2117b025c46d683160892b0de6

Je monte sur Ubuntu Wily 15.10

E : Impossible de localiser le package docker-engine

J'ai eu la même chose auparavant sur Ubuntu Xenial 16.04. Docker est-il encore ajouté au dépôt Xenial ?

Sortie pertinente de apt-get -o Debug::pkgAcquire::Auth=true update :

Got Codename: ubuntu-xenial
Expecting Dist: 
Transformed Dist: 
Signature verification succeeded: /var/lib/apt/lists/partial/apt.dockerproject.org_repo_dists_ubuntu-xenial_InRelease
Holen:12 https://apt.dockerproject.org/repo ubuntu-xenial/main amd64 Packages [1.712 B]
Ign:12 https://apt.dockerproject.org/repo ubuntu-xenial/main amd64 Packages
Holen:12 https://apt.dockerproject.org/repo ubuntu-xenial/main amd64 Packages [1.430 B]
Ign:12 https://apt.dockerproject.org/repo ubuntu-xenial/main amd64 Packages
Holen:12 https://apt.dockerproject.org/repo ubuntu-xenial/main amd64 Packages [4.815 B]
100% [12 Packages 4.815 B/4.815 B 100%]201 URI Done: https://apt.dockerproject.org/repo/dists/ubuntu-xenial/main/binary-amd64/Packages
ReceivedHash:
    - SHA512:c7883bb7a1d0b5162431576408644a85003be4601724b6f2db275cd4b603a61f8dcd924e80158c40413942519c8a528f7940ffbe5370daa4b0a0d867afe3163d
    - SHA256:de12840d76e571cb6f42e63ac570c59d5332d772fb295b6919d12214052bfa6b
    - SHA1:9f9c05d3b7d8ca13e9e03c4f0f12757816f02301
    - MD5Sum:65e1f5c451c230a091118b468c31bae7
    - Checksum-FileSize:4815
ExpectedHash:
    - Checksum-FileSize:4815
    - SHA512:2becf6c2b9aae5b6823ea6d9f12988e22905a87a9a03fed844a761698eee614899d7b039e081e0b330539e716918b75e87a96c287a5efbe9fc3e847d44657798
    - SHA256:f4ae20e2259740699fba3a79dd7fb557c472d172b578798071274f7ba4c400f3
    - SHA1:8f34563e8170c5698dc7ba04dd3cf4c8a93100cf
    - MD5Sum:31d143b7a15a8a38bc92a7559c995078

Pouvons-nous nous mettre d'accord sur le fait que les hashsums sont incorrects/le dépôt nécessite une action administrative ?

J'ai contourné ce problème en téléchargeant le nouveau package manuellement et en l'installant à l'aide dpkg

curl -OL https://apt.dockerproject.org/repo/pool/main/d/docker-engine/docker-engine_1.11.2-0~trusty_amd64.deb
dpkg -i docker-engine*.deb

Malheureusement, l'installation de dpkg ne semble pas bien fonctionner sur Travis.

De plus, c'est ce qui m'arrive lors de l'installation manuelle sur Debian Stretch, en utilisant https://apt.dockerproject.org/repo/pool/main/d/docker-engine/docker-engine_1.11.2-0~stretch_amd64.deb :

$ sudo systemctl status docker.service
● docker.service - Docker Application Container Engine
   Loaded: loaded (/lib/systemd/system/docker.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Thu 2016-06-02 14:46:59 CEST; 58s ago
     Docs: https://docs.docker.com
 Main PID: 31269 (code=exited, status=1/FAILURE)

Jun 02 14:46:58 penny systemd[1]: Starting Docker Application Container Engine...
Jun 02 14:46:58 penny docker[31269]: time="2016-06-02T14:46:58.553905409+02:00" level=info msg="New containerd process, pid: 31293\n"
Jun 02 14:46:59 penny docker[31269]: time="2016-06-02T14:46:59.659258835+02:00" level=error msg="[graphdriver] prior storage driver \"aufs\" failed: driver not supported"
Jun 02 14:46:59 penny docker[31269]: time="2016-06-02T14:46:59.659395935+02:00" level=fatal msg="Error starting daemon: error initializing graphdriver: driver not supported"
Jun 02 14:46:59 penny systemd[1]: docker.service: Main process exited, code=exited, status=1/FAILURE
Jun 02 14:46:59 penny docker[31269]: time="2016-06-02T14:46:59+02:00" level=info msg="stopping containerd after receiving terminated"
Jun 02 14:46:59 penny systemd[1]: Failed to start Docker Application Container Engine.
Jun 02 14:46:59 penny systemd[1]: docker.service: Unit entered failed state.
Jun 02 14:46:59 penny systemd[1]: docker.service: Failed with result 'exit-code'.

Mise à jour : Comme je m'y attendais, il s'agissait d'un problème sans rapport. Je l'ai corrigé en exécutant rm -rf /var/lib/docker/aufs après avoir trouvé this . Donc, l'installation manuelle fonctionne pour moi pour le moment.

ping @mlaventure @tiborvass PTAL !

ET?

oui nous avons aussi besoin d'un ETA, c'est assez urgent - notre chaîne complète de construction de travis est morte maintenant -.-

Voici les fichiers pertinents pour xenial,
https://apt.dockerproject.org/repo/dists/ubuntu-xenial/main/binary-amd64/

InRelease        02-Jun-2016 11:06  2.6K
Packages          02-Jun-2016  2:38  4.8K
Packages.bz2  02-Jun-2016  2:38  1.7K
Packages.gz    02-Jun-2016  2:38  1.4K
Release            02-Jun-2016  3:43  1.7K
Release.gpg    02-Jun-2016  3:43  801

Nous pouvons voir que ces fichiers ont été régénérés plus tôt dans la journée.
Les sommes de contrôle (hachages) de ces fichiers doivent correspondre à ce qui se trouve dans le fichier de sommes de contrôle InRelease signé.

Dans le fichier InRelease (https://apt.dockerproject.org/repo/dists/ubuntu-xenial/main/binary-amd64/InRelease), il est indiqué que ce fichier a été généré le Date: Thu, 02 Jun 2016 03:43:32 UTC . Cependant, l'horodatage affiché par le serveur Web est 02-Jun-2016 11:06 .

Parmi les nombreuses causes de Hash Sum Mismatch , celle-ci concerne une mise à jour étrange de InRelease avec de mauvaises sommes de contrôle. De plus, InRelease répertorie les Release comme ayant une longueur de 0 octet.

@simos Donc, cela devrait fonctionner sur Xenial maintenant ? Je pensais que docker ne fonctionnait toujours pas sur Xenial et nous devions retourner à Wily. (encore une fois, je suis un utilisateur d'Ubuntu depuis aujourd'hui, alors qu'est-ce que je sais)

@bmoorthamers Vous pouvez vérifier manuellement quels référentiels ont des hachages incompatibles. Voir mon message ci-dessus. Au moins trusty , wily et xenial sont actuellement (probablement depuis plus tôt dans la matinée) affectés.

J'utilise, en attendant le correctif du package principal, le package expérimental, qui fonctionne. est-ce que quelqu'un sait s'il y a de grandes différences dont je dois être conscient, ou y a-t-il quelque part un document les décrivant?

@theluk la version expérimentale est actuellement construite à partir du maître

Pour donner une mise à jour ; J'ai soulevé ce problème en interne, mais les personnes nécessaires pour résoudre ce problème se trouvent dans le fuseau horaire de San Francisco, elles ne sont donc pas encore présentes.

Comme solution de contournement temporaire, vous pouvez installer docker 1.11.2-rc1 à partir du référentiel "test" ; La 1.11.2-rc1 est presque la même que la version actuelle, à part ces trois modifications ;
https://github.com/docker/docker/pull/23164 , https://github.com/docker/docker/pull/23169 et https://github.com/docker/docker/pull/23176

Ces changements ne devraient pas faire de différence fonctionnelle (et le dernier changement n'affecte que certains cas particuliers)

Vous pouvez installer le RC, soit en changeant le référentiel "main" en "test" pour APT, soit en utilisant le script d'installation ;

curl -fsSL https://test.docker.com | sh

En espérant régler ce problème au plus vite

Pour déterminer si ce problème est résolu, vous pouvez visiter, par exemple, la page à l' adresse https://apt.dockerproject.org/repo/dists/ubuntu-xenial/main/binary-amd64/ et vérifier l'horodatage du InRelease Fichier

Actuellement, il indique toujours 11:06 (UTC) qui est la version du fichier qui a les mauvaises sommes de contrôle. S'il indique une date ultérieure, cela a probablement été corrigé.

Il est maintenant 13:25 (UTC) et nous attendons toujours.

Merci les gars!

merci @thaJeztah l' installation du test a bien fonctionné !

Même problème avec Ubuntu Trusty sur Travis CI :

W: Failed to fetch https://apt.dockerproject.org/repo/dists/ubuntu-trusty/main/binary-amd64/Packages  Hash Sum mismatch

Pour donner une mise à jour ; J'ai soulevé ce problème en interne, mais les personnes nécessaires pour résoudre ce problème se trouvent dans le fuseau horaire de San Francisco, elles ne sont donc pas encore présentes.

Cela signifie-t-il que Docker, une grande entreprise d'infrastructure, n'a pas d'ingénieurs disponibles sur appel pour résoudre ce problème ?

@mlafeldt suppose que vous n'avez pas payé pour une assistance 24h/24 et 7j/7.

Le support commercial de @mlafeldt le fait ; l'open source est une infrastructure distincte

Je suis également confronté au même problème sur Wily et je ne peux pas installer Docker :

root@vikram-VirtualBox :/etc/apt/sources.list.d# cat docker.list
deb https://apt.dockerproject.org/repo ubuntu-wily principal

> chat /etc/_release_

DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=15.10
DISTRIB_CODENAME=rusé
DISTRIB_DESCRIPTION="Ubuntu 15.10"
NOM="Ubuntu"
VERSION="15.10 (Loup-garou astucieux)"
identifiant=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 15.10"
VERSION_ID="15.10"
HOME_URL=" http://www.ubuntu.com/ "
SUPPORT_URL=" http://help.ubuntu.com/ "
BUG_REPORT_URL=" http://bugs.launchpad.net/ubuntu/ "

>sudo rm -rf /var/lib/apt/lists/*

>rm /etc/apt/trusted.gpg

> sudo apt-get clean

> sudo apt-obtenir la mise à jour

Cliquez sur http://in.archive.ubuntu.com wily-backports/main Translation-en
Cliquez sur http://in.archive.ubuntu.com wily-backports/universe Translation-en
Récupéré 4 789 B en 33 s (145 B/s)
W : Impossible de récupérer https://apt.dockerproject.org/repo/dists/ubuntu-wily/main/binary-amd64/Packages Hash Sum incompatible
E : Certains fichiers d'index n'ont pas pu être téléchargés. Ils ont été ignorés ou d'anciens ont été utilisés à la place.

> apt-get -o Debug::pkgAcquire::Auth=true mise à jour

http://in.archive.ubuntu.com/ubuntu/dists/wily-backports/universe/i18n/Translation-en : Computed Hash: SHA256: c03ff8f13394e66ce3b2d4645e779e658df189f96326c6eaa8f137a08eb0df30 Hash attendu: SHA256: c03ff8f13394e66ce3b2d4645e779e658df189f96326c6eaa8f137a08eb0df30
Récupéré 737 ko en 28 s (26,0 ko/s)
W : Impossible de récupérer https://apt.dockerproject.org/repo/dists/ubuntu-wily/main/binary-amd64/Packages Hash Sum incompatible

https://apt.dockerproject.org/repo/dists/ubuntu-wily/main/binary-amd64/
../
InRelease 02-juin-2016 11:06 2.6K
Forfaits 02-juin-2016 2:37 28K
Packages.bz2 02-Jun-2016 2:37 4.7K
Packages.gz 02-Jun-2016 2:37 4.5K
Sortie 02 juin 2016 3:43 1.7K
Version.gpg 02-Jun-2016 3:43 801

Nous pouvons voir que ces fichiers ont été régénérés plus tôt dans la journée.
Les sommes de contrôle (hachages) de ces fichiers doivent correspondre à ce qui se trouve dans le fichier InRelease signé des sommes de contrôle.
Dans InRelease https://apt.dockerproject.org/repo/dists/ubuntu-wily/main/binary-amd64/InRelease , il est indiqué que ce fichier a été généré le Date : Thu, 02 Jun 2016 03:43:32 UTC . Cependant, l'horodatage affiché par le serveur Web est 02 juin 2016 11:06.

Je suis stupéfait que ce processus ne soit pas automatisé avec les sommes de contrôle calculées indépendamment par des conteneurs Docker séparés et en cas de calcul contesté entre eux, le téléchargement est suspendu jusqu'à ce qu'un humain puisse intervenir.

@thaJeztah donc il y a un repo différent pour les utilisateurs commerciaux qui n'est pas cassé?

Voici un script pour qu'Ubuntu soit averti par un carillon (joue un fichier audio) lorsque les sommes de contrôle du référentiel sont mises à jour,
https://gist.github.com/simos/7ee8258ec17101e44bbfa93606694ede

Je pense qu'il n'y a pas grand chose à dire à part obtenir une réponse officielle de Docker à ce sujet.

@ krak3n oui, il existe des versions distinctes pour la version prise en charge commercialement.

Pour les personnes utilisant Travis, je pourrais le réparer en procédant comme suit :

before_install:
- sudo apt-get install libsystemd-journal0
- pushd /tmp
- curl -OL https://apt.dockerproject.org/repo/pool/main/d/docker-engine/docker-engine_1.10.2-0~trusty_amd64.deb
- sudo dpkg --force-all -i docker-engine*.deb
- docker -v
- popd

@thaJeztah à la fois en changeant le référentiel "principal" en "test" pour APT, ou en utilisant le script d'installation ;
curl -fsSL https://test.docker.com | sh ne fonctionnent pas.

W : Échec de la récupération de https://apt.dockerproject.org/repo/dists/ubuntu-trusty/InRelease Impossible de trouver l'entrée attendue "test/binary-amd64/Packages" dans le fichier de version (entrée sources.list incorrecte ou fichier mal formé )

E : Certains fichiers d'index n'ont pas pu être téléchargés. Ils ont été ignorés ou d'anciens ont été utilisés à la place.

@xuedong09 au lieu de "test", utilisez "testing"

J'ai tweeté @docker @dockerstatus (plusieurs fois)... c'est un problème majeur... surpris qu'ils soient si silencieux !

Nous y travaillons, les amis.

Merci @crunis - ce correctif Travis fonctionne à merveille.

Merci d'avoir travaillé à résoudre ce problème. Ce serait formidable si vous publiiez les résultats de l'autopsie une fois fixés.

Merci @hertzg et @thaJeztah de changer le référentiel "principal" en "testing" pour le travail APT pour moi.

@ xuedong09 N'oubliez pas que c'est là que nous publions les packages de pré-version.

Un point de défaillance unique si intéressant pour l'écosystème docker

@babakgh J'y pensais aussi. Espérons que l'autopsie puisse suggérer une bonne future prévention.

Cela m'affecte aussi.

Je reçois toujours : https://apt.dockerproject.org/repo/dists/debian-jessie/main/binary-amd64/Packages Hash Sum mismatch

Cela me rappelle ce qui s'est passé avec npm et NodeJS :

http://www.thejournal.ie/programmer-break-internet-code-2679793-Mar2016/

Et un autre, moi aussi

W: Failed to fetch https://apt.dockerproject.org/repo/dists/debian-jessie/main/binary-amd64/Packages Hash Sum mismatch

Responsables du dépôt Docker. Vous avez besoin:

• Test automatique des modifications
• Bilan de santé de votre dépôt
• essentiellement la surveillance et les alarmes

J'espère que cela ne se reproduira plus jamais. Docker causait des problèmes de test de production et de déploiement ici (sur TravisCI) avec cela bien que je n'utilise pas un seul conteneur Docker en production. 😑

À tous les râleurs et rageurs :

Il existe une version commerciale, payante et bien prise en charge de Docker.

Pour votre information, il s'agit de la version communautaire, prise en charge au mieux et PAS PLUS.

@vadviktor Est-ce la position officielle de Docker, parce que j'aimerais la citer ?

@therealmarv Ce problème ne devrait de toute façon pas affecter votre production ni aucun pipeline de déploiement, car personne ne devrait compter sur une connexion Internet ou un référentiel externe pour créer et déployer des logiciels.

@vadviktor Le meilleur effort ne signifie pas faire tomber tout le monde. Cela signifie que les petits bugs et défauts sont éventuellement examinés. Vous devez toujours faire en sorte que tout fonctionne dans les meilleurs scénarios.

Pour Ubuntu Trusty (14.04), le passage du référentiel APT "principal" au "test" a très bien fonctionné pour moi.

+1

Je ne savais pas que Docker était une organisation à 2 niveaux où la base d'utilisateurs est divisée entre les nantis et les démunis. L'installation de Docker surly est une préoccupation mondiale pour tous ceux qui utilisent le logiciel et, par conséquent, le support dont bénéficient les personnes "commerciales" devrait également s'appliquer à la communauté. Un niveau payant pour une organisation est un bon moyen de gagner de l'argent, mais cela devrait aller au-delà des bases, comme pouvoir installer votre logiciel.

Les accidents se produisent, c'est la façon dont nous les traitons et les leçons que nous en tirons qui comptent. La plupart de ce fil semble être effréné avec la spéculation. Merci d'avance à tous les membres de l'équipe Docker qui travaillent à la résolution de ce problème.

@vadviktor Vous travaillez chez Docker ?

@vadviktor Où puis-je trouver ce référentiel apt commercial ? Quel produit dois-je acheter pour y avoir accès ?

@vadviktor Ne travaille pas chez Docker ni ne maintient le projet.

@qzio voir http://www.docker.com/docker-support-services

Cela semble fonctionner pour Ubuntu Xenial maintenant.

Pour info, ce numéro est sur HN https://news.ycombinator.com/item?id=11822562

pour tous ceux qui font rage pendant ce temps d'arrêt : voici une jolie photo de cerf pour se calmer et passer le temps en attendant :

Trusty semble être de retour

Salut à tous. Je travaille chez Docker.

Tout d'abord, mes excuses pour la panne. Je considère notre infrastructure de packages comme une infrastructure critique, à la fois pour les versions gratuites et commerciales de Docker. Il est vrai que nous offrons un meilleur support pour la version commerciale (c'est l'une de ses fonctionnalités), mais cela ne devrait pas s'appliquer à des choses fondamentales comme pouvoir télécharger vos packages.

L'équipe travaille sur le problème et continuera à donner des mises à jour ici. Nous prenons cela au sérieux.

Certains d'entre vous ont souligné que le temps de réponse et l'utilisation des canaux de communication semblent inadéquats, par exemple le bot @dockerststus n'a pas mentionné le problème lors de sa détection. Je partage l'avis mais je ne connais pas encore toute l'histoire; l'autopsie nous dira avec certitude ce qui s'est passé. Pour le moment, l'équipe se concentre sur la résolution du problème et je ne veux pas les distraire de cela.

Une fois que l'autopsie aura identifié ce qui n'a pas fonctionné, nous prendrons les mesures correctives appropriées. Je soupçonne qu'une partie de cela sera une meilleure coordination entre les ingénieurs de base et les ingénieurs d'infrastructure (2 groupes distincts au sein de Docker).

Merci et encore désolé pour la gêne occasionnée.

heh - j'ai le catalogue mais le paquet est manquant - je suppose que je vais prendre un autre café :-)
@shykes Merci pour la mise à jour - mauvaise façon de commencer votre matinée ...
J'espère que la journée s'améliorera à partir d'ici

Je suis triste que ma photo de cerf ait obtenu moins de +1 que la réponse officielle.

J'ai déjà installé docker avec https://get.docker.com | sh sans aucune erreur.
On dirait que les gars de Docker ont résolu le problème,

Nous avons localisé la cause du problème, et si cela doit être résolu maintenant, veuillez réessayer.

Il peut être nécessaire d'effacer le apt-cache ;

apt-get clean && apt-get update

Merci pour le correctif @thaJeztah

Eh bien, c'était rapide pour un problème inattendu, merci.

@snario vous êtes le bienvenu ; Je ne peux pas m'attribuer le mérite du correctif, mais je suis heureux de voir que tout a été réglé 😅

👍

Malheureusement, avec cela au sommet des nouvelles sur les hackers, il y aura des milliards de commentaires. Un grand merci pour la solution rapide @thaJeztah.

Je me demande si nous devrions verrouiller ce fil avant qu'ils n'apparaissent.

Jusqu'à présent, il y a eu workarounds (soit récupérez le .deb et installez-le avec dpkg, passez temporairement au référentiel testing , etc.). Ce ne sont pas des solutions permanentes.

Un fix signifie que la source de ce problème est résolue et que nous pouvons marquer ce problème comme Résolu.

Comme indiqué précédemment, vous pouvez utiliser un script pour obtenir une notification audio dès que les principaux référentiels de docker sont corrigés,
https://gist.github.com/simos/7ee8258ec17101e44bbfa93606694ede
A part ça, il n'y a pas grand chose à faire.

@simos voir mon commentaire précédent ; https://github.com/docker/docker/issues/23203#issuecomment -223328829 le problème devrait être résolu

@thaJeztah J'ai vérifié que le problème a été résolu. Testé sur Ubuntu 15.10. Merci à tous les autres membres de Docker qui ont aidé à résoudre ce problème rapidement.

Merci à tous pour les rapports : nous en sommes vraiment désolés. Nous examinons les détails et la chronologie des événements qui ont conduit à cela, et nous ferons en sorte que cela ne se reproduise plus.

Je ferme le sujet, mais bien sûr n'hésitez pas à me faire savoir si vous voyez des bizarreries restantes.

Ubuntu 14.04 Ici, problème résolu !

Cela ne devrait probablement pas être surpris, mais il est choquant de voir combien de personnes risquent leur infrastructure avec des dépendances dures sur des dépôts externes. Je ne fais même pas ça avec mes systèmes domestiques.

Et puis se plaindre du fait que Docker ait un point de défaillance unique ?

@jalawrence Docker n'est que la pointe de l'iceberg...
Avez-vous entendu parler des problèmes récents avec node.js et un développeur sortant un seul paquet ?
Je suis à peu près sûr que la plupart des développeurs php utilisant Composer - le gestionnaire de paquets de facto pour cette plate-forme - ne stockent pas non plus de copies complètes de toutes les dépendances de leur site, et le fait qu'il n'y ait eu aucun incident jusqu'à présent est plus de chance qu'autre chose.
Le problème est que tout le monde et son chien dépendent maintenant de $world, et la mise en cache de toutes les dépendances localement est une tâche sisyphe. Dois-je mettre en cache tout debian, tout packagist, tout cpan, tout rubygems, tout npm dans un reverse proxy à mes propres frais ?
Et puis : si github, bitbucket ou travis sont en panne, que pourront faire mes développeurs de toute façon ? Est-ce que je veux revenir au jour où j'ai dû héberger tout cela ?