Насочување на rsync изворите на MacPorts преку прокси
Усогласете го протоколот на изворот на ports tree со прокси преносот наместо да претпоставите дека примерот со SSH ќе ја поправи и врската со rsync демонот.
Прелистувачот работи преку SOCKS. Обична SSH сесија исто така. Потоа MacPorts заглавува при синхронизирање на ports tree. Пред да додадете уште една SSH опција, погледнете го URI на изворот.
rsync://host/module означува услуга на rsync демон. Примерот со rsync -e ssh user@host:path користи далечинска лушпа и бара пристап до соодветна сметка на тој хост. Јавно rsync огледало не добива SSH најава само затоа што клиентот има ProxyCommand.
Три патеки со различни предуслови
| Патека | Што мора да постои |
|---|---|
| Снимка на ports tree преку 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 не успеа. Ажурирањето на ports tree, преземањето архив и симнувањето на изворните датотеки на port не мора да користат ист пренос. Поправањето на првата патека не докажува дека останатите го делат нејзиниот прокси.