Squid কখন APT প্যাকেজ ক্যাশ করতে পারে
প্যাকেজ অনুরোধ Squid হিট হওয়ার আশা করার আগে HTTP পরিবহন, ক্যাশ স্টোরেজ, অবজেক্টের আকার এবং APT-এর cache-control সেটিংস যাচাই করুন।
APT এবং aptitude HTTP-এর মাধ্যমে রিপোজিটরি ফাইল আনতে পারে। Squid উপযুক্ত HTTP প্রতিক্রিয়া ক্যাশ করতে পারে; ক্লায়েন্টকে ওয়েব ব্রাউজার হতে হবে না।
Squid 6 বা 7 স্থাপনায়, প্রতিটি প্যাকেজ স্থানান্তর যখন এখনও উৎসে পৌঁছায় তখন এই ইনপুটগুলো যাচাই করুন:
- ডাউনলোডটি HTTP ব্যবহার করে, অথবা Squid অন্য উপায়ে HTTP বিনিময়ে প্রবেশাধিকার পায়। শুধু একটি HTTPS CONNECT টানেল প্যাকেজ প্রতিক্রিয়াকে ক্যাশ করার জন্য উন্মুক্ত করে না।
- ক্যাশে উপযুক্ত স্টোরেজ কনফিগার করা আছে। সফল ফরওয়ার্ডিং ডিস্ক ক্যাশ থাকার প্রমাণ নয়।
- আর্কাইভটি প্রযোজ্য ক্যাশ ডিরেক্টরির সর্বোচ্চ অবজেক্ট আকারে ফিট করে। ছোট মেটাডেটা এবং বড় .deb ভিন্ন ফলাফল দিতে পারে।
- অনুরোধ ও প্রতিক্রিয়া তাদের cache-control নীতির অধীনে সংরক্ষণ ও পুনরায় ব্যবহারের অনুমতি দেয়।
APT Acquire::http::No-Cache, Max-Age এবং No-Store প্রকাশ করে। No-Store অনুরোধ করা আর্কাইভ ফাইল সংরক্ষণে বাধা দিতে পারে। No-Cache সংরক্ষিত প্রতিক্রিয়া পুনরায় ব্যবহারের আগে পুনরায় বৈধতা যাচাই চায়। কার্যকর APT কনফিগারেশন এবং Squid-এর নীতি—দুটোই পরীক্ষা করুন।
একই সম্পূর্ণ URL তুলনা করুন এবং access.log-এ ক্যাশ ফলাফল পরীক্ষা করুন। ভিন্ন মিরর হোস্ট, পরিবর্তিত রিপোজিটরি পথ বা স্থানীয়ভাবে ক্যাশ করা প্যাকেজ বোঝাতে পারে যে দুটি ইনস্টল কখনও একই নেটওয়ার্ক অবজেক্ট অনুরোধ করে না।
একটি রিপোজিটরি মিরর কেবল চাহিদা-চালিত HTTP ক্যাশ পুনঃব্যবহারের উপর নির্ভর না করে সচেতনভাবে রিপোজিটরি বিষয়বস্তু রক্ষণাবেক্ষণ করে।