Back To The Main Support Page

Setting Up Your Application

Slingshot Hosting and Highgroove Studios regularly contribute to many sources of documentation for Rails and Deployment specific instructions. We're active posters and editors on the "official" rubyonrails.org wiki for documentation related to the servers we've setup. Here, you'll find some quick setup instructions specific to the Slingshot Servers we setup.

Subversion
lighttpd
Apache2.1+
MySQL
SSL

Subversion

All Slingshot Hosting servers come with Subversion installed and setup for version control.

Most Subversion repositories use the convention of having a trunk, tags, and branches directory for storing your code. Trunk is where the action is, and tags and branches are where you may choose to copy your code to facilitate releases. For more information, see Version Control with Subversion: Chapter 4: Branching and Merging.

Let's setup an initial repository on your local development machine to facilitate your initial check in.

Make some temporary directories in some place temporary:

$ mkdir /tmp/my_svn_project
$ mkdir /tmp/my_svn_project/trunk
$ mkdir /tmp/my_svn_project/branches
$ mkdir /tmp/my_svn_project/tags

Leave that there, and let's setup SVN on the server.

SSH+SVN

SSH+SVN is a quick protocol for accessing SVN repositories.

your_computer $ ssh username@daytona.slingshothosting.com

Create a directory to store your SVN repository:

daytona $ mkdir /var/svn/repos

Now, use the svnadmin command to create a new repository.

daytona $ svnadmin create /var/svn/repos/your_project_name

Now, let's jump back to your development computer and import the initial directory structure into your new svn repository.

your_computer $ cd /tmp/my_svn_project
your_computer $ svn import . svn+ssh://username@daytona.slingshothosting.com/var/svn/repos/your_project_name -m "Initial import and directory structure"

You now have a working repository. Make an initial checkout of your code.

your_computer $ cd /path/to/my_application
your_computer $ svn co svn:///username@daytona.slingshothosting.com:/var/svn/repos/your_project_name/trunk .

Note the . at the end, we're checking out your trunk into the "current" directory.

You're now able to svn commit and svn update to your heart's content!

SVN over Web DAV

Web DAV is a protocol that allows read/write access over HTTP or HTTPS. This is great for those firewalled servers that only allow HTTP and HTTPS (ports 80 and 443) access, and, in our opinion, a little easier to setup and manage.

Instead of storing the svn repository in /var/svn/repos, we'll put it web accessible (but password protected!).

Create a directory to store your SVN repository:

daytona $ mkdir /var/www/svn

Now, use the svnadmin command to create a new repository and set permissions:

daytona $ svnadmin create /var/www/svn/your_project_name
daytona $ chown -R apache.apache /var/www/svn/your_project_name

Now, make sure your /etc/httpd/conf.d/subversion.conf looks like this:

<Location /repos>
   DAV svn
   SVNParentPath /var/www/svn

   AuthType Basic
   AuthName "Authorization Realm"
   AuthUserFile /var/svn/conf/htpasswd
   Require valid-user
</Location>

Create a password file:

daytona $ mkdir /var/svn/conf
daytona $ htpasswd -c /var/svn/conf/htpasswd bobbyjones

Once the file is created (using -c) you can add users using:

daytona $ htpasswd /var/svn/conf/htpaswsd jimmyjones
daytona $ htpasswd /var/svn/conf/htpaswsd juliejones

Reload and/or Restart Apache 2.0.x by using:

daytona $ /etc/init.d/httpd restart

Your Apache 2.0.x server is by default setup with Web DAV access through port 8080, but you can easily setup a lighttpd proxy to forward requests. See the lighttpd documentation for more info on using mod_proxy. If you don't know what this means, don't worry.

Now, we should be able to checkout the repository using:

your_computer $ svn co http://daytona.slingshothosting.com:8080/repos/your_project/name/trunk .

You'll be prompted for your username and password. To change your username from the default user, just press enter when prompted.

If you're having problems, make sure the repos are writable by the apache user:

daytona $ sudo chown -R apache:apache /var/svn/repos/my_repo

lighttpd

lighttpd is a fast, light httpd implementation. It has a "small memory footprint compared to other web-servers, effective management of the cpu-load, and advanced feature set (FastCGI, CGI, Auth, Output-Compression, URL-Rewriting and many more)." -- lighttpd Home Page

Slingshot Hosting Servers come preconfigured with lighttpd. Starting and stopping of lighttpd servers is done through the /etc/init.d/ scripts. You can also use our preconfigured capistrano task to restart the web server.

Let's check out the default lighttpd.conf. SSH into your server and edit /etc/lighttpd.conf:

your_computer $ ssh username@daytona.slingshothosting.com

your_computer $ nano /etc/lighttpd.conf

your_computer $ vi /etc/lighttpd.conf

If you make any changes the configuration, you can simply restart the webserver like so:

daytona $ sudo /etc/init.d/lighttpd restart

Apache 2.1+ with mod_proxy_balancer

Our newest images include a capistrano script that completely automates the setup of Apache conf files.

To see it in action, simply run cap setup and view the files that it creates in your server's /etc/rails directory.

For more information, see Apache Best Practice Deployment.

MySQL

Slingshot Hosting Servers come preconfigured with a secure MySQL 5.x installation. Our servers are ready to go with ruby-mysql bindings and the correct password style (for the newer 5.x passwords).

All you need to do is setup a your database:

daytona $ mysql -u username -p

mysql> CREATE DATABASE your_project_development;
mysql> CREATE DATABASE your_project_test;
mysql> CREATE DATABASE your_project_production;

You can also grant access to a user, let's go through a few examples. We recommend the last example, for a secure app.

mysql> GRANT ALL PRIVILEGES ON *.* TO 'bob'@'localhost';

This is pretty lenient, bob has access to everything with no password, let's set at least a password:

mysql>  GRANT ALL PRIVILEGES ON *.* TO 'bob'@'localhost' IDENTIFIED BY 'password';

Actually, let's make it even more secure, instead, let's give easy, no-password access to a user for development and test, and then let's secure production. This is the most ideal for deployment:

mysql>  GRANT ALL PRIVILEGES ON your_project_development.* TO 'bob'@'localhost';
mysql>  GRANT ALL PRIVILEGES ON your_project_test.* TO 'bob'@'localhost';
mysql>  GRANT ALL PRIVILEGES ON your_project_production.* TO 'bob'@'localhost' IDENTIFIED BY 'password';

Be sure to adjust your deploy/database.yml file accordingly (not your config/database.yml -- that's for your local development box)!

If you would like to be able to connect remotely to your MySQL database and understand that it could possibly be a security risk if you're not careful, you must enable a firewall rule for the MySQL server:

Edit the file: /etc/sysconfig/iptables and add these two lines:

-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 3306 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m udp -p udp --dport 3306 -j ACCEPT

and then restart the firewall:

/etc/init.d/iptables restart

You can then view the firewall rules and status:

/etc/init.d/iptables status

to see that the rule is there.

Be sure to add a user who can access remotely:

GRANT ALL PRIVILEGES ON your_project_production.* TO 'bob'@'%'
IDENTIFIED BY 'password';

Note the % instead of 'localhost' which should allow all IP addresses to connect. If you can specify a single IP address, or subnet like 64.15.35.%, it would be more secure.

Incoming Mail Processing

Forwarding mail to Rails ActionMailer with qmail

There are lots of ways to do it, but here’s an easy one.

First, ensure that normal mail delivery occurs.

Now, let’s create the user/email to be our action mailer address, for example the email ruby-mail@highgroove.com will pipe to our ruby runner:

daytona $ useradd -m -G users -s /bin/false ruby-mail

This adds a user with no abilities to login, just sets up a “home” directory for them.

You can view it at /home/ruby-mail

Next, let’s change the default deliver to a .maildir directory to pipe to our program. With qmail, we simply edit the .qmail file in the ruby-mail directory:

daytona $ vi /home/ruby-mail/.qmail

and put in one line:

| /usr/bin/ruby /path/to/app/script/runner

To test this you can use the following one-liner instead:

| /bin/cat > /tmp/test.txt

Which simply drops any email sent to ruby-mail@highgroove.com to a test.txt file in the tmp directory. So, as long as you’ve got the pipe correctly done and your ruby script is taking in the input from STDIN, you should be fine.

Since we do have procmail, another way is to change the .qmail to read:

| /usr/bin/procmail

And then we could add a .procmailrc file to /home/ruby-mail to do all kinds of procmail rules to deliver (like the Agile Web with Rails book has as an example—subject line matching etc.)

Alternatively we could even make the .procmailrc part of the code for the web app if it got kind of hairy and then setup a symlink to it:

| /usr/bin/procmail /path/to/app/config/procmail_rules

Forwarding mail to Rails ActionMailer with Postfix

The easiest way to forward mail from postifix is to setup a new alias.

First, create an alias on the machine, for example: "rails-mail" and add it like to your aliases file located in /etc/aliases

rails-mail: "|/path/to/app/script/runner 'Mailman.receive(STDIN.read)'"

Any time you update the aliases file, you must run the command: newalises.

newaliases

If you are using virtual hosts in Postfix, you need to inform Postfix that incoming emails of a given address should be forwarded to this alias by adding a line below to /etc/postfix/virtual:

/^.*@.*example.com$/          rails-mail

Changes to this file require a postfix restart (and possible a recompile of the configuration file). While in /etc/postfix run this to recompile the settings manually:

make && make install

Your ActionMailer should work now. To test, you can simply setup a handler that outputs to a file. In your aliases file, put the line:

rails-mail: "|cat /tmp/incoming_mail.txt"

All your incoming mail will now be put into a file /tmp/incoming_mail.txt for testing purposes

We recommend against configuring Postfix to handle all mail for a domain, because of the sheer volume of spam and spam bounches (not even your own) that will clog up your mailer over time, but if you would like to do this, see the Official Rails Wiki page on HowToReceiveEmailsWithActionMailer, as we contribute to this guide from time to time.

SSL

If you're going to use an SSL certificate to encrypt communication with your rails app, we've got you covered.

The only things you'll need to do are to place your server's certificate file, key file, and certificate authority files in the appropriate places, and enable SSL in your capistrano setup file.

For more information, contact us.