To add to my original comment above, and to reiterate what a couple of other posters have suggested, I would love a follow-up tutorial to this showing how to deploy a new (separate) Rails app on the same server.
The reason I ask is that, given that I am a lone developer (and, probably like most folks here, my apps are generally quite small), my app only takes up around 5-10% of the allocated Linode so, when it comes round to deploying a second app (which will probably be just as tiny), it would appear to be more sensible to deploy it within the spare space rather than purchase an extra Linode.
There appear to be a few solutions above, but they are a bit daunting for a noob (particularly when one's current app just "works" and you're wary of breaking anything!), so a short screencast would be just dandy.
On a related note - Linode offer a backup service for around $5 a month (for the basic server option), so I'd recommend getting this if you're a noob like me. I think nightly backups are taken.
This is an absolutely ASTOUNDING tutorial/runthrough - one of the best I've ever come across on anything Rails-related. I will admit it took me around 2 days involving a couple of attempts and a bit of debugging to get everything working, but I got there in the end.
From memory, the main issues I had to deal with were as follows:
1) As Steve Fox mentions above, you will probably need to edit the /etc/nginx/sites-enabled/default file as per Steve's instructions in order to get nginx to work properly.
2) For some reason, when I tried to install PostgreSQL, version 8 was installed on my server, whereas version 9 appears to be installed in the video for Ryan's installation. I had to make sure I added this to the relevant command in the terminal. From memory (so you might want to check), it was:
ruby
apt-get install postgresql-9.2 libpq-dev
(Or whatever the current version is at the point you are reading this :-) ). See also this link.
3) An obvious one, but make sure that you install the same versions of Rails, PostgreSQL etc. on your server that you have on your local machine!
4) If your gems fail to install properly on the server, you may need to install the relevant development files:
HOWEVER, the most important piece of advice I can give based upon my experiences is as follows:
If you're intending to deploy your first ever app, do not build your complete app locally and then attempt to deploy it. There are probably minor differences in the different installations which are likely to cause your 500 page to appear, and which may end up being a nightmare to debug.
Instead, my advice would be to set up your server as soon as you write the first line of code for your app (even if it's just a "Hello World!") - and then deploy and debug as you go along. Believe me, this saves the frustration (particularly if you're a novice and not quite sure of what you're doing) of having a complete, working app on your local machine and one that refuses to work on a server. If you carry out a staged deployment, any issues should be identifiable and therefore rectifiable fairly quickly, rather than trying to debug a complete app at the end of the process. If you're worried about having an unfinished app publically available, I suppose you could set a username/password using the nginx equivalent of Apache's htpassword (do a Google search) to the root directory so that visitors to your site won't be able to access it.
To add to my original comment above, and to reiterate what a couple of other posters have suggested, I would love a follow-up tutorial to this showing how to deploy a new (separate) Rails app on the same server.
The reason I ask is that, given that I am a lone developer (and, probably like most folks here, my apps are generally quite small), my app only takes up around 5-10% of the allocated Linode so, when it comes round to deploying a second app (which will probably be just as tiny), it would appear to be more sensible to deploy it within the spare space rather than purchase an extra Linode.
There appear to be a few solutions above, but they are a bit daunting for a noob (particularly when one's current app just "works" and you're wary of breaking anything!), so a short screencast would be just dandy.
On a related note - Linode offer a backup service for around $5 a month (for the basic server option), so I'd recommend getting this if you're a noob like me. I think nightly backups are taken.
This is an absolutely ASTOUNDING tutorial/runthrough - one of the best I've ever come across on anything Rails-related. I will admit it took me around 2 days involving a couple of attempts and a bit of debugging to get everything working, but I got there in the end.
From memory, the main issues I had to deal with were as follows:
1) As Steve Fox mentions above, you will probably need to edit the /etc/nginx/sites-enabled/default file as per Steve's instructions in order to get nginx to work properly.
2) For some reason, when I tried to install PostgreSQL, version 8 was installed on my server, whereas version 9 appears to be installed in the video for Ryan's installation. I had to make sure I added this to the relevant command in the terminal. From memory (so you might want to check), it was:
apt-get install postgresql-9.2 libpq-dev
(Or whatever the current version is at the point you are reading this :-) ). See also this link.
3) An obvious one, but make sure that you install the same versions of Rails, PostgreSQL etc. on your server that you have on your local machine!
4) If your gems fail to install properly on the server, you may need to install the relevant development files:
See this StackOverflow question/response, and particularly the response with the most upvotes for further info.
HOWEVER, the most important piece of advice I can give based upon my experiences is as follows:
If you're intending to deploy your first ever app, do not build your complete app locally and then attempt to deploy it. There are probably minor differences in the different installations which are likely to cause your 500 page to appear, and which may end up being a nightmare to debug.
Instead, my advice would be to set up your server as soon as you write the first line of code for your app (even if it's just a "Hello World!") - and then deploy and debug as you go along. Believe me, this saves the frustration (particularly if you're a novice and not quite sure of what you're doing) of having a complete, working app on your local machine and one that refuses to work on a server. If you carry out a staged deployment, any issues should be identifiable and therefore rectifiable fairly quickly, rather than trying to debug a complete app at the end of the process. If you're worried about having an unfinished app publically available, I suppose you could set a username/password using the nginx equivalent of Apache's htpassword (do a Google search) to the root directory so that visitors to your site won't be able to access it.
Hope this helps others - and thanks again, Ryan!
Fantastic, as always!
I note, however, that the user is always redirect to the root_url, which isn't always ideal.
Which is the best method for redirecting a user to the "original" page after they have (possibly unsuccessfully) logged in?
This should also cover static pages - for example, if the user is on an "About" page, then logs in, they should be returned to the "About" page.
Thanks!