Маршрутизація джерел 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 стався збій. Оновлення дерева портів, отримання архіву й завантаження вихідних файлів порту не обов'язково використовують один транспорт. Виправлення першого маршруту не доводить, що інші поділяють його проксі.