Uyuni proxy Squid cache refresh/expiry

[ppanon2022]

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?

[rjmateus]

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.
Squid configuration is in here, in case you want to have a look and know more about it:https://github.com/uyuni-project/uyuni/blob/master/containers/proxy-squid-image/squid.conf

[rjmateus]

another thing to add is also the flag refresh-ims, to allow the refresh if the request sends If-Modified-Since.

[ppanon2022]

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!

[ppanon2022]

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
4:51PM INF Welcome to mgrpxy
4:51PM INF Executing command: clear
Error: failed to re-create the cache directories: 2025/03/14 23:51:19| Processing Configuration File: /etc/squid/squid.conf (depth 0)
2025/03/14 23:51:19| WARNING: (B) '::/0' is a subnetwork of (A) '::/0'
2025/03/14 23:51:19| WARNING: because of this '::/0' is ignored to keep splay tree searching predictable
2025/03/14 23:51:19| WARNING: You should probably remove '::/0' from the ACL named 'all'
2025/03/14 23:51:19| Processing Configuration File: /etc/squid/conf.d/squid_example.conf (depth 1)
2025/03/14 23:51:19| Processing Configuration File: /etc/squid/conf.d/squid_tuning.conf (depth 1)
2025/03/14 23:51:19| WARNING: use of 'override-expire' in 'refresh_pattern' violates HTTP
2025/03/14 23:51:19| WARNING: use of 'override-lastmod' in 'refresh_pattern' violates HTTP
2025/03/14 23:51:19| WARNING: use of 'reload-into-ims' in 'refresh_pattern' violates HTTP
2025/03/14 23:51:19| WARNING: use of 'ignore-reload' in 'refresh_pattern' violates HTTP
2025/03/14 23:51:19| WARNING: use of 'ignore-no-store' in 'refresh_pattern' violates HTTP
2025/03/14 23:51:19| WARNING: use of 'ignore-private' in 'refresh_pattern' violates HTTP
2025/03/14 23:51:19| FATAL: Squid is already running: Found fresh instance PID file (/run/squid/squid.pid) with PID 1
exception location: Instance.cc(122) ThrowIfAlreadyRunningWith

[aaannz]

We have a bug in the redirect where the listing works fine, but the generated links are missing /pub prefix so clicking on them will throw 404.

About the cache clear, seems like a bug too. Will restart of the service resolve that?

[ppanon2022]

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.

Update: Have since upgraded to Uyuni 2025.07. Recently had to flush the squid caches on our Uyuni proxies to speed up the refresh of the expired PGP key and the repository metadata signatures. mgrpxy cache clear still didn't work properly and wound up using
podman exec uyuni-proxy-squid find /var/cache/squid -type f -exec rm -f {} ;
to clear all the cache data, followed by a container restart with mgrpxy restart, which seems to rebuild an empty cache index.