I’ve been installing passenger on my development PC so that I can debug an issue that is only apparent in production (it’s due to the app being hosted in a sub-uri). I don’t tend to use passenger much myself, as in most of the environments I’ve worked in there has either already been a server set up, or there is a sys-admin who needs to manage the server set up. However, doing this myself has been really useful and I’ve learnt a lot from doing it. (Another “why haven’t I worked out all this before” moment).
The main problem I had was that I kept having to point RackBaseURI at the public folder in my app, which left ‘/public’ in the app’s url. So instead of ‘/mysite’, I was getting ‘/mysite/public’.
As is so often the case once you know the solution, the answer was very simple. I had overlooked the significance of a single line in the passenger documentation:
That sets up a symlink to the public folder of your app. It also means that RackBaseURI is not pointing at the real folder where the code is, but to a symlink in your web root. Now I realise the significance of this line in the docs, it is obvious to me that this a better way to arrange things.
With the the symlink in place everything started working properly.
One thing that playing with this has taught me is that the passenger documentation is very good. A couple of times google searches led me to outdated methods that no longer worked with the version of passenger I was using. Each time the solution was found within the passenger docs.
The problem is that the apache guide is a very long document. However, my experience was that it was much more fruitful to search the passenger documention page for keywords, than to google for the solution.