मिरर रोटेशन Squid काय पुन्हा वापरू शकतो ते बदलते

दोन क्लायंट 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 असतात, म्हणून जुळणारे पॅकेज चेकसम या नोंदी स्वयंचलितपणे एकत्र करत नाहीत.

Yum आणि DNF निश्चित baseurl वापरू शकतात किंवा mirrorlist आणि metalink द्वारे मिरर शोधू शकतात. त्यामुळे एकसारखी प्रतिष्ठापने वेगळे डाउनलोड URL निवडू शकतात.

एक मंजूर मिरर वापरल्यास दृश्यमान विनंत्यांना सुसंगत कॅशे ओळख मिळते. रेपॉझिटरी मार्ग, आर्किटेक्चर आणि सूट सुसंगत ठेवा. पिनिंग उपलब्धता आणि मिरर-निवड वर्तनही बदलते, म्हणून ते रेपॉझिटरी धोरणाचा निर्णय करा.

ऑब्जेक्ट कॅशिंग उपलब्ध आहे का ते तपासा

सामान्य HTTPS CONNECT बोगद्यात Squid HTTP कॅशिंगसाठी RPM प्रतिसादाचा मुख्य भाग पाहू शकत नाही. सामायिक मिरर होस्टनाव ते बदलणार नाही. HTTPS रेपॉझिटरी एन्क्रिप्टेड ठेवा.

Squid कॅशे करू शकणाऱ्या प्रतिसादांसाठी, पुनर्वापर ताजेपणा, विनंती व प्रतिसाद निर्देश आणि स्थानिक कॅशे धोरणावर अवलंबून असतो. निवडलेला URL, व्यवहार दृश्यमान HTTP होता की एन्क्रिप्टेड बोगदा, आणि त्याचा कॅशे निकाल नोंदवा जेणेकरून चुकीची समजूत होऊ नये.