Маршрутизиране на rsync източниците на MacPorts през прокси
Съобразете протокола на източника на ports tree с прокси транспорта, вместо да предполагате, че примерът със 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 документира HTTP и HTTPS tarball източници в sources.conf като алтернативи, когато обичайният транспорт за синхронизация не е наличен. Изберете поддържания от проекта източник за инсталираната версия; смяната на URI схемата не е разрешение да сочите към произволен архив.
RSYNC_PROXY на rsync е механизъм за уеб прокси, а не обща настройка на SOCKS URL. Маршрутът през демона обикновено изисква порт 873, който иначе работещо уеб прокси може умишлено да откаже. Отделният механизъм RSYNC_CONNECT_PROG може да замени директния сокет на демона с помощна програма, но тя трябва да осигури очаквания байтов поток.
Накрая отбележете кой етап на MacPorts е неуспешен. Обновяването на дървото с портове, изтеглянето на архив и свалянето на изходните файлове на порт не е задължително да ползват един транспорт. Поправянето на първия маршрут не доказва, че останалите споделят неговото прокси.