Un utilisateur de ZimaOS en Irlande a signalé que les téléchargements d’images Docker aboutissaient parfois à des domaines proxy régionaux tels que ghcr.1panel.live ou daocloud.io, même après avoir tenté d’effacer la configuration. Les téléchargements concernés échouaient avec des erreurs de certificat TLS ou d’accès régional au lieu de s’effectuer via le registre officiel attendu.
Les premières réponses décrivaient ces proxys comme des miroirs imposés, mais une réponse ultérieure de l’équipe ZimaOS a apporté une correction importante : ZimaOS essaie d’abord Docker Hub et n’utilise un proxy qu’après l’échec de ce téléchargement. La discussion documente donc un problème lié au chemin de secours ainsi qu’une demande de contrôle « registres officiels uniquement », et non la preuve que chaque téléchargement d’image est envoyé vers un proxy régional dès le départ.
Ce que l’utilisateur en Irlande a constaté
lucslav a signalé des échecs répétés lors de l’installation d’images Docker avec ZimaOS en Irlande. Le comportement se produisait aussi bien via l’interface graphique que depuis le terminal, et les tentatives manuelles visant à effacer la configuration du miroir ne semblaient pas rendre la modification permanente.
L’erreur la plus précise copiée dans la discussion était la suivante :
tls: failed to verify certificate: x509: certificate signed by unknown authorityLa requête ayant échoué mentionnait des domaines proxy ou miroir plutôt que le seul registre d’images officiel attendu. Comme une connexion directe aux registres officiels était plus fiable depuis l’emplacement de l’utilisateur, lucslav a demandé un moyen permanent de désactiver ces chemins régionaux.
Les deux erreurs supplémentaires signalées par la suite
Dans un message de suivi, lucslav se souvenait avoir vu deux autres types de messages. L’un indiquait que le service était disponible uniquement en Chine continentale. L’autre signalait que le certificat avait expiré ou n’était pas encore valide.
Ces messages ont renforcé l’idée de l’utilisateur selon laquelle le point de repli n’était pas adapté à toutes les régions. Une réponse de restriction régionale empêche l’utilisation du service en dehors de la zone prévue, tandis qu’un certificat expiré ou pas encore valide empêche d’établir une connexion TLS fiable.
La modification demandée est restée simple tout au long de la discussion : ajouter un paramètre permettant aux utilisateurs de désactiver les miroirs régionaux et d’imposer des connexions directes aux registres officiels, tels que GitHub Container Registry et Docker Hub.
Comment gelbuilding a interprété l’échec
gelbuilding a reconnu que le comportement signalé ne ressemblait pas à une simple perte de connexion Internet. Selon son interprétation, la requête Docker atteignait un miroir de registre dont le certificat ne pouvait pas être validé, ce qui interrompait le téléchargement.
Après que lucslav a ajouté les messages indiquant une disponibilité limitée à la Chine continentale et un problème de validité du certificat, gelbuilding a considéré le point d’accès lui-même comme la branche défaillante. De ce point de vue, les miroirs n’amélioraient plus la fiabilité pour les utilisateurs européens ; ils provoquaient un échec complet de l’installation.
La solution d’interface proposée était une option similaire à Utiliser uniquement les registres officiels. Aucune option de ce type ni procédure de configuration confirmée n’a été fournie dans la discussion ; la réponse doit donc être comprise comme une suggestion d’amélioration du produit et non comme une étape actuellement disponible.
Un échec similaire signalé depuis les États-Unis
connorb a ensuite rejoint la discussion depuis les États-Unis après avoir reçu une erreur similaire en tentant d’installer une image Docker. Cela montre que le problème décrit dans la discussion ne se limitait pas à la région de l’utilisateur initial, en Irlande.
connorb a demandé s’il existait une solution de contournement. lucslav a répondu ne pas en avoir trouvé et a suggéré de rechercher, si possible, une autre image. La discussion n’a pas établi si cette autre image utiliserait un registre différent, un autre propriétaire de dépôt ou un paquet applicatif différent.
L’équipe ZimaOS a clarifié l’ordre des téléchargements
raller1028 a apporté la précision la plus importante vers la fin de la discussion : lorsque ZimaOS télécharge une image, il tente d’abord de la récupérer via Docker Hub. Le proxy n’est essayé que lorsque le téléchargement initial échoue.
Cela modifie l’interprétation des premiers signalements. Les membres de la communauté ont subi des échecs liés au proxy, mais la réponse de l’équipe indique que le proxy constituait un chemin de secours plutôt que la destination initiale de chaque téléchargement.
Cette précision laisse également une question sans réponse : pourquoi la requête initiale vers Docker Hub a-t-elle échoué avant le passage au proxy ? La discussion ne contient aucun journal ni test de suivi permettant de déterminer si le premier échec résultait d’un problème de connectivité, d’authentification, de limitation de débit, de disponibilité de l’image, de DNS ou d’une autre condition.
Ce que la discussion n’a pas permis de résoudre
Aucun participant n’a fourni de méthode permanente confirmée pour désactiver le repli vers le proxy. lucslav a indiqué que les tentatives manuelles visant à effacer la configuration ne persistaient pas, mais le fichier, le paramètre ou le service concerné n’a pas été précisé dans le message.
La discussion n’a pas non plus confirmé que le certificat avait expiré dans tous les cas. Trois messages différents ont été évoqués : autorité de certification inconnue, certificat expiré ou pas encore valide, et restriction indiquant que le service était réservé à la Chine continentale. Ils peuvent concerner des points d’accès proxy différents ou des étapes différentes du processus de repli.
Enfin, aucune version finale de ZimaOS, aucun paramètre ni aucune solution de contournement n’a été publié dans cette discussion. Le résultat concret est une demande d’amélioration du produit : proposer une politique persistante imposant les connexions directes pour les régions où les miroirs régionaux sont inutiles ou inaccessibles.
Informations à conserver lors du signalement du même problème
Le message initial était utile parce qu’il indiquait la région de l’utilisateur, les noms d’hôtes proxy, le fait que l’interface et le terminal étaient tous deux concernés, ainsi que le message x509 exact. Les réponses ultérieures ont ajouté deux autres conditions d’erreur visibles et un signalement similaire provenant d’un autre pays.
Un rapport de suivi utile devrait donc conserver le même type d’éléments : la version de ZimaOS, le pays ou la région, la référence de l’image initiale, le point de départ du téléchargement — interface ou terminal —, l’échec initial du registre officiel, le nom d’hôte de repli et le message complet concernant le certificat ou la restriction régionale.
Ces informations permettraient à l’équipe ZimaOS de distinguer l’échec d’un téléchargement depuis le registre officiel de celui d’un repli vers un proxy. Les utilisateurs peuvent consulter le guide des applications Docker ZimaOS existant pour suivre la procédure d’installation normale.
FAQ issue de la discussion de la communauté
Les miroirs régionaux constituaient-ils le premier chemin de téléchargement ?
Selon la réponse de l’équipe ZimaOS, non. ZimaOS tente d’abord de télécharger l’image via Docker Hub et n’essaie le proxy qu’après l’échec de ce téléchargement.
Quelles erreurs ont réellement été signalées ?
La discussion mentionne une erreur liée à une autorité de certification inconnue, un message rapporté concernant un certificat expiré ou pas encore valide, ainsi qu’un message indiquant que le service était uniquement disponible en Chine continentale.
La discussion proposait-elle un bouton pour désactiver les proxys ?
Non. Le bouton « Utiliser uniquement les registres officiels » était une demande de fonctionnalité formulée par des membres de la communauté, et non un paramètre existant présenté dans la discussion.
Une solution de contournement a-t-elle été confirmée ?
Non, aucune solution permanente n’a été confirmée. Un participant a suggéré de rechercher une autre image, tandis que la clarification de l’équipe a expliqué l’ordre de téléchargement : registre officiel en premier, proxy en second.
Le problème était-il limité à l’Europe ?
Non. Le signalement initial provenait d’Irlande, mais un autre utilisateur a ensuite signalé une erreur similaire d’installation d’image Docker depuis les États-Unis.
