Well, my good and annoying sir! I want to be annoyed, but I do appreciate this persistent bug report. Thanks for following up with intelligent discussion.
There are two files allowed for packages: * /etc/nginx/conf.d/pkg_<package_name>.conf Optional. Prefer it's not used... ever. Should only create variable Variables should be prefixed with the package name * /etc/nginx/default-server.d/pkg_<package_name>.conf Required. location ^~ /<package_name> { ... } is REQUIRED to wrap everything All packages must follow latest version of php-fpm's socket location. ... or... grrrrr... Honestly, I would prefer we stop promoting the use of php-fpm for running PHP applications behind Nginx. My reasoning is that uwsgi is a much more flexible tool that offers individual application configurations. It also offers nicer security features. If someone wants to run something other than a PHP application, such as bottle.py, flask, django, whatever ruby thingies exist, etc., they'll already be looking for an alternative and uwsgi supports that. Should we request use of uwsgi as a default over php-fpm? In that scenario, each application would be using its own socket location and would have another configuration that the nginx packaging team could help with. The third file would become: * /etc/uwsgi/apps-enabled/pkg_<package_name>.ini [uwsgi] socket = /run/uwsgi/app/<package_name>/socket chdir = /usr/share/<package_name>/html master = true plugins = python file = app.py uid = www-data gid = www-data Disclaimer: I'm tired and some of this has been poorly revised. For the record, I don't dislike php-fpm and recall what a life saver it was to me when it was new. I, however, don't think it's the right tool for this job. -- Michael Lustfield