On 25 October 2012 07:08, rahul286 <nginx-forum@nginx.us> wrote:
> Please give your suggestions/opinion/alternative approach...
>
> Goal is to allow wordpress like web-apps to update a site-specific nginx
> config file AND have nginx auto-reloaded new config.

In a multi-tenant system, which is what you appear to be aiming for,
this is a bad idea. A very bad idea.

Here are a few ways, as a customer, I could fuck you up:

In my /var/www/path/to/site/.nginxaccess:

START -------------------------------------------------------------------------

} # close the "location /{" we assume we're included from within
} # close the "server{" we must be included from within

server { # get access to some files we shouldn't be allowed to see
listen 80;
server_name invalid.name1;
root /etc/;
}

server { # destroy someone else's site
listen 80;
server_name invalid.name2;
root /var/www/path/to/someone/elses/site;

location / {
dav_methods PUT DELETE MKCOL COPY MOVE;
client_body_temp_path /var/www/path/to/someone/elses/site;
create_full_put_path on;
dav_access group:rwx all:rwx;
}
}

server { # DoS someone else's site
listen 80;
server_name another.customer.on.this.server;
rewrite ^ http://google.com;
}

server { # re-enter our normal "server{" block, so nginx reloads OK
listen 80;
server_name invalid.name3;
location {

END -------------------------------------------------------------------------

Don't do this. It's a bad idea.
The quality of badly-written nginx howtos, blogs, etc out there on the
web is poor enough without this flawed pattern gaining any traction or
exposure.

Cheers,
Jonathan
--
Jonathan Matthews // Oxford, London, UK
http://www.jpluscplusm.com/contact.html

_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx