run script from nginx

raziel.lupercio · 2016-10-07T11:06:45+00:00

Hello, I am trying to access data from lua_shared_dict in stream module which is set by http module. It complains about : nginx: [emerg] the...

run script from nginx

raziel.lupercio

Is it possible to call a bash script from openresty? Also I would like to pass some variables from url parameters.

What I aiming is to run a script everyting a determinate URL is called from a external api and this script will add another location to nginx and will restart the server in order to apply the changes...

So I have the script ready and I have openresty installed on the box but whenever I try to do something like

content_by_lua "os.execute("/absolute/path/to/my/script.sh")";

I get the following error on my log:

2016/10/06 22:05:48 [error] 15913#0: *75 FastCGI sent in stderr: "Primary script unknown" while reading response header from upstream, client: 187.232.250.174, server: mybox, request: "GET /lua_content/ HTTP/1.1", upstream: "fastcgi://unix:/var/run/php-mail-fpm.sock:", host: "mybox"

my nginx location:

     location /nginx_var {
         # MIME type determined by default_type:
         default_type 'text/plain';

         # try access /nginx_var?a=hello,world
         content_by_lua_block {
             os.execute("/absolute/path/to/my/script.sh")
         }
     }

inspiration from here: https://gist.github.com/aterreno/6208791

any help is greatly appreciated

rpaprocki

Hi,

Sent from my iPhone

On Oct 6, 2016, at 20:06, raz lupercio <raziel....@gmail.com> wrote:

Is it possible to call a bash script from openresty?

Yes it's possible, though I'd question the wisdom of doing so ;) os.execute() will block your worker process, so for the bold and brash, have a look at https://github.com/juce/lua-resty-shell. This requires a separate daemon, but requests will not block the rest of the worker.

Also I would like to pass some variables from url parameters.

This can be -very- dangerous unless you're in a highly trusted environment. Unless you sanitize the ever loving snot out of your input you're going to run into serious trouble here. At this point I'd start to rethink your approach with what you want to accomplish.

What I aiming is to run a script everyting a determinate URL is called from a external api and this script will add another location to nginx and will restart the server in order to apply the changes...

There are a few problems here. First, restarting or reloading Nginx in the middle of the request is likely to be fraught with peril (I smell broken http transactions and stuck worker processes). Next, this implies that either the nginx process is running as a privileged user, or that your shell script is sudo-ing up, both of which are wholly unappetizing options (unless you're running nginx only on a nonprivileged listening port). it would make far more sense to use a dedicated config management system like chef/puppet/ansible/salt/pick-your-config-mgmt-system-du-jour. trying to using openresty to manage itself and its own config sounds dangerous. It's a flexible application server to be sure, but there are certainly more sane ways to accomplish this.

So I have the script ready and I have openresty installed on the box but whenever I try to do something like

content_by_lua "os.execute("/absolute/path/to/my/script.sh")";

I get the following error on my log:

2016/10/06 22:05:48 [error] 15913#0: *75 FastCGI sent in stderr: "Primary script unknown" while reading response header from upstream, client: 187.232.250.174, server: mybox, request: "GET /lua_content/ HTTP/1.1", upstream: "fastcgi://unix:/var/run/php-mail-fpm.sock:", host: "mybox"

my nginx location:

     location /nginx_var {
         # MIME type determined by default_type:
         default_type 'text/plain';

         # try access /nginx_var?a=hello,world
         content_by_lua_block {
             os.execute("/absolute/path/to/my/script.sh")
         }
     }

do you have an existing location block that is calling fcgi_pass? That's what this error indicates. You haven't pasted your whole config so there's no way to know, but certainly there's more to your sever config than meets the eye.