A rotação de espelhos muda o que o Squid pode reutilizar

Dois clientes baixam o mesmo RPM através do Squid, mas a segunda transferência ainda chega a um espelho. Compare as URLs completas das requisições:

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

Os nomes dos arquivos do pacote coincidem; seus URIs de destino diferem. As chaves de cache HTTP incluem pelo menos o método da requisição e o URI de destino, então somas de verificação iguais do pacote não unem automaticamente essas entradas.

O Yum e o DNF podem usar um baseurl fixo ou descobrir espelhos por meio de mirrorlist e metalink. Por isso, instalações idênticas podem escolher URLs de download diferentes.

Usar um único espelho aprovado dá às requisições visíveis uma identidade de cache consistente. Mantenha os caminhos do repositório, a arquitetura e o conjunto alinhados. A fixação também altera a disponibilidade e o comportamento de seleção de espelhos, portanto faça disso uma decisão de política do repositório.

Verifique se o cache de objetos está disponível

Dentro de um túnel HTTPS CONNECT comum, o Squid não consegue ver o corpo da resposta RPM para o cache HTTP. Um nome de host de espelho comum não mudará isso. Mantenha os repositórios HTTPS criptografados.

Para respostas que o Squid pode armazenar, a reutilização ainda depende da frescura, das diretivas de requisição e resposta e da política local de cache. Registre a URL escolhida, se a transação foi HTTP visível ou um túnel criptografado, e o resultado do cache para explicar uma falha.