La rotación de espejos cambia lo que Squid puede reutilizar

Dos clientes descargan el mismo RPM a través de Squid, pero la segunda transferencia sigue llegando a un espejo. Compare las URL completas de las solicitudes:

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

Los nombres de archivo del paquete coinciden; sus URI de destino difieren. Las claves de caché HTTP incluyen al menos el método de la solicitud y el URI de destino, así que las sumas de verificación coincidentes del paquete no unen automáticamente estas entradas.

Yum y DNF pueden usar un baseurl fijo o descubrir espejos mediante mirrorlist y metalink. Por eso, instalaciones idénticas pueden elegir URL de descarga distintas.

Usar un solo espejo aprobado da a las solicitudes visibles una identidad de caché coherente. Mantenga alineados las rutas del repositorio, la arquitectura y el suite. Fijar el espejo también cambia la disponibilidad y el comportamiento de selección de espejos, así que conviértalo en una decisión de política del repositorio.

Compruebe si el almacenamiento en caché de objetos está disponible

Dentro de un túnel HTTPS CONNECT normal, Squid no puede ver el cuerpo de la respuesta RPM para el almacenamiento en caché HTTP. Un nombre de host de espejo común no cambiará eso. Mantenga los repositorios HTTPS cifrados.

Para las respuestas que Squid puede almacenar, la reutilización sigue dependiendo de la frescura, las directivas de solicitud y respuesta y la política local de caché. Registre la URL elegida, si la transacción fue HTTP visible o un túnel cifrado, y su resultado de caché para explicar un fallo.