ကလိုင်းနှစ်ခုသည် Squid မှတစ်ဆင့် တူညီသော RPM ကို ဒေါင်းလုဒ်လုပ်သော်လည်း ဒုတိယ လွှဲပြောင်းမှုသည် မှန်ပြောင်းတစ်ခုထံ ရောက်ရှိနေဆဲဖြစ်သည်။ အပြည့်အစုံ တောင်းဆိုမှု URL များကို နှိုင်းယှဉ်ပါ-

http://mirror-a.example.net/packages/tool-1.0.rpm
http://mirror-b.example.net/packages/tool-1.0.rpm

ပက်ကေ့ဂျ် ဖိုင်အမည်များ ကိုက်ညီသည်။ ၎င်းတို့၏ ပစ်မှတ် URI များ ကွာခြားသည်။ HTTP ကက်ရှ်သော့များတွင် အနည်းဆုံး တောင်းဆိုမှုနည်းလမ်းနှင့် ပစ်မှတ် URI ပါဝင်သောကြောင့် ကိုက်ညီသော ပက်ကေ့ဂျ် checksum များသည် ဤထည့်သွင်းမှုများကို အလိုအလျောက် မပေါင်းစပ်ပါ။

Yum နှင့် DNF သည် ပုံသေ baseurl ကို အသုံးပြုနိုင်သည် သို့မဟုတ် mirrorlist နှင့် metalink မှတစ်ဆင့် မှန်ပြောင်းများကို ရှာဖွေနိုင်သည်။ ထို့ကြောင့် တူညီသော တပ်ဆင်မှုများသည် မတူညီသော ဒေါင်းလုဒ် URL များကို ရွေးချယ်နိုင်သည်။

အတည်ပြုထားသော မှန်ပြောင်းတစ်ခုကို အသုံးပြုခြင်းသည် မြင်နိုင်သော တောင်းဆိုမှုများကို တသမတ်တည်း ကက်ရှ်အထောက်အထား ပေးသည်။ repository လမ်းကြောင်းများ၊ ဗိသုကာနှင့် suite ကို ညှိထားပါ။ ပင်ထိုးခြင်းသည် ရရှိနိုင်မှုနှင့် မှန်ပြောင်းရွေးချယ်မှု အပြုအမူကိုလည်း ပြောင်းလဲသည်၊ ထို့ကြောင့် ၎င်းကို repository မူဝါဒ ဆုံးဖြတ်ချက်အဖြစ် ပြုလုပ်ပါ။

အရာဝတ္ထု ကက်ရှ်ခြင်း ရရှိနိုင်ခြင်း ရှိမရှိ စစ်ဆေးပါ

သာမန် HTTPS CONNECT လိုဏ်ခေါင်းအတွင်း Squid သည် HTTP ကက်ရှ်အတွက် RPM တုံ့ပြန်မှု ကိုယ်ထည်ကို မတွေ့နိုင်ပါ။ ဘုံ မှန်ပြောင်း hostname သည် ၎င်းကို မပြောင်းလဲပါ။ HTTPS repository များကို ကုဒ်ဝှက်ထားပါ။

Squid ကက်ရှ်လုပ်နိုင်သော တုံ့ပြန်မှုများအတွက် ပြန်လည်အသုံးပြုခြင်းသည် လတ်ဆတ်မှု၊ တောင်းဆိုမှုနှင့် တုံ့ပြန်မှု ညွှန်ကြားချက်များနှင့် ဒေသတွင်း ကက်ရှ်မူဝါဒအပေါ် မူတည်နေဆဲဖြစ်သည်။ ရွေးချယ်ထားသော URL၊ အရောင်းအဝယ်သည် မြင်နိုင်သော HTTP လား ကုဒ်ဝှက်ထားသော လိုဏ်ခေါင်းလား နှင့် ၎င်း၏ ကက်ရှ်ရလဒ်ကို မှတ်တမ်းတင်ပါ။

ဆက်စပ်ဆောင်းပါးများ