Over the next few posts (weather permitting) I'm going to walk you through how I set up my server to run multiple Rails apps.
Now bear in mind, I'm not a sys admin and if you're reading this I guess you aren't either. I'm a designer and programmer. Everything I've learnt has been pieced together from articles like this, forums and good old fashioned trial and error. So your milage may vary, use at your own risk et cetera et cetera.
- By the end of the series we'll have a server running
- - Ubuntu for the OS (should be already installed by your hosting provider)
- - Apache for the web server
- - Passenger (aka mod_rails) for making it super easy to setup and serve our apps
- - Ruby and Ruby on Rails of course
- - MySQL for db stuff
I'll warn you now that some of this is bound to be tedious and boring but stick with me and I'll show you how ridiculously easy setting up a multiple rails apps can be.
My personal experience was with Slicehost VPS but all this should be pretty much the same no matter who your hosting is with providing that they treat you like a grown up and give you root access. Root access basically means that you have the power to install anything you want and mess with any setting you want to on your little piece of interweb.
Ok, so lets assume you have a clean slate and your admin login and password at hand. Most experts say to create a new user on your server to do all your work under and to not log in with your root user for security purposes. So lets do that first.
In your welcome email you probably got an IP address and a password. Open up Terminal (or your command line interface) on your local machine (aka your computer) and use SSH to connect to your server.
Run ssh root@123.45.67.890 where the string of numbers is the IP address you were given. Make sure to include all the dots in all the right places. Enter your password when prompted and you should now be connected to your server and everything you type in this window will be a command issued to your server. We should probably change root's password to something secure but memorable by typing passwd and following the prompts.
Now we'll add a user who'll we'll actually use to do all the work. I've chosen "deploy" but you can use anything you like. Just be sure to replace "deploy" with your username in future steps.
adduser deploy
Our user deploy is new 'round here and nobody is going to listen to him or do anything he says. Lets fix that by giving him "Super User" privileges. Being a Super User will enable deploy to do whatever he damn well pleases (as long as he asks nicely and has the password). visudo will open a file that will tell the server who to listen to so go all the way to the bottom of the file and on its own line type deploy ALL=(ALL) ALL then Ctrl-X to exit making sure to save your changes. Then logout to close the connection.
Now one more little security trick. As great as your cat's name is a secure password if someone did somehow guess that was your password they could SSH into your server and do all sorts of nasty in there. That's where SSH keys come in. Basically we create a pair of keys (big long strings of characters) and put one (called the public key) on the server and the other (called the private key) you keep on your machine. When you try to login with your password, the server will look for the private key that matches it's public key before letting you in. So even if Dr Evil guesses your password, he still can't get into your server without they key on your machine. Lets set that up real quick.
You need to keep your private key in a specific folder which we'll make now. You should be logged out of your server and back on your local machine, right? Right. Good because we need to do this locally. Run mkdir ~/.ssh.
mkdir is a command to make a directory (or a folder - same thing) and the ~/ is a shortcut to your home directory.
Now run ssh-keygen -t rsa - this will generate some SSH keys for us. To make them more unique (and therefore more secure) it'll prompt you for a passphrase. Once this is done you should see that it left you two files: id_rsa and id_rsa.pub. To check this type cd ~/.ssh && ls which will go to that .ssh folder and list all the files there. The id_rsa.pub is your public key. The one without .pub is your private key. For the love of all that is Holy do not let Dr Evil get ahold of your private key!!
Lets get that public key up onto our server...
scp ~/.ssh/id_rsa.pub deploy@123.45.67.890:/home/deploy/
(You'll need your deploy user's password for this.) ...log back into your server with
ssh deploy@123.45.67.890
and create a good home for the precious public key with
mkdir /home/deploy/.ssh
...and then move the public key to it's new home
mv /home/deploy/id_rsa.pub /home/deploy/.ssh/authorized_keys
We should probably set the correct permissions for the key while we're here (just as it sounds - permissions govern who has what kind of access to a given file or folder - only it has a tendency for being really confusing as you may discover one day yourself)
chown -R deploy:deploy /home/deploy/.ssh
chmod 700 /home/deploy/.ssh
chmod 600 /home/deploy/.ssh/authorized_keys
This wouldn't be nearly as much fun if there wasn't some settings to mess with. We can mess with some SSH settings by sudo nano /etc/ssh/sshd_config. You might want to follow what someone who knows what they're doing says to do but two things people say to watch out for is which port (for server ports, think doors) the server should listen for connections/users on. Port 22 is a default port so hackers often try getting in via that port so you may want to change it to some fairly high, fairly random number (eg Port 28400) to make it harder for them to find the right door to knock on - just remember what port you set! The other thing to look out for is AllowUsers deploy. Make sure your deploy user is listed otherwise you won't get in!
Ok, so lets test that this all works. /etc/init.d/ssh reload will reload SSH with your new settings. Open a new terminal window and try to open a second connection to your server with ssh -p 28400 deploy@123.45.67.890 where -p 28400 specifies the port we told the server to accept connections on. If this works, then we can move on. If not, use your original connection to re-edit your sshd_config and see where you went wrong.
Everything running fine? Good. That's the groundwork done. Have a breather, you deserve it!
