Een ZimaOS-gebruiker in Ierland meldde dat het ophalen van Docker-images soms regionale proxydomeinen zoals ghcr.1panel.live of daocloud.io bereikte, zelfs nadat hij had geprobeerd de configuratie te wissen. De betreffende pulls mislukten met TLS-certificaat- of regionale-toegangsfouten, in plaats van via de verwachte officiële registry te worden voltooid.
In eerste instantie werden deze proxy's in de reacties beschreven als geforceerde mirrors, maar een latere reactie van het ZimaOS-team bevatte een belangrijke correctie: ZimaOS probeert eerst Docker Hub en gebruikt pas een proxy nadat die pull mislukt. De thread documenteert daarom een probleem met het fallback-pad en een verzoek om een instelling voor “alleen officiële registries”, niet het bewijs dat elke image-pull vanaf het begin naar een regionale proxy wordt gestuurd.
Wat de gebruiker in Ierland ervoer
lucslav meldde herhaalde fouten bij het installeren van Docker-images tijdens het gebruik van ZimaOS in Ierland. Het gedrag trad zowel op via de grafische interface als via pulls in de terminal, en handmatige pogingen om de mirrorconfiguratie te wissen leken de wijziging niet permanent te maken.
De meest specifieke fout die in de thread werd gekopieerd, was:
tls: failed to verify certificate: x509: certificate signed by unknown authorityIn het mislukte verzoek werden proxy- of mirrordomeinen genoemd in plaats van alleen de verwachte officiële imageregistry. Omdat een directe verbinding met officiële registries vanaf de locatie van de gebruiker betrouwbaarder was, vroeg lucslav om een permanente manier om deze regionale paden uit te schakelen.
De twee aanvullende fouten die later werden gemeld
In een vervolgreactie herinnerde lucslav zich nog twee andere soorten meldingen. De ene zei dat de service alleen beschikbaar was op het Chinese vasteland. De andere zei dat het certificaat verlopen was of nog niet geldig was.
Deze meldingen versterkten de indruk van de gebruiker dat het fallback-eindpunt niet voor elke regio geschikt was. Een reactie over regionale beperking voorkomt dat de service buiten het beoogde gebied wordt gebruikt, terwijl een verlopen of nog niet geldig certificaat ervoor zorgt dat de TLS-verbinding niet kan worden vertrouwd.
De gevraagde productwijziging bleef gedurende de hele discussie eenvoudig: voeg een instelling toe waarmee gebruikers regionale mirrors kunnen uitschakelen en directe verbindingen met officiële registries zoals GitHub Container Registry en Docker Hub kunnen afdwingen.
Hoe gelbuilding de fout interpreteerde
gelbuilding was het ermee eens dat het gemelde gedrag niet leek op een gewone onderbreking van de internetverbinding. Hun interpretatie was dat het Docker-verzoek een registry-mirror bereikte waarvan het certificaat niet kon worden gevalideerd, waardoor Docker de pull stopzette.
Nadat lucslav de meldingen over beschikbaarheid op het Chinese vasteland en de geldigheid van het certificaat had toegevoegd, beschouwde gelbuilding het eindpunt zelf als de falende vertakking. Vanuit dit perspectief verbeterden de mirrors de betrouwbaarheid voor Europese gebruikers niet langer; ze veroorzaakten juist een harde installatiefout.
De voorgestelde interface-oplossing was een optie zoals Alleen officiële registries gebruiken. In de thread werd geen dergelijke optie of bevestigde configuratieprocedure verstrekt. De reactie moet daarom worden opgevat als een productsuggestie en niet als een beschikbare stap.
Een vergelijkbare fout werd gemeld vanuit de Verenigde Staten
connorb nam later vanuit de Verenigde Staten deel aan de discussie nadat hij een vergelijkbare fout had gekregen bij het installeren van een Docker-image. Dit liet zien dat het probleem uit de thread niet beperkt was tot de oorspronkelijke locatie van de gebruiker in Ierland.
connorb vroeg of er een workaround bestond. lucslav antwoordde dat die niet was gevonden en stelde voor om waar mogelijk naar een alternatieve image te zoeken. De discussie stelde niet vast of die alternatieve image een andere registry, een andere repository-eigenaar of een ander applicatiepakket zou gebruiken.
Het ZimaOS-team verduidelijkte de volgorde van de pulls
raller1028 voegde tegen het einde van de thread de belangrijkste verduidelijking over het gedrag toe: wanneer ZimaOS een image ophaalt, probeert het die eerst via Docker Hub op te halen. De proxy wordt alleen geprobeerd wanneer de oorspronkelijke pull mislukt.
Dit verandert de manier waarop de eerdere meldingen moeten worden geïnterpreteerd. De communityleden ervoeren proxygerelateerde fouten, maar uit de reactie van het team blijkt dat de proxy een fallback-pad was en niet de eerste bestemming voor elke pull.
De verduidelijking laat ook een onbeantwoorde vraag achter: waarom mislukte het oorspronkelijke verzoek aan Docker Hub voordat het systeem naar de proxy overschakelde? De thread bevat geen logs of vervolgtests waaruit blijkt of de eerste fout werd veroorzaakt door connectiviteit, authenticatie, rate limiting, beschikbaarheid van de image, DNS of een andere oorzaak.
Wat de discussie niet oploste
Geen enkele deelnemer leverde een bevestigde permanente methode om de proxy-fallback uit te schakelen. lucslav meldde dat handmatige pogingen om de configuratie te wissen niet blijvend waren, maar het exacte bestand, de instelling of de betrokken service werd niet in het bericht vermeld.
De thread bevestigde ook niet dat het certificaat in alle gevallen daadwerkelijk verlopen was. Er werden drie verschillende meldingen besproken: een onbekende certificaatautoriteit, een verlopen of nog niet geldig certificaat en een beperking tot het Chinese vasteland. Het kan gaan om verschillende proxy-eindpunten of verschillende fasen van het fallback-proces.
Tot slot werd in deze discussie geen definitieve ZimaOS-release, instelling of workaround geplaatst. De concrete uitkomst was een productverzoek: maak een permanente, directe verbindingen afdwingende beleidsoptie beschikbaar voor regio's waar regionale mirrors niet nodig of niet toegankelijk zijn.
Informatie die bij een melding van hetzelfde probleem moet worden behouden
Het oorspronkelijke bericht was waardevol omdat het de regio van de gebruiker, de proxynamen, het feit dat zowel de interface als de terminal getroffen waren en de exacte x509-melding bevatte. De latere reacties voegden nog twee zichtbare foutcondities en een vergelijkbare melding uit een ander land toe.
Een nuttige vervolgmelding moet daarom hetzelfde soort bewijs bevatten: de ZimaOS-versie, het land of de regio, de oorspronkelijke imagereferentie, of de pull in de interface of terminal begon, de eerste fout bij de officiële registry, de fallback-hostnaam en de volledige certificaat- of regiobeperkingsmelding.
Met die informatie kan het ZimaOS-team onderscheid maken tussen een mislukte officiële pull en een mislukte proxy-fallback. Gebruikers kunnen de bestaande Docker-applicatiehandleiding voor ZimaOS gebruiken voor de normale installatieprocedure.
Veelgestelde vragen uit de communitydiscussie
Waren regionale mirrors het eerste pull-pad?
Volgens de reactie van het ZimaOS-team niet. ZimaOS probeert de image eerst via Docker Hub op te halen en probeert de proxy pas nadat die pull mislukt.
Welke fouten werden daadwerkelijk gemeld?
De thread bevat een fout over een onbekende certificaatautoriteit, een herinnerde melding over een verlopen of nog niet geldig certificaat en een melding dat de service alleen beschikbaar was op het Chinese vasteland.
Bood de discussie een schakelaar om proxy's uit te schakelen?
Nee. De schakelaar “Alleen officiële registries gebruiken” was een functieverzoek van communityleden en geen bestaande instelling die in de thread werd gedemonstreerd.
Was er een bevestigde workaround?
Nee, er werd geen permanente workaround bevestigd. Eén deelnemer stelde voor om een alternatieve image te zoeken, terwijl de verduidelijking van het team de volgorde van eerst de officiële registry en daarna de proxy uitlegde.
Was het probleem beperkt tot Europa?
Nee. De oorspronkelijke melding kwam uit Ierland, maar een andere gebruiker meldde later een vergelijkbare fout bij het installeren van een Docker-image vanuit de Verenigde Staten.
