Проксі для snapd відрізняється від проксі для застосунку snap
Налаштуйте демон, що завантажує snap-пакети, окремо від застосунків, які працюють усередині цих snap-пакетів.
Робочий snap install, за яким іде застосунок, що не може підключитися, стосується двох різних власників запитів:
| Невдала операція | Конфігурація для перевірки |
|---|---|
| Пошук, завантаження або оновлення snap | Конфігурація доступу snapd до сховища та середовище демона |
| Підключення із встановленого застосунку | Мережевий клієнт цього застосунку, середовище пісочниці, налаштування робочого столу та сховище сертифікатів |
Для snapd використовуйте підтримуваний інтерфейс інсталяції. HTTP-точка з переліку HTTP-проксі є кандидатом лише тоді, коли публічний доступ до сховища може використовувати публічні проксі. Його параметри proxy.http і proxy.https залежать від продукту; їхня застосовність і файли середовища служби мають відповідати розгорнутій системі. Експорт у терміналі, зроблений під час виконання команди snap, не замінює стартове середовище демона.
Шаблон upstream-юніту містить входи файлів середовища, але встановлені шляхи та наявні значення мають значення. Де це доречно, drop-in systemd може надати це середовище. Завантаження зміненого юніту й повторне створення процесу демона — різні кроки.
Для запущеного застосунку snap досліджуйте його власний шлях запитів. Успіх у сховищі не доводить, що він успадкував ці налаштування чи довіряє тим самим сертифікатам. Спершу назвіть невдалу операцію, щоб проблема застосунку не призводила до повторних перезапусків справного демона завантаження зі сховища.