[packages/nginx] Provide the vhosts.d and webapps.d directories

Jacek Konieczny jajcus at jajcus.net
Tue Oct 15 10:15:01 CEST 2013


Cc: pld-devel-en, as the discussion may be interesting for others too

On Tue, 15 Oct 2013 00:43:05 +0300
Elan Ruusamäe <glen at pld-linux.org> wrote:

> On 14/10/13 20:10, Jacek Konieczny wrote:
> >> (as you know the "other" webservers are populated with triggers
> > What triggers? You mean that '# make sure webapps.d is included' trigger
> > in apache.spec? That would be crazy.
> no, i mean in web app itself, like phpmyadmin. as a start how to use it. 
> not all packages of course!
> so template-specs/webapp.spec could be updated with samples.

I can see that. But there is a problem. This system was designed for one
of the most broken HTTP servers (Apache) and it is hard to make it work
well with other servers.

nginx is a HTTP server/proxy/load-balancer and a good one. Not an
application server.  Many webapps won't work with nginx alone. And often
the webapps would be running on a different server that nginx would run
on.

When deploying applications under nginx the apps are running under
uWSGI or as standalone FastCGI programs. They can be running under a
different UID/GID (which is desirable when many different webapps are
running on a single server) or on a different machine. The same could be
done with lighttpd, but Apache was never really made for such secure,
efficient and scalable scenario.

And our 'webapps' system is made for those Apache limitations:
– Requires: webserver(*), when the webserver is not needed on the local
machine
– drop-in configuration files only for the web server, not any other
component (typical Python or CGI webapp deployment with ngix would
require both nginx and uWSGI configuration files placed in right places)
– no sane way for privilege separation – there is no good way to do that
for Apache, so no a good generic way to enable this in webapp packages.

I don't have time and desire to hack webapps to use nginx our current
way or to invent something better (that would probably require a lot of
work). But feel free to try it yourself :)

Greets,
	Jacek


More information about the pld-devel-en mailing list