Scheint mit #23202 verwandt zu sein.

Dasselbe Problem bei 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.

Ähnliches Problem bei Travis CI mit Ubuntu-Paket. Vor einer Stunde hat es noch funktioniert.

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.

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

Kann auch leicht in einem Container reproduziert werden:

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

Was ist mit apt-get clean ? Hilft es?

@Vanuan Nein, schon probiert.

_USER-UMFRAGE_

_Der beste Weg, um über Updates benachrichtigt zu werden, ist die Verwendung der Schaltfläche _Abonnieren_ auf dieser Seite._

Bitte verwenden Sie keine „+1“- oder „Das habe ich auch“-Kommentare zu Problemen. Wir automatisch
Sammeln Sie diese Kommentare, um den Thread kurz zu halten.

Die unten aufgeführten Personen haben dieses Problem positiv bewertet, indem sie einen +1-Kommentar hinterlassen haben:

@ViGo5190

Hier gilt das gleiche!

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

Dinge, die wir bisher ausprobiert haben:

Fügen Sie den GPG-Schlüssel erneut hinzu
curl -fsSL https://get.docker.com/gpg | sudo apt-key add -

Sprengen Sie den Listen-Cache
sudo rm -rf /var/lib/apt/lists/*

Passend sauber
apt-clean

Keiner von ihnen hat das Problem gelöst

Habe versucht über apt zu installieren. Nichtübereinstimmung der Prüfsumme mit der folgenden Datei:

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

Versuchte die folgenden Verfahren, die nicht halfen:

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

Vielleicht hilft das apt-get -o Debug::pkgAcquire::Auth=true update das Problem zu lösen.

Freigabe enthält:
MD5Summe:
49df2d605bb5914873fd826f7e7e8c6f 4917 Pakete.bz2

InRelease enthält:
b013253c327e2bc4be87825f02936344 4915 main/binary-amd64/Packages.bz2

letzteres wurde heute aktualisiert, Datum: Donnerstag, 02. Juni 2016 11:06:54 UTC
während Release von gestern ist.

Das Ausführen apt-get -o Debug::pkgAcquire::Auth=true update unter Ubuntu 14.04 ergibt Ergebnisse

[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

Relevante Ausgabe von 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

Ich bekomme auf Ubuntu Wily 15.10

E: Paket docker-engine kann nicht gefunden werden

Ich hatte das gleiche zuvor auf Ubuntu Xenial 16.04. Ist Docker überhaupt schon zum Xenial-Repo hinzugefügt worden?

Relevante Ausgabe von 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

Können wir uns darauf einigen, dass die Hashsummen falsch sind/das Repo administrative Maßnahmen erfordert?

Ich habe dies umgangen, indem ich das neue Paket manuell heruntergeladen und mit dpkg installiert habe

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

Leider scheint die Installation von dpkg auf Travis nicht gut zu laufen.

Folgendes passiert mir auch bei der manuellen Installation auf Debian Stretch mit 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'.

Update : Wie ich irgendwie erwartet hatte, war dies ein unabhängiges Problem. Ich habe es behoben, indem ich rm -rf /var/lib/docker/aufs ausgeführt habe, nachdem ich dies gefunden hatte . Also die manuelle Installation funktioniert bei mir vorerst.

ping @mlaventure @tiborvass PTAL!

UND?

Ja, wir brauchen auch eine ETA, es ist ziemlich dringend - unsere komplette Travis-Baukette ist jetzt tot -.-

Hier sind die relevanten Dateien für 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

Wir können sehen, dass diese Dateien heute früher neu generiert wurden.
Die Prüfsummen (Hashes) für diese Dateien sollten mit dem übereinstimmen, was sich in der signierten InRelease -Prüfsummendatei befindet.

In der Datei InRelease (https://apt.dockerproject.org/repo/dists/ubuntu-xenial/main/binary-amd64/InRelease) steht, dass diese Datei auf Date: Thu, 02 Jun 2016 03:43:32 UTC generiert wurde 02-Jun-2016 11:06 .

Unter den verschiedenen Ursachen für Hash Sum Mismatch handelt es sich hier um ein seltsames Update von InRelease mit falschen Prüfsummen. Außerdem listet InRelease die Release als 0 Byte lang auf.

@simos Also sollte das jetzt auf Xenial funktionieren? Ich dachte, Docker funktionierte immer noch nicht auf Xenial und wir mussten zu Wily zurückkehren. (Andererseits bin ich seit heute ein Ubuntu-Benutzer, also was weiß ich)

@bmoorthamers Sie können manuell überprüfen, welche Repositories nicht übereinstimmende Hashes haben. Siehe meinen Beitrag oben. Mindestens trusty , wily und xenial sind derzeit (vermutlich seit früher morgens) betroffen.

Ich verwende, während ich auf die Hauptpaketkorrektur warte, das experimentelle Paket, das funktioniert. Weiß jemand, ob es einige große Unterschiede gibt, auf die ich achten muss, oder gibt es irgendwo ein Dokument, das sie beschreibt?

@theluk Der experimentelle Build wird derzeit vom Master erstellt

Um ein Update zu geben; Ich habe dieses Problem intern angesprochen, aber die Leute, die zur Behebung des Problems benötigt werden, befinden sich in der Zeitzone von San Francisco, also sind sie noch nicht anwesend.

Als vorübergehende Problemumgehung können Sie Docker 1.11.2-rc1 aus dem „test“-Repository installieren; 1.11.2-rc1 ist fast identisch mit der aktuellen Version, abgesehen von diesen drei Änderungen;
https://github.com/docker/docker/pull/23164 , https://github.com/docker/docker/pull/23169 und https://github.com/docker/docker/pull/23176

Diese Änderungen sollten keinen funktionalen Unterschied machen (und die letzte Änderung betrifft nur einige Eckfälle).

Sie können den RC installieren, indem Sie entweder das Repository „main“ in „test“ für APT ändern oder das Installationsskript verwenden;

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

In der Hoffnung, dass dies so schnell wie möglich behoben wird

Um herauszufinden, ob dieses Problem behoben ist, können Sie beispielsweise die Seite unter https://apt.dockerproject.org/repo/dists/ubuntu-xenial/main/binary-amd64/ besuchen und den Zeitstempel für das InRelease überprüfen

Derzeit steht dort immer noch 11:06 (UTC), was die Version der Datei ist, die die falschen Prüfsummen hat. Wenn es eine spätere Zeit sagt, dann wurde es wahrscheinlich behoben.

Jetzt ist es 13:25 (UTC) und wir warten immer noch.

Danke Leute!

danke @thaJeztah Installation von Test hat gut funktioniert!

Gleiche Probleme mit Ubuntu Trusty auf Travis CI:

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

Um ein Update zu geben; Ich habe dieses Problem intern angesprochen, aber die Leute, die zur Behebung des Problems benötigt werden, befinden sich in der Zeitzone von San Francisco, also sind sie noch nicht anwesend.

Bedeutet das, dass Docker – ein großes Infrastrukturunternehmen – keine Techniker auf Abruf zur Verfügung hat, um das Problem zu beheben?

@mlafeldt schätze, du hast nicht für den 24/7-Support bezahlt.

Der kommerzielle Support von @mlafeldt tut es; Open Source ist eine separate Infrastruktur

Ich habe auch das gleiche Problem auf Wily und kann Docker nicht installieren:

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

> Katze /etc/_release_

DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=15.10
DISTRIB_CODENAME=schlau
DISTRIB_DESCRIPTION="Ubuntu 15.10"
NAME="Ubuntu"
VERSION="15.10 (Schlauer Werwolf)"
ID=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-get update

Klicken Sie auf http://in.archive.ubuntu.com wily-backports/main Translation-en
Klicken Sie auf http://in.archive.ubuntu.com wily-backports/universe Translation-en
Abrufen von 4.789 B in 33 s (145 B/s)
W: Fehler beim Abrufen der https://apt.dockerproject.org/repo/dists/ubuntu-wily/main/binary-amd64/Packages-Hash-Summe-Nichtübereinstimmung
E: Einige Indexdateien konnten nicht heruntergeladen werden. Sie wurden ignoriert oder stattdessen alte verwendet.

> apt-get -o Debug::pkgAcquire::Auth=true aktualisieren

http://in.archive.ubuntu.com/ubuntu/dists/wily-backports/universe/i18n/Translation-en : Computed Hash: SHA256: c03ff8f13394e66ce3b2d4645e779e658df189f96326c6eaa8f137a08eb0df30 Erwartete Hash: SHA256: c03ff8f13394e66ce3b2d4645e779e658df189f96326c6eaa8f137a08eb0df30
737 kB in 28 s abgerufen (26,0 kB/s)
W: Fehler beim Abrufen der https://apt.dockerproject.org/repo/dists/ubuntu-wily/main/binary-amd64/Packages-Hash-Summe-Nichtübereinstimmung

https://apt.dockerproject.org/repo/dists/ubuntu-wily/main/binary-amd64/
../
InRelease 02.06.2016 11:06 2.6K
Pakete 02.06.2016 2:37 28K
Pakete.bz2 02.06.2016 2:37 4.7K
Packages.gz 02.06.2016 2:37 4.5K
Veröffentlichung 02.06.2016 3:43 1.7K
Release.gpg 02.06.2016 3:43 801

Wir können sehen, dass diese Dateien heute früher neu generiert wurden.
Die Prüfsummen (Hashes) für diese Dateien sollten mit dem übereinstimmen, was sich in der signierten InRelease-Prüfsummendatei befindet.
In InRelease https://apt.dockerproject.org/repo/dists/ubuntu-wily/main/binary-amd64/InRelease heißt es, dass diese Datei am Datum: Do, 02. Juni 2016 03:43:32 UTC generiert wurde. Der vom Webserver angezeigte Zeitstempel lautet jedoch 02. Juni 2016, 11:06 Uhr.

Ich bin verblüfft, dass dieser Prozess nicht automatisiert ist, wobei die Prüfsummen unabhängig von separaten Docker-Containern berechnet werden, und im Falle einer umstrittenen Berechnung zwischen ihnen wird der Upload zurückgehalten, bis ein Mensch eingreifen kann.

@thaJeztah , also gibt es ein anderes Repo für kommerzielle Benutzer, das nicht kaputt ist?

Hier ist ein Skript für Ubuntu, um durch ein Glockenspiel (spielt eine Audiodatei) benachrichtigt zu werden, wenn die Prüfsummen des Repositorys aktualisiert werden.
https://gist.github.com/simos/7ee8258ec17101e44bbfa93606694ede

Ich denke, es gibt nicht viel zu sagen, außer eine offizielle Antwort von Docker dazu zu bekommen.

@krak3n ja, es gibt separate Versionen für die kommerziell unterstützte Version.

Für Leute, die Travis verwenden, könnte ich es wie folgt beheben:

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 sowohl das "main"- als auch das "test"-Repository für APT ändern oder das Installationsskript verwenden;
curl -fsSL https://test.docker.com | sh sind keine Arbeit.

W: Fehler beim Abrufen von https://apt.dockerproject.org/repo/dists/ubuntu-trusty/InRelease Der erwartete Eintrag „test/binary-amd64/Packages“ konnte in der Release-Datei nicht gefunden werden (Falscher sources.list-Eintrag oder fehlerhafte Datei )

E: Einige Indexdateien konnten nicht heruntergeladen werden. Sie wurden ignoriert oder stattdessen alte verwendet.

@xuedong09 anstelle von "test" verwenden Sie "testing"

Ich habe @docker @dockerstatus (mehrmals) getwittert ... das ist ein wichtiges Problem ... überrascht, dass sie so still waren!

Wir arbeiten daran, Leute.

Danke @crunis - dieser Travis-Fix funktioniert wunderbar.

Vielen Dank, dass Sie daran gearbeitet haben, dies zu beheben. Es wäre großartig, wenn Sie die Ergebnisse der Autopsie veröffentlichen würden, sobald sie behoben sind.

Danke @hertzg und @thaJeztah , die das Repository "main" in "testing" geändert haben, damit APT für mich funktioniert.

@xuedong09 Denken Sie nur daran, dass wir dort Vorabversionspakete veröffentlichen.

Solch ein interessanter Single Point of Failure für das Docker-Ökosystem

@babakgh das habe ich mir auch gedacht. Hoffentlich kann die Obduktion eine gute Zukunftsprävention vorschlagen.

Das betrifft mich auch.

Ich bekomme immer noch: https://apt.dockerproject.org/repo/dists/debian-jessie/main/binary-amd64/Packages Hash Sum mismatch

Erinnert mich an das, was mit npm und NodeJS passiert ist:

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

Und ein anderer, ich auch

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

Docker-Repository-Betreuer. Du brauchst:

• Automatische Prüfung auf Änderungen
• Healthcheck Ihres Repos
• im Grunde Überwachung und Alarme

Ich hoffe, das passiert nie wieder. Docker verursachte hier (auf TravisCI) Produktionstest- und Bereitstellungsprobleme, obwohl ich keinen einzigen Docker-Container in der Produktion verwende. 😑

An alle Nörgler und Wütende:

Es gibt eine kommerzielle, kostenpflichtige und gut unterstützte Version von Docker.

Zu Ihrer Information, dies ist die Community-Version, die nach besten Kräften unterstützt wird und NICHT MEHR.

@vadviktor Ist das die offizielle Position von Docker, weil ich das zitieren möchte?

@therealmarv Dieses Problem sollte sich ohnehin nicht auf Ihre Produktion oder Bereitstellungspipelines auswirken, da sich niemand auf eine Internetverbindung oder ein externes Repository verlassen sollte, um Software zu erstellen und bereitzustellen.

@vadviktor Beste Anstrengung bedeutet nicht, alle zu Fall zu bringen. Das bedeutet, dass kleine Fehler und Mängel schließlich untersucht werden. Sie müssen immer noch alles unter Best-Case-Szenarien am Laufen halten.

Für Ubuntu Trusty (14.04) hat das Wechseln vom "Haupt"- zum "Testing"-APT-Repository für mich hervorragend funktioniert.

+1

Ich wusste nie, dass Docker eine zweistufige Organisation ist, in der die Benutzerbasis zwischen den Besitzenden und den Besitzlosen aufgeteilt ist. Die mürrische Installation von Docker ist ein globales Anliegen für jeden, der die Software verwendet, und daher sollte die Unterstützung, die "kommerzielle" Leute erhalten, auch für die Community gelten. Eine bezahlte Stufe für eine Organisation ist eine gute Möglichkeit, Geld zu verdienen, aber das sollte über die Grundlagen hinausgehen, wie z. B. die Möglichkeit, Ihre Software zu installieren.

Unfälle passieren, es kommt darauf an, wie wir damit umgehen und welche Lehren wir daraus ziehen. Der größte Teil dieses Threads scheint voller Spekulationen zu sein. Vielen Dank im Voraus an alle Mitglieder des Docker-Teams, die an der Behebung dieses Problems arbeiten.

@vadviktor Arbeitest du bei Docker?

@vadviktor Wo finde ich dieses kommerzielle Apt-Repository? Welches Produkt sollte ich kaufen, um darauf zugreifen zu können?

@vadviktor Arbeitet nicht bei Docker und pflegt das Projekt nicht.

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

Es scheint jetzt für Ubuntu Xenial zu funktionieren.

Zu Ihrer Information, diese Ausgabe ist auf HN https://news.ycombinator.com/item?id=11822562

für alle die sich über diese auszeit aufregen: hier ein süßes rehbild zur beruhigung und dem zeitvertreib zwischendurch:

Trusty scheint wieder da zu sein

Hallo allerseits. Ich arbeite bei Docker.

Zunächst entschuldige ich mich für den Ausfall. Ich betrachte unsere Paketinfrastruktur als kritische Infrastruktur, sowohl für die kostenlose als auch für die kommerzielle Version von Docker. Es ist wahr, dass wir besseren Support für die kommerzielle Version anbieten (es ist eine ihrer Funktionen), aber das sollte nicht für grundlegende Dinge gelten, wie zum Beispiel die Möglichkeit, Ihre Pakete herunterzuladen.

Das Team arbeitet an dem Problem und wird hier weiterhin Updates geben. Wir nehmen das ernst.

Einige von Ihnen haben darauf hingewiesen, dass die Reaktionszeit und die Nutzung von Kommunikationskanälen unzureichend erscheinen, zum Beispiel hat der @dockerststus- Bot das Problem nicht erwähnt, als es erkannt wurde. Ich teile die Meinung, aber ich kenne noch nicht die ganze Geschichte; Die Obduktion wird uns mit Sicherheit sagen, was schief gelaufen ist. Im Moment konzentriert sich das Team darauf, das Problem zu beheben, und ich möchte sie nicht davon ablenken.

Sobald die Obduktion feststellt, was schief gelaufen ist, werden wir geeignete Korrekturmaßnahmen ergreifen. Ich vermute, ein Teil davon wird eine bessere Koordination zwischen Kerningenieuren und Infrastrukturingenieuren sein (zwei verschiedene Gruppen innerhalb von Docker).

Danke und nochmals Entschuldigung für die Unannehmlichkeiten.

heh - habe den Katalog, aber das Paket fehlt - nehme ich an, ich werde noch einen Kaffee trinken :-)
@shykes Danke für das Update - mieser Start in den Morgen ...
Hoffentlich wird der Tag von hier an besser

Ich bin traurig, dass mein Hirschbild weniger +1 bekommen hat als die offizielle Antwort.

Docker habe ich bereits mit https://get.docker.com | installiert sh ohne Fehler.
Sieht so aus, als hätten die Jungs von Docker das Problem behoben,

Wir haben die Ursache des Problems lokalisiert, und wenn es jetzt behoben sein sollte, versuchen Sie es bitte erneut.

Es kann erforderlich sein, den Apt-Cache zu löschen;

apt-get clean && apt-get update

Danke für die Lösung @thaJeztah

Nun, das war schnell für ein unerwartetes Problem, danke.

@snario gerne geschehen; Ich kann die Lösung nicht loben, bin aber froh zu sehen, dass sie geklärt wurde 😅

👍

Leider wird es zu diesem Thema an der Spitze der Hacker-News Milliarden von Kommentaren geben. Vielen Dank für die schnelle Lösung @thaJeztah.

Ich frage mich, ob wir diesen Thread sperren sollten, bevor sie auftauchen.

Bis jetzt gab es workarounds (entweder schnappen Sie sich die .deb und installieren Sie sie mit dpkg, wechseln Sie vorübergehend zum testing -Repository usw.). Das sind keine Dauerlösungen.

Ein fix bedeutet, dass die Ursache dieses Problems behoben ist und wir dieses Problem als gelöst markieren können.

Wie bereits früher gepostet, können Sie ein Skript verwenden, um eine Audiobenachrichtigung zu erhalten, sobald die Haupt-Docker-Repositories repariert sind.
https://gist.github.com/simos/7ee8258ec17101e44bbfa93606694ede
Ansonsten gibt es nicht viel zu tun.

@simos siehe meinen früheren Kommentar; https://github.com/docker/docker/issues/23203#issuecomment -223328829 das Problem sollte behoben sein

@thaJeztah Ich habe überprüft, ob das Problem behoben wurde. Getestet auf Ubuntu 15.10. Vielen Dank an alle anderen Docker-Leute, die geholfen haben, dieses Problem schnell zu lösen.

Vielen Dank an alle für die Meldungen: Das tut uns sehr leid. Wir untersuchen die Details und den Zeitplan der Ereignisse, die dazu geführt haben, und wir werden dafür sorgen, dass so etwas nicht wieder vorkommt.

Ich schließe das Thema, aber lassen Sie es mich natürlich wissen, wenn Sie irgendwelche verbleibenden Macken sehen.

Ubuntu 14.04 Hier, Problem gelöst!

Wahrscheinlich sollte es nicht überraschen, aber es ist schockierend, wie viele Menschen ihre Infrastruktur mit harten Abhängigkeiten von externen Repos riskieren. Ich mache das nicht einmal mit meinen Heimsystemen.

Und sich dann darüber beschweren, dass Docker einen Single Point of Failure hat?

@jalawrence Docker ist die Spitze des Eisbergs...
Haben Sie von den jüngsten Problemen mit node.js und einem Entwickler gehört, der ein einzelnes Paket herausholt?
Ich bin mir ziemlich sicher, dass die meisten PHP-Entwickler, die Composer verwenden – den De-facto-Paketmanager für diese Plattform – auch keine vollständigen Kopien aller Abhängigkeiten ihrer Site speichern, und die Tatsache, dass es bisher keine Pannen gab, ist mehr Glück als alles andere.
Das Problem ist, dass jetzt jeder und sein Hund von $world abhängig sind und das lokale Zwischenspeichern aller Abhängigkeiten eine Sisyphus-Aufgabe ist. Soll ich alles von debian, alles von packagist, alles von cpan, alles von rubygems, alles von npm in einem Reverse-Proxy auf eigene Kosten zwischenspeichern?
Und dann: Wenn github, bitbucket oder travis down sind, was können meine Entwickler dann trotzdem tun? Will ich zurück zu dem Tag, an dem ich all das hosten musste?