Apache Web Server and Yunohost Core – Cache Invalidation Interoperability Question
0 reputation · 18 Feb 2023, 11:01 UTC
0 reputation · 18 Feb 2023, 11:01 UTC
When an application on Yunohost is updated or its configuration changes, the Apache mod_cache module may continue to serve stale static or dynamic content until the TTL expires. Yunohost’s global "clear cache" button purges all cache entries, but it offers no per‑application granularity and can be slow for large sites.
The goal is to establish a reliable mechanism that automatically or manually invalidates cache entries belonging to a specific Yunohost app immediately after an update, without affecting unrelated applications.
Constraints include:
Unresolved decision: Should Yunohost expose a per‑application cache flush API that translates to mod_cache purge directives?
Specific questions:
To invalidate cache entries for a specific YunoHost application without performing a system-wide purge, you must target the specific cache keys generated by mod_cache_disk. Because YunoHost manages Apache virtual hosts, the cache keys are typically derived from the URL and the server's cache root directory.
Apache's mod_cache_disk stores content in a hashed directory structure based on the URL. There is no native "app-to-folder" mapping provided by YunoHost core; instead, Apache maps the full request URI to a specific file on disk. To programmatically target a specific app, you cannot simply delete a folder named after the app. You must either:
PURGE request to a specific URL, which instructs Apache to remove that specific entry.CacheRoot in Apache config) and use a script to find and remove files associated with the app's domain.A custom hook can be integrated into the YunoHost app-update lifecycle. Since YunoHost uses a set of scripts to manage app installation and updates, you can trigger a purge script post-update. Assuming mod_cache_purge is enabled, the hook would execute a curl command targeting the application's primary URLs:
# Example: Purging the home page of a specific app
curl -X PURGE http://app.yourdomain.tld/
If mod_cache_purge is not available, the hook must trigger a shell script to clear the CacheRoot directory. Note that without mod_cache_purge, granular invalidation is difficult because the disk layout is hashed, not hierarchical by domain.
The interaction between these layers depends on where the cache resides:
Cache-Control headers affect the TTL (how long Apache stores the item) but do not dictate how the cache is purged. A manual purge overrides these headers.To verify if your environment supports targeted purging, run the following command to check for the purge module:
apache2ctl -M | grep cache_purge
Missing Diagnostic Detail: Please specify if you are using a custom CacheRoot configuration or if you have a Varnish instance positioned in front of your YunoHost server, as this changes the required purge target.
Use comments to ask for clarification. Post a solution as an answer.
32,775 reputation · 18 Feb 2023, 12:17 UTC
With mod_cache_disk the entry is stored by a hash of the full request URI as seen by Apache, not by the app’s document root on disk. That means a per-app invalidation has to target the URL path for that virtual host, rather than deleting a directory named after the app.
Because Yunohost regenerates per-app vhosts on updates, manual edits to sites-available are overwritten. Any CacheRemove or CacheEnable lines are more durable when placed in the app’s custom config snippet that Yunohost preserves across regeneration.
Verify mod_cache is active via mods-enabled cache.conf and confirm CacheEnable is set for the vhost before testing a targeted purge.