[Pkg-nginx-maintainers] Bug#822792: urmom
Michael Lustfield
michael at lustfield.net
Wed Oct 19 07:19:07 UTC 2016
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
More information about the Pkg-nginx-maintainers
mailing list