CODEWITHSUNDEEP
nginxelasticsearchreverse-proxyelasticsearch-plugin
Shark
Shark

Reputation: 2382

Elasticsearch head plugin not working through nginx reverse proxy

I have elasticsearch with the head plugin installed running on a different server. I also set up an nginx reverse proxy for my ES instance. The configuration looks like below:

http {
    include       mime.types;
    default_type  application/octet-stream;
    sendfile        on;
    keepalive_timeout  65;

    server {
      listen       80;
      server_name  es.mydomain.net;
      location / {
          proxy_set_header    Host $http_host;
          proxy_set_header    X-Real-IP   $remote_addr;
          proxy_set_header    X-Forwarded-For $proxy_add_x_forwarded_for;

          proxy_redirect off;
          proxy_pass  http://127.0.0.1:9200;
      }
    }
}

Hitting the link http://es.mydomain.net/ works fine and I get a status 200 response. However, if I try to hit the link http://es.mydomain.net/_plugin/head/, I seemingly get a blank page. Note, the page loads fine if I access the head plug-in directly without the reverse proxy, via http://SERVERIP:PORT/_plugin/head/.

EDIT:

After doing some more debugging, I saw a net::ERR_CONTENT_LENGTH_MISMATCH error in the console for the page. After looking at nginx's log, to see what the error was, I came upon the true culprit, which is this error:

2015/05/27 16:26:48 [crit] 29765#0: *655 open() "/home/web/nginx/proxy_temp/6/0
0/0000000006" failed (13: Permission denied) while reading upstream, client: 10.
183.6.63, server: es.mydomain.com, request: "GET /_plugin/head/dist/app.js HTT
P/1.1", upstream: "http://127.0.0.1:9200/_plugin/head/dist/app.js", host: "es.my
domain.com", referrer: "http://es.mydomain.com/_plugin/head/"

I googled this one particularly, and it seems this can happen because the worker process is nobody, and the folder it is trying to read/write to may not have the right permissions. Still looking into this, but will update with an answer when found

EDIT 2: Removed unnecessary information to make issue more direct.

Upvotes: 0

Views: 2309

Answers (2)

Hugues Lepesant
Hugues Lepesant

Reputation: 11

You have to install the plugin head on all ES nodes.

Upvotes: 0

Shark
Shark

Reputation: 2382

I was able to work out two solutions to get around the permission, so I'll present them both.

One thing to know about my nginx set-up is that I did not use sudo to install it. I unarchived the tar file, configured, and make installed it, so it was residing in /home/USERNAME/nginx/.

The issue was that starting nginx was creating a worker process under "nobody", which was then trying to read/write in /home/USERNAME/nginx/proxy_temp/, which it did not have permission to do. Solutions on the web said to just chown nobody to the temp folders, but this solution wasn't really appropriate in my particular case since we were inside USERNAME's home.

Solution 1:

Add user USERNAME; to top of nginx.conf, so that it would run the worker process as the specified username. This no longer led to a permission issue, as USERNAME had the permissions to read/write in the desired temp folders.

Solution 2:

Add proxy_temp_path to the server config. With this, you could specify a folder for the nobody process to create where it would have read/write permission. Note, you might still run into permission issues if the other *_temp folders are used by your nginx server.

server {
  listen       80;
  server_name  es.mydomain.net;
  location / {
      proxy_set_header    Host $http_host;
      proxy_set_header    X-Real-IP   $remote_addr;
      proxy_set_header    X-Forwarded-For $proxy_add_x_forwarded_for;

      proxy_redirect off;
      proxy_pass  http://127.0.0.1:9200;
      proxy_temp_path /foo/bar/proxy_temp

  }
}

I personally preferred solution 1, as it would apply to all the server blocks, and I would not have to worry about the other *_temp folders once the conf file got more complex.

Upvotes: 1

Related Questions