Mikor tud a Squid APT-csomagokat gyorsítótárazni
Ellenőrizze a HTTP-átvitelt, a gyorsítótár tárolóját, az objektum méretét és az APT cache-control beállításait, mielőtt arra számítana, hogy a csomagkérések Squid-találatokká válnak.
Az APT és az aptitude HTTP-n keresztül tud tárolófájlokat letölteni. A Squid képes gyorsítótárazni egy alkalmas HTTP-választ; az ügyfélnek nem kell webböngészőnek lennie.
Squid 6 vagy 7 telepítésnél ellenőrizze ezeket a bemeneteket, ha minden csomagátvitel még mindig eléri az origót:
- A letöltés HTTP-t használ, vagy a Squid más módon hozzáfér a HTTP-cseréhez. Önmagában egy HTTPS CONNECT-alagút nem teszi gyorsítótárazhatóvá a csomagválaszt.
- A gyorsítótár megfelelő tárolóval van beállítva. A sikeres továbbítás nem bizonyítja, hogy létezik lemezes gyorsítótár.
- Az archívum belefér az érintett gyorsítótár-könyvtár maximális objektumméretébe. A kis metaadatok és a nagy .deb eltérő eredményt adhat.
- A kérés és a válasz engedélyezi a tárolást és az újrafelhasználást a cache-control irányelvük szerint.
Az APT a Acquire::http::No-Cache, Max-Age és No-Store beállításokat kínálja. A No-Store megakadályozhatja a kért archívfájlok tárolását. A No-Cache újraérvényesítést kér a tárolt válasz újrafelhasználása előtt. Vizsgálja meg a tényleges APT-konfigurációt és a Squid irányelvét is.
Hasonlítsa össze ugyanazt a teljes URL-t, és vizsgálja meg a gyorsítótár eredményét az access.log fájlban. Különböző tükörgazdák, megváltozott tárolóútvonalak vagy egy helyben gyorsítótárazott csomag azt jelentheti, hogy két telepítés soha nem ugyanazt a hálózati objektumot kéri.
A tárolótükör szándékosan karbantartja a tároló tartalmát, ahelyett hogy csak az igényvezérelt HTTP-gyorsítótár újrafelhasználására támaszkodna.