Sinatra on Nginx Configuration - What's Wrong

Sinatra on Nginx configuration - what's wrong?

Make sure that the user nginx is running as (in most cases 'nobody' or 'www-data') has permission to read the contents of your home directory /home/admin.

Also you can look into the nginx logs and read exactly what the error was.

How do I configure nginx correctly to work with my Sinatra app running on thin?

You have to tell nginx to proxy requests to your Sinatra application. The minimum required to accomplish that is to specify a proxy_pass directive in the location block like this:

location / {
  proxy_pass http://localhost:4567;
}
        

The Nginx Reverse Proxy docs have more information on other proxy settings you might want to include.

Passenger/nginx not loading Sinatra app

The passenger_base_uri together with the root in your configuration example do not match with the directory structure (e.g /web/archive/sites/app1 vs /web/archive/sites/archive/app1). As far as I understand Passenger does not consider the location but only root and passenger_base_uri.

Try changing the configuration into

server {
    listen 80;
    server_name domain.com;

    location /archive {
        root /web/archive/sites/archive;
        passenger_enabled on;
        passenger_base_uri /app1;
        passenger_base_uri /app2
    }
}

Passenger + Nginx + Sinatra: friendly error page does not appear

Asked here https://github.com/sinatra/sinatra/issues/963 and got the answer.
It works now!

The fix is already in master branch. Until a new release is made, you can point the gem to master:

# Gemfile
gem 'sinatra', github: 'sinatra/sinatra'

Why am I getting 404 errors with Sinatra with Passenger under nginx?

In the original question I wrote:

I moved it to a nginx-based server with Passenger and now all my links to files in my apps /public are returning 404 errors. The primary app runs, is able to access the HAML templates in /view, which render correctly. The files exist and permissions are correct; I can open and edit them so I know they're there.

That was my clue. On my fourth pass or so through the Passenger docs I ran into a section that talked about errors with /public assets:

The second and highly recommended way is to always use Rails helper methods to
output tags for static assets. These helper methods automatically take care of
prepending the base URI that you’ve deployed the application to. For images
there is image_tag, for JavaScript there is javascript_include_tag and for CSS
there is stylesheet_link_tag. In the above example you would simply remove the
HTML tag and replace it with inline Ruby like this:

So, that got me searching for similar helpers for Sinatra. I found in Sinatra's extensions page:

sinatra-url-for construct absolute paths and full URLs to actions in a Sinatra application

sinatra-static-assets implements image_tag, stylesheet_link_tag, javascript_script_tag and link_tag helpers. These helpers construct correct absolute paths for applications dispatched to sub URI.

And that got me searching Sinatra's docs because it sparked a memory, and I relearned Sinatra's built-in "url" method:

Generating URLs

For generating URLs you should use the url helper method, for instance, in
Haml:

%a{:href => url('/foo')} foo

It takes reverse proxies and Rack routers into account, if present.

This method is also aliased to to (see below for an example).

By using the static asset methods, or Sinatra's own url helper it fixed the problem.

Nginx doesn't work with Sinatra JSON route

Solved this by adding the following to my /etc/nginx/sites-available/default config file (inside the server block):

...

location / {
    try_files $uri @app;
}

location @app {
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header Host $http_host;
    proxy_redirect off;
}

...

And I deleted:

location / {
    # First attempt to serve request as file, then
    # as directory, then fall back to displaying a 404.
    try_files $uri $uri/ =404;
}

This was an Nginx config issue related to the deleted code above.

Nginx denied permission while connecting upstream to Unicorn

While I did not figure out the actual problem, switching from Centos 7.5 to 6.9 fixed the issue.

NGINX configuartion to proxy SSL requests to a Sinatra server

There's something wrong with the DNS configuration for your domain, hard to tell you what's wrong without knowing more about your setup, but at least make sure that you have the name servers for your domain properly set up and an A-record pointing to your AWS-instance.

An important thing to note when configuring HTTPS with Nginx is that your certificate file should include any intermediate certificates that you might have. See the link to the Nginx documentation below for more information.

Setting up SSL with Nginx can be as simple as adding these 3 lines to your configuration:

listen 0.0.0.0:443 ssl;
ssl_certificate /path/to/your/certificate
ssl_certificate /path/to/your/certificate_key

If you want to enforce HTTPS you can disable HTTP (port 80) on your existing server block and create an additional one like this:

server {
    listen 0.0.0.0:80;
    server_name automation.mydomain.com my_site;
    return 301 https://$server_name$request_uri;
}

This will redirect any HTTP-request to your HTTPS-enabled server. Note that I would advice changing 301 to 302 while testing so that your browser doesn't cache the response.

See these resources for more information

• nginx ssl module documentation
• Strong SSL Security on nginx by Raymii

---

Related Topics