A rotación de espellos cambia o que Squid pode reutilizar

Dous clientes descargan o mesmo RPM a través de Squid, pero a segunda transferencia segue chegando a un espello. Compare as URL completas das solicitudes:

http://mirror-a.example.net/packages/tool-1.0.rpm
http://mirror-b.example.net/packages/tool-1.0.rpm

Os nomes de ficheiro do paquete coinciden; as súas URI de destino difiren. As claves de caché HTTP inclúen polo menos o método da solicitude e a URI de destino, así que as sumas de verificación coincidentes do paquete non unen automaticamente estas entradas.

Yum e DNF poden usar un baseurl fixo ou descubrir espellos mediante mirrorlist e metalink. Por iso, instalacións idénticas poden escoller URL de descarga distintas.

Usar un só espello aprobado dá ás solicitudes visibles unha identidade de caché coherente. Manteña aliñados os camiños do repositorio, a arquitectura e o suite. Fixar o espello tamén cambia a dispoñibilidade e o comportamento de selección de espellos, así que convírtao nunha decisión de política do repositorio.

Comprobe se o almacenamento en caché de obxectos está dispoñible

Dentro dun túnel HTTPS CONNECT normal, Squid non pode ver o corpo da resposta RPM para o almacenamento en caché HTTP. Un nome de host de espello común non o cambiará. Manteña os repositorios HTTPS cifrados.

Para as respostas que Squid pode almacenar, a reutilización segue dependendo da frescura, das directivas de solicitude e resposta e da política local de caché. Rexistre a URL elixida, se a transacción foi HTTP visible ou un túnel cifrado, e o seu resultado de caché para explicar un fallo.