Le proxy de snapd est distinct de celui d'une application snap
Configurez le démon qui récupère les snaps séparément des applications qui s'exécutent à l'intérieur de ces snaps.
Un snap install réussi suivi d'une application qui ne peut pas se connecter met en jeu deux propriétaires de requêtes différents :
| Opération en échec | Configuration à examiner |
|---|---|
| Rechercher, télécharger ou actualiser un snap | La configuration d'accès au magasin de snapd et l'environnement du démon |
| Se connecter depuis l'application installée | Le client réseau de cette application, l'environnement de bac à sable, les réglages du bureau et le magasin de confiance |
Pour snapd, utilisez l'interface prise en charge de l'installation. Un point de terminaison HTTP de la liste de proxys HTTP n'est candidat que lorsque l'accès public au magasin peut utiliser des proxys publics. Ses options proxy.http et proxy.https sont propres au produit ; leur applicabilité et les fichiers d'environnement du service doivent correspondre au système déployé. Un export effectué dans le terminal pendant la commande snap ne remplace pas l'environnement de démarrage du démon.
Le modèle d'unité amont comporte des entrées de fichiers d'environnement, mais les chemins installés et les valeurs existantes comptent. Le cas échéant, un drop-in systemd peut fournir cet environnement. Charger une unité modifiée et recréer le processus du démon sont deux étapes différentes.
Pour une application snap en cours d'exécution, examinez son propre chemin de requête. Un succès auprès du magasin ne prouve pas qu'elle a hérité de ces réglages ni qu'elle fait confiance aux mêmes certificats. Nommez d'abord l'opération en échec, afin qu'un problème d'application ne conduise pas à redémarrer sans cesse un démon de téléchargement sain.