Spoguļu rotācija maina to, ko Squid var izmantot atkārtoti
Paskaidrojiet, kāpēc identiskas RPM pakotnes, kas lejupielādētas no dažādiem spoguļu URL, var aizņemt atsevišķus Squid kešatmiņas ierakstus.
Divi klienti lejupielādē vienu un to pašu RPM caur Squid, bet otrā pārsūtīšana joprojām sasniedz spoguli. Salīdziniet pilnos pieprasījuma URL:
http://mirror-a.example.net/packages/tool-1.0.rpm
http://mirror-b.example.net/packages/tool-1.0.rpmPakotnes failu nosaukumi sakrīt; to mērķa URI atšķiras. HTTP kešatmiņas atslēgas ietver vismaz pieprasījuma metodi un mērķa URI, tāpēc sakrītošas pakotnes kontrolsummas šos ierakstus automātiski neapvieno.
Yum un DNF var izmantot fiksētu baseurl vai atklāt spoguļus, izmantojot mirrorlist un metalink. Tāpēc identiskas instalācijas var izvēlēties dažādus lejupielādes URL.
Viena apstiprināta spoguļa izmantošana dod redzamiem pieprasījumiem konsekventu kešatmiņas identitāti. Turiet repozitorija ceļus, arhitektūru un komplektu saskaņotus. Piespraušana arī maina pieejamību un spoguļa izvēles uzvedību, tāpēc padariet to par repozitorija politikas lēmumu.
Pārbaudiet, vai objektu kešatmiņa ir pieejama
Parastā HTTPS CONNECT tunelī Squid nevar redzēt RPM atbildes pamattekstu HTTP kešatmiņai. Kopīgs spoguļa resursdatora nosaukums to nemainīs. Turiet HTTPS repozitorijus šifrētus.
Atbildēm, ko Squid var kešot, atkārtota izmantošana joprojām ir atkarīga no svaiguma, pieprasījuma un atbildes direktīvām un vietējās kešatmiņas politikas. Ierakstiet izvēlēto URL, vai darījums bija redzams HTTP vai šifrēts tunelis, un tā kešatmiņas rezultātu, lai izskaidrotu garām palaišanu.