La rotation des miroirs change ce que Squid peut réutiliser
Expliquez pourquoi des paquets RPM identiques téléchargés depuis différentes URL de miroir peuvent occuper des entrées de cache Squid distinctes.
Deux clients téléchargent le même RPM via Squid, mais le second transfert atteint encore un miroir. Comparez les URL complètes des requêtes :
http://mirror-a.example.net/packages/tool-1.0.rpm
http://mirror-b.example.net/packages/tool-1.0.rpmLes noms de fichiers du paquet correspondent ; leurs URI cibles diffèrent. Les clés de cache HTTP incluent au moins la méthode de la requête et l'URI cible, donc des sommes de contrôle identiques du paquet ne fusionnent pas automatiquement ces entrées.
Yum et DNF peuvent utiliser une baseurl fixe ou découvrir des miroirs via mirrorlist et metalink. Des installations identiques peuvent donc choisir des URL de téléchargement différentes.
L'usage d'un seul miroir approuvé donne aux requêtes visibles une identité de cache cohérente. Gardez les chemins du dépôt, l'architecture et la suite alignés. L'épinglage modifie aussi la disponibilité et le comportement de sélection des miroirs, faites-en donc une décision de politique de dépôt.
Vérifiez si la mise en cache d'objets est disponible
Dans un tunnel HTTPS CONNECT ordinaire, Squid ne peut pas voir le corps de la réponse RPM pour la mise en cache HTTP. Un nom d'hôte de miroir commun n'y changera rien. Gardez les dépôts HTTPS chiffrés.
Pour les réponses que Squid peut mettre en cache, la réutilisation dépend encore de la fraîcheur, des directives de requête et de réponse et de la politique de cache locale. Notez l'URL choisie, si la transaction était du HTTP visible ou un tunnel chiffré, et son résultat de cache pour expliquer un échec.