Enkursigado de MacPorts rsync-fontoj tra prokurilo
Agu la fontprotokolon de la porthava arbo al la prokurila transporto anstataŭ supozi, ke SSH-ekzemplo ankaŭ riparas rsync-demonan konekton.
La retumilo funkcias tra SOCKS. Ordinara SSH-sesio ankaŭ. Tiam MacPorts haltas dum sinkronigado de sia porthava arbo. Antaŭ ol aldoni plian SSH-opcion, rigardu la fontan URI.
rsync://host/module nomas rsync-demonan servon. La ekzemplo kun rsync -e ssh user@host:path uzas malproksiman ŝelon kaj postulas aliron al taŭga konto sur tiu gastiganto. Publika rsync-spegulo ne ricevas SSH-ensaluton nur ĉar la kliento havas ProxyCommand.
Tri itineroj kun malsamaj antaŭkondiĉoj
| Itinero | Kio devas ekzisti |
|---|---|
| Porthava arbosnapshot per HTTP aŭ HTTPS | Subtenata snapshotfonto kaj funkcianta HTTP-prokura agordo |
| rsync-demono tra reteja prokurilo | rsync-kliento uzanta RSYNC_PROXY kaj prokurilo permesanta CONNECT al la demona pordo |
| rsync per SSH | SSH-finpunkto, konto kaj malproksima rsync-aranĝo |
MacPorts dokumentas HTTP- kaj HTTPS-tarballfontojn en sources.conf kiel alternativojn kiam la kutima sinkroniga transporto ne disponeblas. Elektu la fonton subtenatan de la projekto por la instalita eldono; ŝanĝi la URI-skemon ne estas permeso montri al arbitra arkivo.
RSYNC_PROXY de rsync estas reteja prokurila mekanismo, ne ĝenerala SOCKS-URL-agordo. La demona itinero kutime bezonas pordon 873, kiun alie funkcianta reteja prokurilo povas intence rifuzi. La aparta mekanismo RSYNC_CONNECT_PROG povas anstataŭigi la rektan demonan ingon per helpilo, sed la helpilo devas liveri la atendatan bajtfluon.
Fine, notu kiun MacPorts-etapon malsukcesis. Ĝisdatigi la porthavan arbon, akiri arkivon kaj elŝuti la fontdosierojn de pordo ne devas uzi unu transporton. Ripari la unuan itineron ne pruvas, ke la aliaj kunhavas ĝian prokurilon.