[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