Here’s a diagram detailing the software architecture and components used for my proposed static site generation solution.
Posterous has decided to shutdown so migrating my blogs here!
Recently banged my head against this issue for ages until someone with nginx knowledge pointed out it wasn’t nginx but a sinatra/unicorn issue.
Basically the symtoms were after setting up my Sinatra application, with Unicorn as the webserver and Nginx as the SSL proxy (redirecting http to https for the domain) anytime the application received a post request on my login screen it responded with “forbidden” (403). Get requests for the login screen worked fine.
Initially I thought the error came from Nginx, but it turned out it came from Rack (running via Unicorn). The issue was as part of the login post sinatra-authentication was redirecting to http, not https. Nginx then redirected the client to https but lost the auth details, so Rack gave the forbidden response (with no helpful debug).
To fix this all I had to do was add the following to the nginx conf at the proxy settings:
That told Rack it was working via an ssl proxy and changed the redirects to use https. No clue why I needed to do this, but in future I’ll use something like rack-ssl-enforcer and handle the redirects in the application itself rather than nginx conf.
If you’ve been trying to start a Unicorn app and seeing something like the following error:
“‘raise_if_conflicts’: can’t activate rack-1.4.1, already activated rack-1.5”
It’s down the versions of rack gem which you installed. In your applications gemfile you should specify the version of rack you want to use, e.g.
gem “rack”, “1.4.1”
Run “bundle update rack” and see if that fixes the issue.
If not, run “gem uninstall rack”, you may see that you have two versions of rack installed, uninstall the wrong one and try again.
This has caught me out twice now, so typing it up to remember. By default Unicorn outputs stderr/stdout to terminal, which is great if you have one running, but if you don’t (i.e. you logged off) you get a massive error screen were your app was “Errno::EIO Input/output error” in “lint.rb” or something similar.
To fix this just add the following lines to your unicorn.conf file you create for your application, which redirect the output to log files instead:
# By default, the Unicorn logger will write to stderr.# Additionally, some applications/frameworks log to stderr or stdout,# So prevent them from going to /dev/null when daemonized here:stderr_path "/srv/www/logs/unicorn.stderr.log"stdout_path "/srv/www/logs/unicorn.stdout.log"