Uyuni proxy Squid cache refresh/expiry #9964
Replies: 1 comment 7 replies
-
|
Files cached in the proxy should check for changes in the server side, and update the cache accordingly. The mod_wsgi is redirecting to squid, and if the data is not present it will fetch from the server. |
Beta Was this translation helpful? Give feedback.
-
|
another thing to add is also the flag |
Beta Was this translation helpful? Give feedback.
-
|
Well, it looks like I misremembered how the mod-wsgi module worked. I thought it was on the other side of the Squid cache. But thank you Ondrej, 525K minutes does seem a little high for the cache expiry :-). It did seem to eventually sort-of refresh the timestamps for everything in that directory after a couple of days, but returned 404 errors when trying to download the files, so there must have been something else which triggered that refresh. A change to a 5 minute expiry does seem helpful - even 15m would be a big improvement. We've got a few proxies, so it makes more sense for us to wait until a new release includes the change than to try to manually change it on all and possibly introduce some human errors. Thanks for the quick response! |
Beta Was this translation helpful? Give feedback.
-
|
Hmm. I had the bright idea of trying to flush the squid cache to force it to pick up the new versions of files, and it didn't work quite as well as hoped. (names changed to protect the guilty) [admin@MyUyuniProxy ~]$ sudo mgrpxy cache clear |
Beta Was this translation helpful? Give feedback.
-
|
We have a bug in the redirect where the listing works fine, but the generated links are missing About the cache clear, seems like a bug too. Will restart of the service resolve that? |
Beta Was this translation helpful? Give feedback.
-
|
No, a restart of the service did not fix it. I wound up opening a shell in the context of the squid container with podman exec -it uyuni-proxy-squid /bin/bash . Nearly all the cache directories were gone and the few that were there were empty, so it looks like it was messed up when trying to rebuild the cache directory structure. I couldn't use squid -z because the caching squid process was running and killing it caused the container to halt. Wound up creating all the missing cache directories with a few bash for loops using that exec'd shell and then doing a mgrpxy restart. |
Beta Was this translation helpful? Give feedback.
-
IIRC, when squid caches a file, it normally does a sort of "metadata header" check on subsequent accesses and uses the last modify date to determine if the file has been modified and the cache entry needs to be refreshed, no? With the way the Uyuni Proxy uses the loopback to the mod_wsgi handler for fetching files from the master server, that doesn't seem to be happening.
In the bootstrap directory, we have some wrapper scripts around bootstrap scripts that do different things depending on the client running the bootstrap (i.e. deploying enterprise PKI keys or running different bootstrap scripts with different activation keys or proxy choices depending on the O/S version and location of the target system). When making updates to those scripts to support new O/S versions or new sites, the changes don't appear to be reflected in the script copies obtained from the squid cache of the Uyuni proxies, even after many hours.
Is this expected behaviour or a bug/oversight in the mod_wsgi handler implementation? What is the default cache expiry time before the updates are usable from the proxies?
Beta Was this translation helpful? Give feedback.
All reactions