La rotació de miralls canvia què pot reutilitzar Squid

Dos clients baixen el mateix RPM a través de Squid, però la segona transferència encara arriba a un mirall. Compareu les URL completes de les peticions:

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

Els noms dels fitxers del paquet coincideixen; les seves URI de destí difereixen. Les claus de la memòria cau HTTP inclouen com a mínim el mètode de la petició i l'URI de destí, així que les sumes de verificació coincidents del paquet no uneixen automàticament aquestes entrades.

Yum i DNF poden fer servir un baseurl fix o descobrir miralls mitjançant mirrorlist i metalink. Per tant, instal·lacions idèntiques poden triar URL de baixada diferents.

Fer servir un sol mirall aprovat dona a les peticions visibles una identitat de memòria cau coherent. Mantingueu alineats els camins del repositori, l'arquitectura i el suite. La fixació també canvia la disponibilitat i el comportament de selecció de miralls, així que feu-ne una decisió de política del repositori.

Comproveu si la memòria cau d'objectes està disponible

Dins d'un túnel HTTPS CONNECT ordinari, Squid no pot veure el cos de la resposta RPM per a la memòria cau HTTP. Un nom d'amfitrió de mirall compartit no ho canviarà. Mantingueu els repositoris HTTPS xifrats.

Per a les respostes que Squid pot emmagatzemar, la reutilització encara depèn de la frescor, les directives de petició i resposta i la política local de memòria cau. Registreu l'URL triada, si la transacció era HTTP visible o un túnel xifrat, i el seu resultat de memòria cau per explicar un error.