როდის შეუძლია 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 ქეშის ხელახალ გამოყენებას დაეყრდნოს.