Użytkownik ZimaOS z Irlandii zgłosił, że pobieranie obrazów Dockera czasami kierowało do regionalnych domen proxy, takich jak ghcr.1panel.live lub daocloud.io, nawet po próbach wyczyszczenia konfiguracji. Te pobrania kończyły się błędami certyfikatu TLS lub dostępu regionalnego zamiast przez oczekiwany oficjalny rejestr.
W odpowiedziach początkowo opisywano te serwery proxy jako wymuszone mirrory, jednak późniejsza odpowiedź zespołu ZimaOS wprowadziła ważne sprostowanie: ZimaOS najpierw próbuje użyć Docker Hub, a z proxy korzysta dopiero po nieudanym pobraniu. Wątek dokumentuje więc problem ze ścieżką awaryjną oraz prośbę o opcję „tylko oficjalne rejestry”, a nie dowód na to, że każde pobranie obrazu od początku trafia do regionalnego proxy.
Czego doświadczył użytkownik z Irlandii
lucslav zgłosił powtarzające się niepowodzenia instalacji obrazów Dockera podczas korzystania z ZimaOS w Irlandii. Problem występował zarówno w interfejsie graficznym, jak i podczas pobierania z terminala, a ręczne próby wyczyszczenia konfiguracji mirrorów nie wydawały się trwałe.
Najbardziej szczegółowy błąd skopiowany do wątku brzmiał:
tls: failed to verify certificate: x509: certificate signed by unknown authorityNieudane żądanie wskazywało domeny proxy lub mirrorów, a nie wyłącznie oczekiwany oficjalny rejestr obrazów. Ponieważ bezpośrednie połączenie z oficjalnymi rejestrami było bardziej niezawodne w lokalizacji użytkownika, lucslav poprosił o trwały sposób wyłączenia tych regionalnych ścieżek.
Dwa dodatkowe błędy zgłoszone później
W dalszej części dyskusji lucslav przypomniał sobie dwa inne rodzaje komunikatów. Jeden informował, że usługa jest dostępna wyłącznie w Chinach kontynentalnych. Drugi wskazywał, że certyfikat wygasł lub nie jest jeszcze ważny.
Komunikaty te utwierdziły użytkownika w przekonaniu, że zapasowy punkt końcowy nie jest odpowiedni dla każdego regionu. Odpowiedź o ograniczeniu regionalnym uniemożliwia korzystanie z usługi poza przeznaczonym obszarem, natomiast wygasły lub jeszcze nieważny certyfikat uniemożliwia zaufane ustanowienie połączenia TLS.
Przez całą dyskusję oczekiwana zmiana w produkcie pozostawała prosta: dodać ustawienie pozwalające użytkownikom wyłączyć regionalne mirrory i wymusić bezpośrednie połączenia z oficjalnymi rejestrami, takimi jak GitHub Container Registry i Docker Hub.
Jak gelbuilding zinterpretował awarię
gelbuilding zgodził się, że opisane zachowanie nie wyglądało na zwykłą utratę połączenia z internetem. Według tej interpretacji żądanie Dockera docierało do mirrora rejestru, którego certyfikatu nie można było zweryfikować, przez co Docker przerywał pobieranie.
Po dodaniu przez lucslav informacji o ograniczeniu do Chin kontynentalnych oraz o ważności certyfikatu gelbuilding uznał sam punkt końcowy za wadliwą gałąź procesu. Z tej perspektywy mirrory nie zwiększały już niezawodności dla użytkowników z Europy, lecz powodowały całkowitą awarię instalacji.
Proponowanym rozwiązaniem interfejsu była opcja podobna do Używaj tylko oficjalnych rejestrów. W wątku nie przedstawiono takiej opcji ani potwierdzonej procedury konfiguracji, dlatego odpowiedź należy traktować jako sugestię dotyczącą produktu, a nie dostępny krok.
Podobną awarię zgłoszono ze Stanów Zjednoczonych
connorb dołączył później do dyskusji ze Stanów Zjednoczonych po otrzymaniu podobnego błędu podczas próby instalacji obrazu Dockera. Pokazało to, że problem opisany w wątku nie ograniczał się do pierwotnej lokalizacji użytkownika w Irlandii.
connorb zapytał, czy istnieje obejście problemu. lucslav odpowiedział, że nie znalazł żadnego, i zasugerował w miarę możliwości wyszukanie alternatywnego obrazu. Dyskusja nie ustaliła, czy taki alternatywny obraz korzystałby z innego rejestru, innego właściciela repozytorium czy innego pakietu aplikacji.
Zespół ZimaOS wyjaśnił kolejność pobierania
raller1028 dodał pod koniec wątku najważniejsze wyjaśnienie dotyczące działania systemu: gdy ZimaOS pobiera obraz, najpierw próbuje pobrać go przez Docker Hub. Proxy jest używane dopiero wtedy, gdy pierwotne pobranie się nie powiedzie.
Zmienia to sposób interpretacji wcześniejszych zgłoszeń. Członkowie społeczności doświadczyli awarii związanych z proxy, jednak odpowiedź zespołu wskazuje, że proxy było ścieżką awaryjną, a nie pierwszym miejscem docelowym każdego pobrania.
Wyjaśnienie pozostawia jednak bez odpowiedzi ważne pytanie: dlaczego pierwotne żądanie do Docker Hub zakończyło się niepowodzeniem, zanim system przeszedł do proxy? Wątek nie zawiera dzienników ani testów uzupełniających, które wskazywałyby, czy pierwsza awaria wynikała z problemów z łącznością, uwierzytelnianiem, ograniczeniem liczby żądań, dostępnością obrazu, DNS-em czy innego czynnika.
Czego nie udało się rozstrzygnąć
Żaden z uczestników nie podał potwierdzonej, trwałej metody wyłączenia awaryjnego proxy. lucslav poinformował, że ręczne próby wyczyszczenia konfiguracji nie były zachowywane, jednak w poście nie wskazano konkretnego pliku, ustawienia ani usługi.
Wątek nie potwierdził również, że sam certyfikat wygasł w każdym przypadku. Omówiono trzy różne komunikaty: o nieznanym urzędzie certyfikacji, o wygasłym lub jeszcze nieważnym certyfikacie oraz o dostępności usługi wyłącznie w Chinach kontynentalnych. Mogą one dotyczyć różnych punktów końcowych proxy lub różnych etapów procesu awaryjnego.
Nie opublikowano też żadnej konkretnej wersji ZimaOS, ustawienia ani obejścia problemu. Jedynym konkretnym rezultatem była prośba dotycząca produktu: udostępnienie trwałej polityki korzystania wyłącznie z połączeń bezpośrednich w regionach, w których regionalne mirrory są niepotrzebne lub niedostępne.
Informacje, które warto zachować przy zgłaszaniu tego samego problemu
Pierwotny post był wartościowy, ponieważ zawierał region użytkownika, nazwy hostów proxy, informację o tym, że problem dotyczył zarówno interfejsu, jak i terminala, oraz dokładny komunikat x509. Późniejsze odpowiedzi dodały dwa kolejne widoczne warunki błędu i podobne zgłoszenie z innego kraju.
Dlatego przydatne zgłoszenie uzupełniające powinno zawierać ten sam rodzaj dowodów: wersję ZimaOS, kraj lub region, oryginalne odwołanie do obrazu, informację, czy pobieranie rozpoczęto w interfejsie czy w terminalu, pierwszy błąd oficjalnego rejestru, nazwę hosta użytego w ścieżce awaryjnej oraz pełny komunikat dotyczący certyfikatu lub ograniczenia regionalnego.
Takie informacje pozwoliłyby zespołowi ZimaOS odróżnić nieudane pobranie z oficjalnego rejestru od nieudanego pobrania przez awaryjne proxy. Użytkownicy mogą skorzystać z istniejącego poradnika aplikacji Dockera w ZimaOS, aby poznać standardowy proces instalacji.
FAQ z dyskusji społeczności
Czy regionalne mirrory były pierwszą ścieżką pobierania?
Według odpowiedzi zespołu ZimaOS — nie. ZimaOS najpierw próbuje pobrać obraz przez Docker Hub, a z proxy korzysta dopiero po nieudanym pobraniu.
Jakie błędy faktycznie zgłoszono?
Wątek zawiera błąd dotyczący nieznanego urzędu certyfikacji, przypomniany komunikat o wygasłym lub jeszcze nieważnym certyfikacie oraz komunikat o dostępności usługi wyłącznie w Chinach kontynentalnych.
Czy w dyskusji przedstawiono przełącznik wyłączający proxy?
Nie. Przełącznik „Używaj tylko oficjalnych rejestrów” był propozycją funkcji zgłoszoną przez członków społeczności, a nie istniejącym ustawieniem zaprezentowanym w wątku.
Czy potwierdzono jakieś obejście problemu?
Nie potwierdzono żadnego trwałego obejścia. Jeden z uczestników zasugerował znalezienie alternatywnego obrazu, natomiast wyjaśnienie zespołu opisało kolejność: najpierw oficjalny rejestr, a następnie proxy.
Czy problem ograniczał się do Europy?
Nie. Pierwotne zgłoszenie pochodziło z Irlandii, ale później inny użytkownik zgłosił podobny błąd instalacji obrazu Dockera ze Stanów Zjednoczonych.
