Ein ZimaOS-Nutzer in Irland berichtete, dass Docker-Image-Pulls gelegentlich regionale Proxy-Domains wie ghcr.1panel.live oder daocloud.io erreichten, obwohl er versucht hatte, die Konfiguration zu löschen. Die betroffenen Pulls schlugen mit TLS-Zertifikats- oder regionalen Zugriffsfehlern fehl, anstatt über die erwartete offizielle Registry abgeschlossen zu werden.
In den Antworten wurden diese Proxys zunächst als erzwungene Spiegelserver beschrieben. Eine spätere Antwort des ZimaOS-Teams enthielt jedoch eine wichtige Korrektur: ZimaOS versucht zuerst, Docker Hub zu verwenden, und nutzt einen Proxy erst, wenn dieser Pull fehlschlägt. Der Thread dokumentiert daher ein Problem mit dem Fallback-Pfad und die Anfrage nach einer Einstellung „Nur offizielle Registries“, nicht den Beweis, dass jeder Image-Pull von Anfang an an einen regionalen Proxy gesendet wird.
Was der Nutzer in Irland erlebt hat
lucslav berichtete von wiederholten Fehlern bei der Installation von Docker-Images mit ZimaOS in Irland. Das Verhalten trat sowohl über die grafische Benutzeroberfläche als auch über Pulls im Terminal auf. Manuelle Versuche, die Mirror-Konfiguration zu löschen, schienen die Änderung nicht dauerhaft zu übernehmen.
Die genaueste im Thread zitierte Fehlermeldung lautete:
tls: failed to verify certificate: x509: certificate signed by unknown authorityBei der fehlgeschlagenen Anfrage wurden Proxy- oder Mirror-Domains genannt und nicht nur die erwartete offizielle Image-Registry. Da eine direkte Verbindung zu offiziellen Registries am Standort des Nutzers zuverlässiger war, bat lucslav um eine dauerhafte Möglichkeit, diese regionalen Pfade zu deaktivieren.
Die beiden später gemeldeten zusätzlichen Fehler
In einer Folgeantwort erinnerte sich lucslav an zwei weitere Arten von Meldungen. Eine besagte, dass der Dienst nur auf dem chinesischen Festland verfügbar sei. Die andere besagte, dass das Zertifikat abgelaufen oder noch nicht gültig sei.
Diese Meldungen verstärkten den Eindruck des Nutzers, dass der Fallback-Endpunkt nicht für jede Region geeignet war. Eine Antwort zur regionalen Beschränkung verhindert die Nutzung des Dienstes außerhalb seines vorgesehenen Gebiets, während ein abgelaufenes oder noch nicht gültiges Zertifikat verhindert, dass der TLS-Verbindung vertraut wird.
Die gewünschte Produktänderung blieb während der gesamten Diskussion einfach: eine Einstellung, mit der Nutzer regionale Mirrors deaktivieren und direkte Verbindungen zu offiziellen Registries wie der GitHub Container Registry und Docker Hub erzwingen können.
Wie gelbuilding den Fehler interpretierte
gelbuilding stimmte zu, dass das gemeldete Verhalten nicht wie ein gewöhnlicher Verlust der Internetverbindung aussah. Die Interpretation lautete, dass die Docker-Anfrage eine Registry-Spiegelung erreichte, deren Zertifikat nicht validiert werden konnte, wodurch Docker den Pull abbrach.
Nachdem lucslav die Meldungen zur Verfügbarkeit nur auf dem chinesischen Festland und zur Zertifikatsgültigkeit ergänzt hatte, betrachtete gelbuilding den Endpunkt selbst als fehlerhaften Pfad. Aus dieser Perspektive verbesserten die Mirrors die Zuverlässigkeit für europäische Nutzer nicht mehr, sondern verursachten einen vollständigen Installationsfehler.
Als Lösung für die Benutzeroberfläche wurde eine Option ähnlich wie Nur offizielle Registries verwenden vorgeschlagen. Im Thread wurde weder eine solche Option noch ein bestätigtes Konfigurationsverfahren bereitgestellt. Die Antwort ist daher als Produktvorschlag und nicht als verfügbare Vorgehensweise zu verstehen.
Ein ähnlicher Fehler wurde aus den Vereinigten Staaten gemeldet
connorb beteiligte sich später aus den Vereinigten Staaten an der Diskussion, nachdem beim Versuch, ein Docker-Image zu installieren, ein ähnlicher Fehler aufgetreten war. Dies zeigte, dass das im Thread beschriebene Problem nicht auf den ursprünglichen Standort des Nutzers in Irland beschränkt war.
connorb fragte, ob es eine Umgehungslösung gebe. lucslav antwortete, dass keine gefunden worden sei, und schlug vor, nach Möglichkeit ein alternatives Image zu suchen. Die Diskussion klärte nicht, ob dieses alternative Image eine andere Registry, einen anderen Repository-Eigentümer oder ein anderes Anwendungspaket verwenden würde.
Das ZimaOS-Team stellte die Reihenfolge der Pulls klar
raller1028 ergänzte gegen Ende des Threads die wichtigste Klarstellung zum Verhalten: Wenn ZimaOS ein Image abruft, versucht es zunächst, dieses über Docker Hub abzurufen. Der Proxy wird erst verwendet, wenn der ursprüngliche Pull fehlschlägt.
Dadurch müssen die früheren Berichte anders interpretiert werden. Die Community-Mitglieder erlebten Fehler im Zusammenhang mit dem Proxy, aber die Antwort des Teams weist darauf hin, dass der Proxy ein Fallback-Pfad und nicht bei jedem Pull das primäre Ziel war.
Die Klarstellung lässt außerdem eine offene Frage bestehen: Warum schlug die ursprüngliche Anfrage an Docker Hub fehl, bevor das System zum Proxy wechselte? Der Thread enthält keine Logs oder nachfolgenden Tests, anhand derer sich feststellen ließe, ob der erste Fehler durch Verbindungsprobleme, Authentifizierung, Ratenbegrenzung, fehlende Verfügbarkeit des Images, DNS oder eine andere Bedingung verursacht wurde.
Was die Diskussion nicht klären konnte
Kein Teilnehmer stellte eine bestätigte dauerhafte Methode zum Deaktivieren des Proxy-Fallbacks bereit. lucslav berichtete, dass manuelle Versuche, die Konfiguration zu löschen, nicht dauerhaft wirksam waren. Die genaue Datei, Einstellung oder der betroffene Dienst wurden im Beitrag jedoch nicht genannt.
Der Thread bestätigte außerdem nicht, dass das Zertifikat in jedem Fall tatsächlich abgelaufen war. Es wurden drei unterschiedliche Meldungen diskutiert: eine unbekannte Zertifizierungsstelle, ein abgelaufenes oder noch nicht gültiges Zertifikat sowie eine Beschränkung auf das chinesische Festland. Möglicherweise betrafen sie unterschiedliche Proxy-Endpunkte oder verschiedene Phasen des Fallback-Prozesses.
Schließlich wurde in dieser Diskussion weder eine endgültige ZimaOS-Version noch eine Einstellung oder eine funktionierende Umgehungslösung veröffentlicht. Das konkrete Ergebnis war eine Produktanforderung: eine dauerhafte Richtlinie für ausschließlich direkte Verbindungen in Regionen bereitzustellen, in denen regionale Mirrors unnötig oder nicht erreichbar sind.
Welche Informationen bei der Meldung desselben Problems erhalten bleiben sollten
Der ursprüngliche Beitrag war besonders hilfreich, weil er die Region des Nutzers, die Proxy-Hostnames, die Betroffenheit von Benutzeroberfläche und Terminal sowie die genaue x509-Meldung enthielt. Die späteren Antworten ergänzten zwei weitere sichtbare Fehlerbedingungen und einen ähnlichen Bericht aus einem anderen Land.
Ein hilfreicher Folgebericht sollte daher dieselbe Art von Belegen enthalten: die ZimaOS-Version, das Land oder die Region, die ursprüngliche Image-Referenz, den Ort, an dem der Pull gestartet wurde – Benutzeroberfläche oder Terminal –, den ersten Fehler der offiziellen Registry, den Fallback-Hostname sowie die vollständige Zertifikats- oder Regionalbeschränkungsmeldung.
Diese Informationen würden dem ZimaOS-Team ermöglichen, einen fehlgeschlagenen offiziellen Pull von einem fehlgeschlagenen Proxy-Fallback zu unterscheiden. Für den normalen Installationsablauf können Nutzer den vorhandenen ZimaOS-Leitfaden für Docker-Anwendungen verwenden.
FAQ aus der Community-Diskussion
Waren regionale Mirrors der erste Pull-Pfad?
Nach Angaben des ZimaOS-Teams nein. ZimaOS versucht zunächst, das Image über Docker Hub abzurufen, und verwendet den Proxy erst, wenn dieser Pull fehlschlägt.
Welche Fehler wurden tatsächlich gemeldet?
Der Thread enthält einen Fehler wegen einer unbekannten Zertifizierungsstelle, eine erinnerte Meldung über ein abgelaufenes oder noch nicht gültiges Zertifikat sowie eine Meldung, dass der Dienst nur auf dem chinesischen Festland verfügbar sei.
Wurde in der Diskussion ein Schalter zum Deaktivieren von Proxys vorgestellt?
Nein. Der Schalter „Nur offizielle Registries verwenden“ war eine von Community-Mitgliedern vorgeschlagene Funktion und keine im Thread gezeigte vorhandene Einstellung.
Gab es eine bestätigte Umgehungslösung?
Es wurde keine dauerhafte Umgehungslösung bestätigt. Ein Teilnehmer schlug vor, ein alternatives Image zu suchen, während die Klarstellung des Teams die Reihenfolge „offizielle Registry zuerst, Proxy danach“ erklärte.
War das Problem auf Europa beschränkt?
Nein. Der ursprüngliche Bericht kam aus Irland, später meldete jedoch ein anderer Nutzer einen ähnlichen Fehler bei der Installation eines Docker-Images aus den Vereinigten Staaten.
