MacPorts-ის rsync წყაროების მარშრუტიზაცია პროქსის გავლით
შეუსაბამეთ ports tree წყაროს პროტოკოლი პროქსის ტრანსპორტს იმის ნაცვლად, რომ ჩათვალოთ, SSH მაგალითი rsync daemon-ის კავშირსაც ასწორებს.
ბრაუზერი SOCKS-ის გავლით მუშაობს. ჩვეულებრივი SSH სესიაც. შემდეგ MacPorts ჩერდება ports tree-ის სინქრონიზაციისას. სანამ კიდევ ერთ SSH ვარიანტს დაამატებთ, შეხედეთ წყაროს URI-ს.
rsync://host/module rsync daemon-ის სერვისს აღნიშნავს. rsync -e ssh user@host:path-ის მაგალითი დისტანციურ shell-ს იყენებს და ამ ჰოსტზე შესაბამის ანგარიშზე წვდომას მოითხოვს. საჯარო rsync სარკე SSH-შესვლას არ იღებს მხოლოდ იმიტომ, რომ კლიენტს ProxyCommand აქვს.
სამი გზა განსხვავებული წინაპირობებით
| გზა | რა უნდა არსებობდეს |
|---|---|
| Ports tree-ის snapshot HTTP ან HTTPS-ით | მხარდაჭერილი snapshot წყარო და მოქმედი HTTP პროქსის კონფიგურაცია |
| rsync daemon ვებ პროქსის გავლით | rsync კლიენტი RSYNC_PROXY-ით და პროქსი, რომელიც daemon-ის პორტზე CONNECT-ს უშვებს |
| rsync SSH-ის გავლით | SSH ბოლო წერტილი, ანგარიში და დისტანციური rsync მოწყობა |
MacPorts sources.conf-ში HTTP და HTTPS tarball წყაროებს ალტერნატივად აღწერს, როცა ჩვეულებრივი sync ტრანსპორტი მიუწვდომელია. აირჩიეთ პროექტის მიერ მხარდაჭერილი წყარო დაყენებული გამოშვებისთვის; URI სქემის შეცვლა ნებართვა არ არის თვითნებურ არქივზე მითითებისა.
rsync-ის RSYNC_PROXY ვებ-პროქსის მექანიზმია და არა SOCKS URL-ის ზოგადი პარამეტრი. daemon-ის გზას ჩვეულებრივ სჭირდება 873 პორტი, რომელზეც სხვაგვარად მუშა ვებ პროქსის შეუძლია განზრახ უარი თქვას. ცალკე RSYNC_CONNECT_PROG მექანიზმს შეუძლია პირდაპირი daemon სოკეტი დამხმარე პროგრამით ჩაანაცვლოს, მაგრამ დამხმარმა მოსალოდნელი ბაიტური ნაკადი უნდა მოგვცეს.
დაბოლოს, დააკვირდით MacPorts-ის რომელი ეტაპი ჩავარდა. ports tree-ის განახლებას, არქივის მოტანას და port-ის წყარო ფაილების ჩამოტვირთვას სულაც არ უნდა სჭირდებოდეს ერთი ტრანსპორტი. პირველი გზის შეკეთება არ ამტკიცებს, რომ დანარჩენები მის პროქსის იზიარებენ.