Маршрутизация источников rsync MacPorts через прокси
Согласуйте протокол источника дерева портов с транспортом прокси, вместо того чтобы считать, что пример с SSH исправит и подключение к демону rsync.
Браузер работает через SOCKS. Обычный сеанс SSH тоже. Затем MacPorts зависает при синхронизации дерева портов. Прежде чем добавлять ещё один вариант SSH, посмотрите на URI источника.
rsync://host/module обозначает службу демона rsync. Пример с rsync -e ssh user@host:path использует удалённую оболочку и требует доступа к подходящей учётной записи на этом хосте. Публичное зеркало rsync не получает вход по SSH только потому, что у клиента есть ProxyCommand.
Три маршрута с разными предпосылками
| Маршрут | Что должно существовать |
|---|---|
| Снимок дерева портов по HTTP или HTTPS | Поддерживаемый источник снимка и работающая конфигурация HTTP-прокси |
| Демон rsync через веб-прокси | Клиент rsync с RSYNC_PROXY и прокси, разрешающий CONNECT к порту демона |
| rsync через SSH | Конечная точка SSH, учётная запись и удалённая настройка rsync |
MacPorts документирует источники tarball по HTTP и HTTPS в sources.conf как альтернативы, когда обычный транспорт синхронизации недоступен. Выбирайте источник, поддерживаемый проектом для установленного выпуска; смена схемы URI не даёт права указывать на произвольный архив.
RSYNC_PROXY в rsync — это механизм веб-прокси, а не общая настройка URL SOCKS. Маршрут через демон обычно требует порт 873, который в остальном работающий веб-прокси может намеренно отклонить. Отдельный механизм RSYNC_CONNECT_PROG может заменить прямой сокет демона вспомогательной программой, но она должна обеспечить ожидаемый поток байтов.
Наконец, отметьте, на каком этапе MacPorts произошёл сбой. Обновление дерева портов, получение архива и загрузка исходных файлов порта не обязаны использовать один транспорт. Исправление первого маршрута не доказывает, что остальные используют его прокси.