Quand Squid peut mettre en cache les paquets APT
Vérifiez le transport HTTP, le stockage du cache, la taille des objets et les réglages cache-control d'APT avant d'attendre que les requêtes de paquets deviennent des hits Squid.
APT et aptitude peuvent récupérer les fichiers de dépôt via HTTP. Squid peut mettre en cache une réponse HTTP éligible ; le client n'a pas besoin d'être un navigateur web.
Dans un déploiement Squid 6 ou 7, vérifiez ces entrées lorsque chaque transfert de paquet atteint encore l'origine :
- Le téléchargement utilise HTTP, ou Squid a autrement accès à l'échange HTTP. Un tunnel HTTPS CONNECT seul n'expose pas la réponse du paquet à la mise en cache.
- Le cache dispose d'un stockage adapté. Un transfert réussi ne prouve pas qu'un cache disque existe.
- L'archive tient dans la taille maximale d'objet du répertoire de cache applicable. De petites métadonnées et un gros .deb peuvent donner des résultats différents.
- La requête et la réponse autorisent le stockage et la réutilisation selon leur politique cache-control.
APT expose Acquire::http::No-Cache, Max-Age et No-Store. No-Store peut empêcher l'enregistrement des fichiers d'archive demandés. No-Cache demande une revalidation avant de réutiliser une réponse stockée. Inspectez la configuration APT effective ainsi que la politique de Squid.
Comparez la même URL complète et inspectez le résultat du cache dans access.log. Des hôtes miroirs différents, des chemins de dépôt modifiés ou un paquet mis en cache localement peuvent signifier que deux installations ne demandent jamais le même objet réseau.
Un miroir de dépôt maintient délibérément le contenu du dépôt au lieu de compter uniquement sur la réutilisation du cache HTTP à la demande.