'n Proxy vir snapd is apart van dié vir 'n snap-toepassing
Stel die daemon wat snaps aflaai apart op van toepassings wat binne daardie snaps loop.
'n Suksesvolle snap install wat gevolg word deur 'n toepassing wat nie kan koppel nie, betrek twee verskillende eienaars van versoeke:
| Mislukte bewerking | Konfigurasie om te ondersoek |
|---|---|
| Vind, laai af of verfris 'n snap | snapd se winkeltoegang-konfigurasie en daemon-omgewing |
| Koppel vanaf die geïnstalleerde toepassing | Daardie toepassing se netwerkklant, sandbox-omgewing, lessenaarinstellings en vertrouensberg |
Vir snapd, gebruik die installasie se ondersteunde koppelvlak. 'n HTTP-eindpunt uit die HTTP-proxylys is slegs 'n kandidaat wanneer toegang tot die openbare winkel openbare proxies mag gebruik. Die opsies proxy.http en proxy.https is produk-spesifiek; hul toepaslikheid en diensomgewingslêers moet by die ontplooide stelsel pas. 'n Terminal-uitvoer wat gemaak word terwyl die snap-opdrag loop, vervang nie die daemon se beginomgewing nie.
Die upstream-eenheidsjabloon sluit omgewingslêer-insette in, maar geïnstalleerde paaie en bestaande waardes maak saak. Waar toepaslik kan 'n systemd drop-in daardie omgewing verskaf. Om 'n veranderde eenheid te laai en om die daemon-proses te herskep, is verskillende stappe.
Vir 'n lopende snap-toepassing, ondersoek sy eie versoekpad. Sukses by die winkel bewys nie dat dit daardie instellings geërf het of dieselfde sertifikate vertrou nie. Noem eers die mislukte bewerking, sodat 'n toepassingsprobleem nie daartoe lei dat 'n gesonde winkel-aflaaidaemon herhaaldelik herbegin word nie.