სარკეების როტაცია ცვლის იმას, რისი ხელახლა გამოყენებაც Squid-ს შეუძლია

ორი კლიენტი ერთსა და იმავე RPM-ს ჩამოტვირთავს Squid-ის მეშვეობით, მაგრამ მეორე გადაცემა მაინც აღწევს სარკეს. შეადარეთ მოთხოვნების სრული URL-ები:

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

პაკეტის ფაილების სახელები ემთხვევა; მათი სამიზნე URI-ები განსხვავდება. HTTP ქეშის გასაღებები მოიცავს სულ მცირე მოთხოვნის მეთოდს და სამიზნე URI-ს, ამიტომ პაკეტის დამთხვეული საკონტროლო ჯამები ავტომატურად არ აერთიანებს ამ ჩანაწერებს.

Yum და DNF შეიძლება იყენებდნენ ფიქსირებულ baseurl-ს ან აღმოაჩინონ სარკეები mirrorlist-ისა და metalink-ის მეშვეობით. ამიტომ იდენტურმა ინსტალაციებმა შეიძლება სხვადასხვა ჩამოტვირთვის URL აირჩიონ.

ერთი დამტკიცებული სარკის გამოყენება ხილულ მოთხოვნებს აძლევს ქეშის თანმიმდევრულ იდენტობას. შეინარჩუნეთ საცავის ბილიკები, არქიტექტურა და კრებული შესაბამისობაში. მიმაგრება ასევე ცვლის ხელმისაწვდომობას და სარკის არჩევის ქცევას, ამიტომ გახადეთ ის საცავის პოლიტიკის გადაწყვეტილება.

შეამოწმეთ, ხელმისაწვდომია თუ არა ობიექტების ქეშირება

ჩვეულებრივი HTTPS CONNECT გვირაბის შიგნით Squid ვერ ხედავს RPM პასუხის სხეულს HTTP ქეშირებისთვის. სარკის საერთო ჰოსტის სახელი ამას არ შეცვლის. შეინახეთ HTTPS საცავები დაშიფრული.

იმ პასუხებისთვის, რომელთა ქეშირებაც Squid-ს შეუძლია, ხელახალი გამოყენება კვლავ დამოკიდებულია სიახლეზე, მოთხოვნისა და პასუხის დირექტივებზე და ლოკალურ ქეშის პოლიტიკაზე. ჩაწერეთ არჩეული URL, იყო თუ არა ტრანზაქცია ხილული HTTP თუ დაშიფრული გვირაბი, და მისი ქეშის შედეგი, რომ ახსნათ გამოტოვება.