Direcționarea surselor rsync MacPorts printr-un proxy
Aliniați protocolul sursei ports tree la transportul prin proxy, în loc să presupuneți că un exemplu SSH repară și conexiunea la demonul rsync.
Browserul funcționează prin SOCKS. O sesiune SSH obișnuită la fel. Apoi MacPorts se blochează în timp ce își sincronizează arborele de porturi. Înainte de a adăuga încă o opțiune SSH, priviți URI-ul sursei.
rsync://host/module desemnează un serviciu de demon rsync. Exemplul cu rsync -e ssh user@host:path folosește un shell la distanță și necesită acces la un cont potrivit pe acea gazdă. O oglindă rsync publică nu obține autentificare SSH doar pentru că clientul are un ProxyCommand.
Trei rute cu precondiții diferite
| Rută | Ce trebuie să existe |
|---|---|
| Instantaneu al arborelui de porturi prin HTTP sau HTTPS | O sursă de instantaneu acceptată și o configurație de proxy HTTP funcțională |
| Demon rsync printr-un proxy web | Un client rsync care folosește RSYNC_PROXY și un proxy care permite CONNECT la portul demonului |
| rsync prin SSH | Un punct final SSH, un cont și o configurare rsync la distanță |
MacPorts documentează sursele tarball HTTP și HTTPS în sources.conf ca alternative atunci când transportul obișnuit de sincronizare nu este disponibil. Alegeți sursa acceptată de proiect pentru versiunea instalată; schimbarea schemei URI nu este permisiunea de a indica o arhivă arbitrară.
RSYNC_PROXY din rsync este un mecanism de proxy web, nu o setare generică de URL SOCKS. Ruta prin demon necesită de obicei portul 873, pe care un proxy web altfel funcțional îl poate refuza intenționat. Mecanismul separat RSYNC_CONNECT_PROG poate înlocui socketul direct al demonului cu un program auxiliar, dar auxiliarul trebuie să furnizeze fluxul de octeți așteptat.
În final, observați care etapă a MacPorts a eșuat. Actualizarea arborelui de porturi, obținerea unei arhive și descărcarea fișierelor sursă ale unui port nu trebuie să folosească același transport. Repararea primei rute nu dovedește că celelalte îi împart proxy-ul.