This vs cache-purge module

Hello. How does your solution compare with a combo of NGINX Cache Purge module with Proxy Cache Purge plugin? The former solves any permissions issue, while the latter automatically clears cache for modified content.

@dvershinin NPP offers more direct solution without any external module. This plugin directly traverse cache directory and clear cache if PHP-FPM and WEBSERVER user permissions adjusted properly. To automate and fix this permission issues there is a pre-made bash script works on server side.

bash <(curl -Ss https://psaux-it.github.io/install.sh)

Note that, NPP also support Nginx cache preloading again a simple direct approach, with help of wget.

There are many cases the module you mentioned works fine for cache purge operations but also integrating module to nginx is a challenging topic for non-technical/regular wordpress user. Not every linux distro packaged this module or have outdated module version so user may need to follow extra steps to integrate it which becomes more complicated.

Also there are other cases, even bleeding edge module version easily installed and integrated with nginx by user still purge operations not works as expected. This is what I faced before and decided to develop NPP.

In short if you are working setup with the module you mentioned and existing wordpress plugins already you stay with your working setup or you can give a chance to NPP and try to additional nginx cache preload feature too.

There is more in depth info here

PHP-FPM and WEBSERVER user permissions adjusted properly

PHP-FPM and WEBSERVER user permissions adjusted properly what does it mean?

if I install LEMP on Ubuntu with multi user environment, each user have their own PHP-FPM pool, such the following setup:

PHP-FPM pool set to someuser
Web directories & files set chown to someuser
Nginx set to www-data
Nginx fastcgi cache set to /path/to/dir/fastcgi_cache

is the plugins work?

@joglomedia

In Short

In short, yes. It's straightforward: just call this one-liner pre-made bash script on your host and follow instructions. I recommend this automation strongly with NPP plugin .

bash <(curl -Ss https://psaux-it.github.io/install.sh)

Long Technical Story

In properly configured Nginx servers, it is not strictly necessary to have separate PHP-FPM-USER (as known WEBSITE-USER or process owner) and WEBSERVER-USER (commonly, nginx or www-data), but there are scenarios where separating these users can enhance security and performance. Here’s why:

Security: By running the PHP-FPM process under a different user than the Nginx web server, you reduce the risk of privilege escalation. If one process is compromised, the attacker does not automatically gain control over the other process.

Permission Management: Having separate users allows for more granular permission settings. For example, PHP scripts can be restricted to only the directories they need to access, while the web server user can be given more restrictive permissions on other parts of the filesystem.

Resource Management: Separate users can help with resource management and monitoring, as it becomes easier to track resource usage per user.

In your current web server setup, you have two distinct users: PHP-FPM-USER (someuser) and WEBSERVER-USER (www-data), which is the recommended configuration. The key requirement here is to grant someuser read/write permissions to the Nginx Cache Path /path/to/dir/fastcgi_cache, which is owned by www-data on your server. This can be achieved using inotifywait and setfacl.

If you don't want to use pre-made automation script cause trust issues you can easily integrate your basic solution like that. Create a bash associative array that stores "PHP-FPM-USER | Nginx Cache Path" pairs, such as "someuser /path/to/dir/fastcgi_cache". Then, loop over this array to use inotifywait and setfacl.

  # Let's start "PHP-FPM-USER | Nginx Cache Path" instances;
  for user in "${!fcgi[@]}"; do
    IFS=':' read -r -a paths <<< "${fcgi[$user]}"

    for path in "${paths[@]}"; do
      if ! pgrep -f "inotifywait.*${path}" >/dev/null 2>&1; then
        # Trigger one time recursive
        setfacl -R -m u:"${user}":rwX,g:"${user}":rwX "${path}"/

        # Start inotifywait/setfacl
        while read -r directory event file_folder; do
          # While this loop is working, if fastcgi cache path
          # is deleted manually by the user that causes strange
          # behaviors, kill it
          if [[ ! -d "${path}" ]]; then
            echo "!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!"
            echo "Nginx Cache folder ${path} destroyed manually, inotifywait/setfacl process for PHP-FPM-USER: ${user} is killed!"
            echo "!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!"
            break
          fi

          # Set ACLs for files and folders created and modified in cache directory
          setfacl -R -m u:"${user}":rwX,g:"${user}":rwX "${path}"/
        done < <(inotifywait -m -q -e modify,create -r "${path}") >/dev/null 2>&1 &
      else
        echo -e "\e[93mWarning: \e[96mNginx FastCGI cache directory: (\e[93m${path}\e[96m) is already listening, EXCLUDED for PHP-FPM-USER: (\e[93m${user}\e[96m)\e[0m"
      fi
    done
  done

@joglomedia

In Short

In short, yes. It's straightforward: just call this one-liner pre-made bash script on your host and follow instructions. I recommend this automation strongly with NPP plugin .

bash <(curl -Ss https://psaux-it.github.io/install.sh)

Long Technical Story

In properly configured Nginx servers, it is not strictly necessary to have separate PHP-FPM-USER (as known WEBSITE-USER or process owner) and WEBSERVER-USER (commonly, nginx or www-data), but there are scenarios where separating these users can enhance security and performance. Here’s why:

Security: By running the PHP-FPM process under a different user than the Nginx web server, you reduce the risk of privilege escalation. If one process is compromised, the attacker does not automatically gain control over the other process.

Permission Management: Having separate users allows for more granular permission settings. For example, PHP scripts can be restricted to only the directories they need to access, while the web server user can be given more restrictive permissions on other parts of the filesystem.

Resource Management: Separate users can help with resource management and monitoring, as it becomes easier to track resource usage per user.

In your current web server setup, you have two distinct users: PHP-FPM-USER (someuser) and WEBSERVER-USER (www-data), which is the recommended configuration. The key requirement here is to grant someuser read/write permissions to the Nginx Cache Path /path/to/dir/fastcgi_cache, which is owned by www-data on your server. This can be achieved using inotifywait and setfacl.

If you don't want to use pre-made automation script cause trust issues you can easily integrate your basic solution like that. Create a bash associative array that stores "PHP-FPM-USER | Nginx Cache Path" pairs, such as "someuser /path/to/dir/fastcgi_cache". Then, loop over this array to use inotifywait and setfacl.
  # Let's start "PHP-FPM-USER | Nginx Cache Path" instances;
  for user in "${!fcgi[@]}"; do
    IFS=':' read -r -a paths <<< "${fcgi[$user]}"

    for path in "${paths[@]}"; do
      if ! pgrep -f "inotifywait.*${path}" >/dev/null 2>&1; then
        # Trigger one time recursive
        setfacl -R -m u:"${user}":rwX,g:"${user}":rwX "${path}"/

        # Start inotifywait/setfacl
        while read -r directory event file_folder; do
          # While this loop is working, if fastcgi cache path
          # is deleted manually by the user that causes strange
          # behaviors, kill it
          if [[ ! -d "${path}" ]]; then
            echo "!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!"
            echo "Nginx Cache folder ${path} destroyed manually, inotifywait/setfacl process for PHP-FPM-USER: ${user} is killed!"
            echo "!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!"
            break
          fi

          # Set ACLs for files and folders created and modified in cache directory
          setfacl -R -m u:"${user}":rwX,g:"${user}":rwX "${path}"/
        done < <(inotifywait -m -q -e modify,create -r "${path}") >/dev/null 2>&1 &
      else
        echo -e "\e[93mWarning: \e[96mNginx FastCGI cache directory: (\e[93m${path}\e[96m) is already listening, EXCLUDED for PHP-FPM-USER: (\e[93m${user}\e[96m)\e[0m"
      fi
    done
  done

When I create the second fpm user (someuser2), What will happen to the someuser2's cache if someuser doing purge all via NPP and vice versa?

@joglomedia

Each PHP-FPM user represents a unique WordPress instance (website) to ensure permission isolation.
Every WordPress instance should have its own separate Nginx Cache Path.
You need to install the NPP plugin on all your WordPress instances and set the Nginx Cache Path in the plugin settings according to your existing Nginx setup.

If have you multiple WordPress instances on the same host, deploying just one instance of the automation script bash <(curl -Ss https://psaux-it.github.io/install.sh) to server side will effectively grant read/write permissions to every automatically matched PHP-FPM user and Nginx Cache Path pair, allowing it to manage all WordPress instances with NPP plugin. If auto detection not works for you continue with manual setup.

[!NOTE] With this structure, each NPP plugin installed for every WordPress instance, each with its unique PHP-FPM user, is responsible for purging the cache associated with its specific Nginx Cache Path.

[!IMPORTANT]
The best practice is to have each PHP-FPM user represent a unique WordPress instance. This approach ensures proper permission isolation and better manageability. If you have multiple WordPress instances under the same PHP-FPM user, this setup is neither accurate nor manageable. This setup does not isolate permissions for WordPress instances; It is not as problematic as having the root process owner, such as nginx or www-data (webserver user), also own your WordPress instance, but it is still not ideal.

psaux-it / nginx-fastcgi-cache-purge-and-preload