Il proxy per snapd è separato da quello di un'app snap
Configura il demone che scarica gli snap separatamente dalle applicazioni che girano dentro quegli snap.
Un snap install riuscito seguito da un'app che non riesce a connettersi coinvolge due diversi proprietari delle richieste:
| Operazione non riuscita | Configurazione da esaminare |
|---|---|
| Trovare, scaricare o aggiornare uno snap | La configurazione dell'accesso allo store di snapd e l'ambiente del demone |
| Connessione dall'applicazione installata | Il client di rete di quell'applicazione, l'ambiente sandbox, le impostazioni del desktop e l'archivio delle fedeltà |
Per snapd usa l'interfaccia supportata dall'installazione. Un endpoint HTTP della lista di proxy HTTP è candidato solo quando l'accesso pubblico allo store può usare proxy pubblici. Le sue opzioni proxy.http e proxy.https sono specifiche del prodotto; la loro applicabilità e i file di ambiente del servizio devono corrispondere al sistema distribuito. Un export nel terminale fatto mentre il comando snap è in esecuzione non sostituisce l'ambiente di avvio del demone.
Il modello di unit upstream include input per file di ambiente, ma i percorsi installati e i valori esistenti contano. Dove opportuno, un drop-in di systemd può fornire quell'ambiente. Caricare un'unità modificata e ricreare il processo del demone sono passaggi diversi.
Per un'app snap in esecuzione, esamina il suo percorso di richiesta. Il successo nello store non dimostra che abbia ereditato quelle impostazioni o che si fidi degli stessi certificati. Nomina prima l'operazione non riuscita, così un problema dell'applicazione non porta a riavviare ripetutamente un demone di download sano.