Slicehost Articles - Home

Secure FTP transfers

2008-05-28T12:45:00Z

Getting images, files and folders onto and off a Slice can cause difficulties with concerns about security.

This article takes a look at SFTP - part of the SSH package - as a way of securely transferring files to your Slice.

Installation

SFTP (SSH File Transfer Protocol) is part of the SSH package.

In other words, there is nothing to install as it is ready to use.

Configuration

There is also nothing to configure.

Once you have setup your user(s) and configured SSH for your needs, SFTP uses the same usernames and ports.

Please see the Slice setup articles for more details of the initial Slice configuration - Ubuntu Hardy - Slice setup #1

Security

As mentioned, SFTP uses the SSH protocol to connect to your Slice.

As such, the connection and all data is encrypted to prevent any eavesdropping of passwords or sensitive data.

SFTP Client

We can start by looking at an SFTP client.

The 'client' is a programme on your local workstation. I won't go into listing all the available SFTP clients but suffice to say that the vast majority of modern FTP clients also support SFTP (keep in mind SFTP does not use the 'typical' FTP protocols and so some older FTP clients may not support SFTP).

You can search for SFTP clients for Windows, OS X, Linux or other Operating Systems.

Due to the vast array of clients available I can't go into how to use each one (they should have plenty of documentation with the software).

However, the preferences/options panel will allow you to enter the SFTP details.

Take a look at this example:

If you have followed the setup articles (see the link above) you will notice the details are the same as those we used to setup SSH.

We have the Slice IP, the user named 'demo', we are using port 30000 (the same port we set in the sshd_config file).

The protocol has been specified as SFTP - this particular client has several options available.

Lastly, you should be able to set the path for the UI. In this case, I want to open the client in my home partition.

Once I have submitted the information, I am connected to the Slice:

Note: In this case I have accessed the Slice at the root folder level. As such, you can browse the folders as shown above.

Most clients will allow you to 'double click' on a file and edit it in a local browser.

Permissions

Which brings us nicely to permissions.

Do remember that you are using the same details as the SSH user - as such they won't be able to automatically edit files owned by root.

All that would happen is a nice 'permission denied' error if you tried to open or save any changes to a root owned file.

So what to do about the permissions?

Well, to be honest, there isn't a lot you can do about it. The permissions are there for a good reason and are an integral part of Linux and how it is designed.

Neither do I recommend logging in as root - part of the initial SSH setup entailed disabling root logins.

However, beyond the initial Slice setup, there should be little reason to mess around with files owned by root and any changes in configurations would be done from the command line using the 'sudo' command.

The main reason for using SFTP clients is to ease the transfer of files - most of which will be to your public_html folder which you will have permission to write.

Summary

Secure FTP connections are very easy when using SFTP - it is already installed as part of SSH and all you need is a client that supports the SFTP protocol.

Transferring files and folders to your home directory has never been easier or more secure.

PickledOnion

How to serve multiple domains

2008-05-28T10:55:00Z

Most people serve more than one domain on their Slice(s).

Whether for different domain names or different subdomains of the same domain, the procedure is the same.

Question

I am often asked by people how to use their Slice to serve multiple domains.

The question often surprises me as they may have setup their Slice, installed a web server (Apache, Nginx, etc) and even created a virtual host to serve their main domain.

Don't get me wrong, the question itself is good (I like questions as it makes me feel useful!), but the answer is always so simple:

Create another vhost.

Outline

There may not be a great deal I can add to the answer but let me outline the process of setting up a Slice and creating a virtual host (I won't go into any details of the installation and creation process - please see the relevant articles for detailed help).

When your Slice is first created it is a minimal Linux install (it doesn't matter what OS you choose).

You SSH into the Slice and update and secure it.

Then you install your preferred web server (Apache, Nginx, Litespeed, etc).

Then the detailed stuff begins. It doesn't matter if your site is PHP based or Rails based or something else entirely. You install the language and framework basics (say Ruby and rubygems or mod_php and so on).

Once that is all done, you come to the part that allows you to server your site: creating virtual hosts.

Procedure

Greatly simplified the procedure for serving a website is as follows:

A browser send a request to your Slice IP asking for the contents of 'domain.com' (your domain name).

Your web server jumps into action and says 'yes! I have something for you'. The web server does its 'thing' and serves up an http representation of your site which is sent to the browser.

The browser then translates the http and parses it to a human form of the web site (something like this one).

All jolly good but how does your web server know what to send?

Virtual Hosts

This is where name based virtual hosts come in.

One of the first lines in any virtual host contains the domain name that is related to the vhost.

Something like this for Apache:

<VirtualHost *:80>

  ServerName  domain1.com
  ServerAlias www.domain1.com

and something like this for Nginx:

server {

  server_name  www.domain1.com;
  rewrite ^/(.*) http://domain1.com permanent;

Each one starts slightly differently but the same principle applies - that particular virtual host will respond to queries for 'domain1.com' and 'www.domain1.com'.

Multiple domains

So, to serve different content for different domains is as simple as adding another virtual host.

Let's say you have a subdomain called 'blog.domain1.com' serving a blog (I know, shocking originality!).

The basic creation process would be to create a folder in your public_html folder with the relevant files (let's say a Wordpress install).

A virtual host would be created with the server_name or ServerName as 'blog.domain1.com' which would be configured to point to the blog files and folders in your public_html folder.

Done.

Language and frameworks

It doesn't matter what language or framework your domain uses.

To serve multiple Rails applications for example requires the same setup for each application.

Of course, there would be some differences such as port numbers for the mongrel or thin instances. Virtual hosts can't share ports.

For example, you may create a mongrel cluster to run from port 8000 - 8002 for one domain and another running from 8010 - 8012 for your blog and so on.

Summary

Once the Slice has been setup and the web server has been installed, serving multiple domains is very easy:

Simply create more vhosts...

PickledOnion

Ubuntu Hardy - Nginx, rails and thin

2008-05-27T12:47:00Z

Having installed the thin web server for Ruby, we can now look at configuring a Nginx vhost to proxy to thin so we can serve our Ruby on Rails application.

The process is easy to follow and easy to repeat for hosting multiple domains.

Setup

Firstly you will have needed to follow the previous Nginx articles and installed via aptitude or via source.

You will also need to have installed the thin web server as per the article linked to above.

Plan

The plan is very simple:

We'll create a basic rails application and use 3 thin instances running from port 3000 to 3002.

I won't go into detail as the thin web server for Ruby article shows how to install and configure thin.

Once that is done, we'll create a simple vhost to proxy requests to the thin instances.

You may also notice this article is very similar to the Nginx and mongrels article. There is a very good reason for that - they use exactly the same methods in creating the virtual host.

All the virtual host has to do is proxy requests to the 3rd party web server - in this case thin, in the sister article, mongrels.

Rails Application

To create a rail application, move into your public_html folder:

cd /home/demo/public_html

and create a new Ruby on Rails application:

rails railsapp

Done.

Thin

Ensure you are in the rails folder:

cd ~/public_html/railsapp

Then create a thin configuration file:

sudo thin config -C /etc/thin/railsapp.yml -c /home/demo/public_html/railsapp/  --servers 3 -e production

It's always a good idea to check the created file:

cat /etc/thin/railsapp.yml

The contents are as such:

pid: tmp/pids/thin.pid
log: log/thin.log
timeout: 30
max_conns: 1024
port: 3000
max_persistent_conns: 512
chdir: /home/demo/public_html/testapp
environment: production
servers: 3
address: 0.0.0.0
daemonize: true

Unlike with mongrels, we don't need to manually create symlinks, etc to make sure thin is started on a reboot.

Now all we need to do is start thin:

sudo /etc/init.d/thin start

Done.

Nginx Virtual Host

Let's create the Nginx vhost:

sudo nano /etc/nginx/sites-available/domain.com

Note: If you installed Nginx from source, the path may vary to something like:

sudo nano /usr/local/nginx/sites-available/domain.com

The contents of the file are as such:

upstream domain1 {
        server 127.0.0.1:3000;
        server 127.0.0.1:3001;
        server 127.0.0.1:3002;
    }

server {
            listen   80;
            server_name  www.domain.com;
            rewrite ^/(.*) http://domain.com permanent;
           }


server {
            listen   80;
            server_name domain.com;

            access_log /home/demo/public_html/railsapp/log/access.log;
            error_log /home/demo/public_html/railsapp/log/error.log;

            root   /home/demo/public_html/railsapp/public/;
            index  index.html;

            location / {
                          proxy_set_header  X-Real-IP  $remote_addr;
                          proxy_set_header  X-Forwarded-For $proxy_add_x_forwarded_for;
                          proxy_set_header Host $http_host;
                          proxy_redirect false;

                          if (-f $request_filename/index.html) {
                                           rewrite (.*) $1/index.html break;
                          }

                          if (-f $request_filename.html) {
                                           rewrite (.*) $1.html break;
                          }

                          if (!-f $request_filename) {
                                           proxy_pass http://domain1;
                                           break;
                          }
            }

}

Take each section at a time and you will see that the basics are the same as for a 'normal' Nginx vhost.

We have the server_name, listen, log and index variables.

Where it differs is the addition of the Rails proxy settings.

In this example, we will use 3 thin instances running on ports 3000, 3001 and 3002 which I have defined in the 'upstream' setting. I've called it domain1 for ease of use.

The location settings say that if the requested file exists to serve the static version straight away.

And if the requested file doesn't exist, pass the request to the thin server.

Enable

Remember that we need to 'enable' any available vhosts or it won't be served (an easy thing to leave out).

Referring to the Nginx articles, all we need to do is create a simple symlink:

sudo ln -s /etc/nginx/sites-available/domain.com /etc/nginx/sites-enabled/domain.com

Or, if you installed from source:

sudo ln -s /usr/local/nginx/sites-available/domain.com /usr/local/nginx/sites-enabled/domain.com

Done.

Restart

Final step is to restart Nginx:

sudo /etc/init.d/nginx stop
...
sudo /etc/init.d/nginx start

Use the 'stop' and 'start' method as issuing a restart command does not always work with Nginx.

Navigate

All that's left is to navigate to your domain:

http://www.domain.com

Where you will be greeted with the rails welcome page.

Summary

Setting up Nginx virtual hosts to proxy to the thin server easily completed.

To serve multiple domains, simply repeat the process with the new domain details.

PickledOnion.

Ubuntu Hardy - Nginx, rails and mongrels

2008-05-27T11:08:00Z

Following from the mongrel and mongrel cluster article, we can now look at configuring Nginx to proxy to a mongrel cluster so we can serve our Ruby on Rails application.

The process is very easy and can simply be repeated for serving multiple domains.

Setup

Firstly you will have needed to follow the previous Nginx articles and installed via aptitude or via source.

You will also need to have installed mongrels as per the article linked to above.

Plan

The plan is very simple:

We'll create a basic rails application and use 3 mongrels running from port 5000 to 5002.

Beyond creating the cluster itself, I won't go into detail as the mongrel and mongrel cluster article shows how to install and create mongrel clusters.

Once that is done, we'll create a simple vhost to proxy requests to the mongrel cluster.

Simple as that.

Rails Application

To create a rail application, move into your public_html folder:

cd /home/demo/public_html

and create a new Ruby on Rails application:

rails railsapp

Done.

Mongrel Cluster

Ensure you are in the rails folder:

cd ~/public_html/railsapp

Then create a mongrel cluster file as such:

mongrel_rails cluster::configure -e production -p 5000 -N 3 -c /home/demo/public_html/railsapp -a 127.0.0.1

It's always a good idea to check the created file (config/mongrel_cluster.yml):

cwd: /home/demo/public_html/railsapp
log_file: log/mongrel.log
port: "5000"
environment: production
address: 127.0.0.1
pid_file: tmp/pids/mongrel.pid
servers: 3

Now create a symlink to the /etc/mongrel_cluster folder (this ensures the cluster is restarted on a reboot):

sudo ln -s /home/demo/public_html/railsapp/config/mongrel_cluster.yml /etc/mongrel_cluster/railsapp.yml

Now all we need to do is start the cluster:

mongrel_cluster_ctl start

Done.

Nginx Virtual Host

Let's create the Nginx vhost:

sudo nano /etc/nginx/sites-available/domain.com

Note: If you installed Nginx from source, the path may vary to something like:

sudo nano /usr/local/nginx/sites-available/domain.com

The contents of the file are as such:

upstream domain1 {
        server 127.0.0.1:5000;
        server 127.0.0.1:5001;
        server 127.0.0.1:5002;
    }

server {
            listen   80;
            server_name  www.domain.com;
            rewrite ^/(.*) http://domain.com permanent;
           }


server {
            listen   80;
            server_name domain.com;

            access_log /home/demo/public_html/railsapp/log/access.log;
            error_log /home/demo/public_html/railsapp/log/error.log;

            root   /home/demo/public_html/railsapp/public/;
            index  index.html;

            location / {
                          proxy_set_header  X-Real-IP  $remote_addr;
                          proxy_set_header  X-Forwarded-For $proxy_add_x_forwarded_for;
                          proxy_set_header Host $http_host;
                          proxy_redirect false;

                          if (-f $request_filename/index.html) {
                                           rewrite (.*) $1/index.html break;
                          }

                          if (-f $request_filename.html) {
                                           rewrite (.*) $1.html break;
                          }

                          if (!-f $request_filename) {
                                           proxy_pass http://domain1;
                                           break;
                          }
            }

}

Take each section at a time and you will see that the basics are the same as for a 'normal' Nginx vhost.

We have the server_name, listen, log and index variables.

Where it differs is the addition of the Rails proxy settings.

In this example, we will use 3 mongrels running on ports 5000, 5001 and 5002 which I have defined in the 'upstream' setting. I've called it domain1 for ease of use.

The location settings say that if the requested file exists to serve the static version straightaway.

If the requested file doesn't exist, pass the request on to the mongrels. In this case it would proxy to 127.0.0.1:5000, 5001 and 5002 as those are the ports we defined at the beginning of the file.

Enable

Remember that we need to 'enable' any available vhosts or it won't be served (an easy thing to leave out).

Referring to the Nginx articles, all we need to do is create a simple symlink:

sudo ln -s /etc/nginx/sites-available/domain.com /etc/nginx/sites-enabled/domain.com

Or, if you installed from source:

sudo ln -s /usr/local/nginx/sites-available/domain.com /usr/local/nginx/sites-enabled/domain.com

Done.

Restart

Final step is to restart Nginx:

sudo /etc/init.d/nginx stop
...
sudo /etc/init.d/nginx start

Use the 'stop' and 'start' method as issuing a restart command does not always work with Nginx.

Navigate

All that's left is to navigate to your domain:

http://www.domain.com

Where you will be greeted with the rails welcome page.

Summary

Setting up Nginx virtual hosts to proxy to a mongrel cluster is fairly simple.

To serve multiple domains, simply repeat the process with the new domain details.

PickledOnion

Ubuntu Hardy - Nginx virtual host settings

2008-05-16T11:28:00Z

The previous Ubuntu Hardy Nginx Virtual Hosts article introduced the basics of the setting up virtual hosts.

This allowed us to serve multiple domains from a single IP address and Slice. Now we can look in detail at more of the settings available to us in the Virtual Hosts files.

Listen

server {
    listen   80;
}

Inside the server module, the 'listen' setting defines the port for that virtual host.

The two most common ports will be port 80 (the standard HTTP port) and port 443 (the standard HTTPS port).

Of course, you can add any port. For example, you might want to test a site on port 8080.

server_name

The usual course of a virtual host file means the next line is the 'server_name'. As such, the beginning of a vhost server module would normally look like this:

server {
    listen   80;
    server_name domain1.com;
}

You can also add a simple rewrite rule here to direct users from www.domain1.com to domain1.com:

server {
  listen   80;
  server_name  www.domain1.com;
  rewrite ^/(.*) http://domain1.com permanent;
}

alias

location  /img/ {
        alias  /home/public_html/domain.com/images/;
    }

Sets an alias location.

In this instance the address '/img/dog.png' would return the file located at:

/home/public_html/domain.com/images/dog.png

This can make for cleaner image/file url's and means you can 'share' an image directory with another site on the same Slice.

root

Following on from the 'alias' setting is a similar one where you can set the 'root' of a location:

location  /img/ {
        root /home/public_html/domain.com;
    }

This time, a request for '/img/dog.png' would return the file located at:

/home/public_html/domain.com/img/dog.png

There is a subtle, but fundamental difference between the 'alias' and 'root' settings.

error_page

error_page    404    /error/404.html;

Sets the location for a custom error page. In this example I have an 'error' folder in my public directory where I place my custom error pages.

You can redirect multiple error types to one file as such:

error_page    502 503 504    /error/50x_error.html;

internal

Following from the error_page setting, it is possible to ensure the user only receives the error page on an actual error.

In other words, at the moment, a user can enter the url:

http://domain.com/error/50x_error.html

and be served the 50x_error.html file.

Not very good, especially if the error file contains variables which may help the user in working out why they are receiving the error (such as previous page, IP address, etc).

We can set the 'internal' tag to ensure specific pages are only served from an internal trigger and not from an external url request.

Let's have look at an example which includes the above 500 error_page example:

error_page    502 503 504    /error/50x_error.html;

location    /error/50x_error.html {
    internal;
}

This will ensure that the /error/50x_error.html file is only triggered and served via an internal error.

Now if one were to navigate to:

http://domain.com/error/50x_error.html

You would receive a 404 (file not found) error instead of directly accessing the 50x_error.html file.

Much better.

You can also set this for the 404.html page but there is little point in doing that as all it would do is serve you the same 404 page!

Summary

Nginx has many Virtual Host settings and there are more available for use.

If you want to delve into the depths of Nginx you should have a look at the main Http Core Modules page on the Nginx site.

However, there should be enough here to get you going with the basics of setting up your vhosts.

PickledOnion.

Ubuntu Hardy - Nginx Virtual Hosts

2008-05-16T10:50:00Z

Now we have Nginx installed (whether via the package manager or from source) we are in a position to serve multiple domains using Virtual Hosts.

Do note the layout used in this article is explained here - feel free to use the directories of your choice.

Create the layout

Let's create the basic layout for each domain. In your home directory create a 'public_html' folder:

mkdir /home/demo/public_html

Now for each domain you want to host (I use the examples of domain1.com and domain2.com) create a folder with a standard set of sub-folders:

mkdir -p /home/demo/public_html/domain1.com/{public,private,log,backup}

and

mkdir -p /home/demo/public_html/domain2.com/{public,private,log,backup}

That will create the folders public, private, log and backup for each of our domains (domain1.com and domain2.com).

index.html

The content of the public folder is, naturally, up to you but for this example I am going to use a very simple html file so we can check the virtual hosts work.

So for each domain:

nano /home/demo/public_html/domain1.com/public/index.html

Enter something like this into the file:

<html>
  <head>
    <title>domain1.com</title>
  </head>
  <body>
    <h1>domain1.com</h1>
  </body>
</html>

Repeat the process so you have a similar file for domain2.com (don't forget to change the index.html content so it shows domain2.com and not domain1.com).

Virtual Hosts Layout

If you have been following the articles for the Nginx install, you will have a 'Debian' style layout (using sites-available and sites-enabled folders) whether you installed via the package manager or via source.

As such, we'll use that layout from now on when creating the virtual hosts.

Virtual Host

Let's go ahead and create the vhost file for domain1:

sudo nano /etc/nginx/sites-available/domain1.com

Remember to adjust the path according to your install. So installing from source would require:

sudo nano /usr/local/nginx/sites-available/domain1.com

The contents look like this:

server {

            listen   80;
            server_name  www.domain1.com;
            rewrite ^/(.*) http://domain1.com permanent;

           }


server {

            listen   80;
            server_name domain1.com;

            access_log /home/demo/public_html/domain1.com/log/access.log;
            error_log /home/demo/public_html/domain1.com/log/error.log;

            location / {

                        root   /home/demo/public_html/domain1.com/public/;
                        index  index.html;

                        }

            }

Note: This example vhost is pretty basic. However, the next article on Nginx virtual hosts will include details of many more settings that are available.

The first server module in the file is a simple rewrite rule that redirects visitors to domain1.com from www.domain1.com.

You can, of course, have this the other way around if you prefer.

The second server module has very basic information including the server_name which is the domain name you want to serve.

It then defines the log locations for easy analysis and finally sets the server root and the index file.

As said, very basic at this stage.

sites-enabled

Last configuration we need to do is to 'enable' our site.

This is done with a symlink in the sites-enabled directory as follows:

sudo ln -s /etc/nginx/sites-available/domain1.com /etc/nginx/sites-enabled/domain1.com

Again, depending on how you installed Nginx, you may need to adjust the paths:

sudo ln -s /usr/local/nginx/sites-available/domain1.com /usr/local/nginx/sites-enabled/domain1.com

Restart Nginx

Although there is a restart option for the Nginx init script, it doesn't always work as expected and may not facilitate any changes you have made.

As such, I recommend a stop and start approach rather than a simple restart:

sudo /etc/init.d/nginx stop
...
sudo /etc/init.d/nginx start

Navigate

Now when you navigate to your domain:

http://www.domain1.com

You will see the equivalent of this:

Nice.

Rinse and Repeat

All you need to do for your next virtual host (domain2.com in this example) is to repeat the process.

I know I mention it a lot, but do remember to adjust any paths to match your Nginx installation.

So create a virtual host file:

sudo nano /etc/nginx/sites-available/domain2.com

Enter the details as shown above but for domain2.com and then create a symlink in the sites-enabled folder like this:

sudo ln -s /etc/nginx/sites-available/domain2.com /etc/nginx/sites-enabled/domain2.com

Restart Nginx:

sudo /etc/init.d/nginx stop
...
sudo /etc/init.d/nginx start

And away you go.

Logs

Remember we defined custom locations for the domain logs?

Well, let's have a check they are there:

ls /home/demo/public_html/domain1.com/log/
...
access.log  error.log

Excellent, everything is working as we expected and we have our domain logs in a nice and convenient location.

Summary

Setting up virtual hosts with Nginx is a simple process using the sites-available and sites-enabled folders.

Although the example here is quite basic, I hope you can see that getting to grips with Nginx syntax and configurations is not too difficult.

The next article will concentrate on some other settings for use in the virtual hosts file, thus allowing for more control and flexibility for your hosting needs.

PickledOnion.

Ubuntu Hardy - Nginx configuration

2008-05-15T15:04:00Z

Whether you have installed Nginx using the package manager or from source, you will need to look at the main configuration file and see what may need changing and optimising.

Although I'll make some suggestions, the aim is not to change a great deal at this point. Rather, we will look at the main settings, see what they mean and what a change will actually do.

Defaults

So why only a few changes to the default? Well, it's difficult to give a definitive configuration as there are so many variables to consider such as expected site traffic, Slice size, site type, etc.

During this article we'll discuss the main settings and you can make any decisions as to what you feel are best for your site. Any changes I do suggest are simply that: suggestions.

My advice is very simple: experiment. Find what works best on your setup.

nginx.conf

Assuming you installed via the package manager, open up the main Nginx config file:

sudo nano /etc/nginx/nginx.conf

If you installed from source, the location may be different:

sudo nano /usr/local/nginx/conf/nginx.conf

The default file is very similar in both case (again, assuming you followed the articles shown above):

user www-data;
worker_processes  1;

error_log  /var/log/nginx/error.log;
pid        /var/run/nginx.pid;

events {
    worker_connections  1024;
}

http {
    include       /etc/nginx/mime.types;
    default_type  application/octet-stream;

    access_log  /var/log/nginx/access.log;

    sendfile        on;
    #tcp_nopush     on;

    #keepalive_timeout  0;
    keepalive_timeout  65;
    tcp_nodelay        on;

    gzip  on;

    include /etc/nginx/sites-enabled/*;

}

The main difference you will see if you installed from source is the path in the 'include' setting which would be something like:

include /usr/local/nginx/sites-enabled/*;

Beyond that, any changes are minor and can be adjusted as discussed below although I won't mention some of the more obvious settings such access logs and pid's.

user

Default:

user www-data;

As you can imagine, this sets the nginx user.

I always push for consistency across servers and the default web server user on Debian based systems is www-data. As such, keep this as the www-data user.

You can also add a group to this setting and it may be an idea to do so as follows:

user www-data www-data;

worker_processes

Default:

worker_processes  1;

Nginx can have more than one worker process running at the same time.

To take advantage of SMP and to enable good efficiency I would recommend changing this to read:

worker_processes  4;

Although you can experiment with this number (and I encourage you to do so) setting it at more than 4 processes may actually cause Nginx to be less efficienct on your Slice.

worker_connections

Default:

events {
    worker_connections  1024;
}

Note the worker_connections setting is placed inside the 'events' module.

Sets the number of connections that each worker can handle. This is a good default setting.

You can work out the maximum clients value from this and the worker_processes settings:

max_clients = worker_processes * worker_connections

http module

Next comes the http module which contains base settings for http access:

include       /etc/nginx/mime.types;
default_type  application/octet-stream;

Unless you have an overwhelming desire, I would leave these settings alone (again, for those who installed via source, adjust the paths to those of your install).

You can, of course, add more includes if you want to customise it but messing with mime-types usually ends up with broken web pages and download errors.

Mind you, it is good fun to play with!

sendfile

Default:

sendfile        on;

Sendfile is used when the server (Nginx) can actually ignore the contents of the file it is sending. It uses the kernel sendfile support instead of using it's own resources on the request.

It is generally used for larger files (such as images) which do not need use of a multiple request/confirmation system to be served - thus freeing resources for items that do need that level of 'supervision' from Nginx.

Keep it an on unless you know why you need to turn it off.

tcp

Default:

#tcp_nopush     on;
tcp_nodelay        on;

tcp_nopush: Sends the HTTP response headers in one packet. You can read more about tcp_nopush on this page.

I would change the default here and uncomment the setting as it is useful when combined with the sendfile option we set earlier.

tcp_nodelay: Disables the Nagle buffering algorithm. Well, that cleared that one up!

Actually, it is for use with items than do not require a response. General web use does require a response from the client and so, going against the default, I would change this to off.

You can read more about tcp_nodelay here.

So there you are. After saying I wouldn't change a lot, I have changed the two default tcp settings. Your experience may show otherwise and, again, all I can say is experiment with your site/app - what do you need?

keepalive

Default:

#keepalive_timeout  0;
keepalive_timeout  65;

The default is very high and can easily be reduced to a few seconds (an initial setting of 2 or 3 is a good place to start and you will rarely need more than that). If no new requests are received during this time the connection is killed.

OK, but what does it mean? Well, once a connection has been established and the client has requested a file, this says "sit there and ignore everyone else until the time limit is reached or you get a new request from the client".

Why would you want a higher time? In cases where there will be a lot of interactivity on the site. However, in most cases, people will go to a page, read it for a while and then click for the next page. You don't want the connection sat there doing nothing and ignoring other users.

gzip

Default:

gzip  on;

Good. We like gzip. It allows for instant, real time compression.

However, I would add a few more settings as follows:

gzip_comp_level 2;
gzip_proxied any;
gzip_types      text/plain text/html text/css application/x-javascript text/xml application/xml 
application/xml+rss text/javascript;

I think those are self explanatory and simply add to the gzip setting. You can read more about the various gzip settings on this page.

include

Default:

include /etc/nginx/sites-enabled/*;

If you installed from source, we added this line:

include /usr/local/nginx/sites-enabled/*;

Either way, it defines what files to include that are located outside of the main nginx.conf.

In this case, it points to the sites-enabled directory so it will include any symlinks. Thus enabling any 'available' sites.

Summary

There is a lot going on in this article, especially from such a small config file.

However, taking one setting at a time, we can see that each one is not only essential but pretty flexible.

The next article will take you through setting up virtual hosts and then move onto mongrel and thin integration for your Ruby on Rails applications.

PickledOnion.

Ubuntu Hardy - Nginx from source layout

2008-05-15T11:19:00Z

Following from the main installing Nginx from source and creating an init script articles we can now move onto looking at the Nginx layout.

The idea of this article is to change the default layout to one more in keeping with the 'Debian' style. Installing Nginx via the package manager creates this layout automatically - we need to do it by hand.

Why?

You do, of course, have the option of leaving the layout exactly as it is.

However, any further Nginx articles will use the 'Debian' layout which includes sites-available and sites-enabled folders.

This gives common ground to those who installed Nginx via the 'aptitude' package manager and those who installed Nginx via source.

As an aside, I also find it a very convenient and easy way of organising my virtual hosts.

Layout

As alluded to, the layout we want to create is the same as if we installed Nginx via the package manager.

The main difference being that any any virtual host files are kept in a 'sites-available' folder - each vhost has its own file and configurations.

This makes for easy administration as they are not all placed in one unwieldy monolithic file.

One thing to note is that any vhosts in the 'sites-available' folder are not 'live' - to enable a vhost, we simply place a symlink in a 'sites-enabled' folder pointing to the vhost file.

Folders

Let's start by creating the two main folders (remember Nginx was installed into '/usr/local/nginx'):

sudo mkdir /usr/local/nginx/sites-available
...
sudo mkdir /usr/local/nginx/sites-enabled

Done.

Configuration

Now we need to adjust the main Nginx configuration file to look in the sites-enabled folder for our vhosts:

sudo nano /usr/local/nginx/conf/nginx.conf

I won't list the contents of the file here but note that the vast majority of the contents consists of two virtual hosts - a default for port 80 and a default for port 443 (which is actually commented out).

This is a great example of an unwieldy file - it contains just two virtual hosts and is already difficult to follow in a terminal.

The easiest thing is to delete the contents of the file (you can make a copy if you wish) and replace it with this:

user www-data;
worker_processes  1;

events {
    worker_connections  1024;
}

http {
    include       mime.types;
    default_type  application/octet-stream;

    sendfile        on;

    keepalive_timeout  65;

    gzip  on;

    include /usr/local/nginx/sites-enabled/*;

}

The contents are very similar to those created when installing Nginx via the package manager.

Let's save the file and move onto creating a default vhost.

Default vhost

Create a default vhost file in the sites-available folder:

sudo nano /usr/local/nginx/sites-available/default

The contents are very simple and come from the original configuration:

server {
    listen       80;
    server_name  localhost;

    location / {
        root   html;
        index  index.html index.htm;
    }


    # redirect server error pages to the static page /50x.html
    #
    error_page   500 502 503 504  /50x.html;
    location = /50x.html {
        root   html;
    }

}

To enable the vhost all we need to do is create a symlink:

sudo ln -s /usr/local/nginx/sites-available/default /usr/local/nginx/sites-enabled/default

Restart

Restart Nginx:

sudo /etc/init.d/nginx restart

Navigating to your Slice IP will show the default "Welcome to nginx!' page.

Done.

To create any further virtual hosts all you need to do is create the main file in the sites-available folder, create a symlink in the sites-enabled folder and restart Nginx.

All very simple and very organised.

Summary

Mirroring the layout used when installing Nginx via the aptitude package manager allows for much easier administration of your virtual hosts - each vhost has its own file and can be switched on and off by a symlink to the sites-enabled folder.

The next article will look at configuring and optimising Nginx for use on your Slice.

PickledOnion

SliceManager API Documentation

2008-05-13T17:40:00Z

The SliceManager API allows for the easy and convenient manipulation of your Slicehost account.

Latest Version

Any changes to the API process will be shown in the latest ebook version:

SliceManager API ebook - v1.3.0.pdf

Please see below for a changelog between versions.

Changelog

v1.3.0 - May 22 2008

Addition of flavor image and slice

v1.2.0 - April 2008

Official release.

PickledOnion.

Ubuntu Hardy - adding an nginx init script

2008-05-13T15:18:00Z

If you decided to install Nginx via source (see the previous article) you would have the latest and greatest version.

However, one disadvantage of installing from source is that init scripts are not created. No problem, let's go ahead and create one for easy control of Nginx and to ensure it restarts on a reboot.

Assumption

I am assuming you have followed the previous article and installed Nginx from source.

If you have used other options or have placed the nginx binary in a directory other than /usr/local/sbin/ then you will need to adjust the script shown below to match your installation.

Stop

If you have nginx running then stop the process using:

sudo kill `cat /usr/local/nginx/logs/nginx.pid`

Init script

The script I use below is from an Ubuntu Hardy 'aptitude' install and has been adapted to take into account our custom install of nginx.

Let's go ahead and create the script:

sudo nano /etc/init.d/nginx

Inside the blank file place the following:

#! /bin/sh

### BEGIN INIT INFO
# Provides:          nginx
# Required-Start:    $all
# Required-Stop:     $all
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: starts the nginx web server
# Description:       starts nginx using start-stop-daemon
### END INIT INFO

PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
DAEMON=/usr/local/sbin/nginx
NAME=nginx
DESC=nginx

test -x $DAEMON || exit 0

# Include nginx defaults if available
if [ -f /etc/default/nginx ] ; then
        . /etc/default/nginx
fi

set -e

case "$1" in
  start)
        echo -n "Starting $DESC: "
        start-stop-daemon --start --quiet --pidfile /usr/local/nginx/logs/$NAME.pid \
                --exec $DAEMON -- $DAEMON_OPTS
        echo "$NAME."
        ;;
  stop)
        echo -n "Stopping $DESC: "
        start-stop-daemon --stop --quiet --pidfile /usr/local/nginx/logs/$NAME.pid \
                --exec $DAEMON
        echo "$NAME."
        ;;

  restart|force-reload)
        echo -n "Restarting $DESC: "
        start-stop-daemon --stop --quiet --pidfile \
                /usr/local/nginx/logs/$NAME.pid --exec $DAEMON
        sleep 1
        start-stop-daemon --start --quiet --pidfile \
                /usr/local/nginx/logs/$NAME.pid --exec $DAEMON -- $DAEMON_OPTS
        echo "$NAME."
        ;;
  reload)
      echo -n "Reloading $DESC configuration: "
      start-stop-daemon --stop --signal HUP --quiet --pidfile /usr/local/nginx/logs/$NAME.pid \
          --exec $DAEMON
      echo "$NAME."
      ;;
  *)
        N=/etc/init.d/$NAME
        echo "Usage: $N {start|stop|restart|reload|force-reload}" >&2
        exit 1
        ;;
esac

exit 0

There's not really the space to go into the workings of the script but suffice to say, it defines where the main nginx binary and pid files are located so nginx can be started correctly.

Execute

As the init file is a shell script, it needs to have executable permissions.

We set them like so:

sudo chmod +x /etc/init.d/nginx

update-rc

Now we have the base script prepared, we need to add it to the default run levels:

sudo /usr/sbin/update-rc.d -f nginx defaults

The output will be similar to this:

Adding system startup for /etc/init.d/nginx ...
   /etc/rc0.d/K20nginx -> ../init.d/nginx
   /etc/rc1.d/K20nginx -> ../init.d/nginx
   /etc/rc6.d/K20nginx -> ../init.d/nginx
   /etc/rc2.d/S20nginx -> ../init.d/nginx
   /etc/rc3.d/S20nginx -> ../init.d/nginx
   /etc/rc4.d/S20nginx -> ../init.d/nginx
   /etc/rc5.d/S20nginx -> ../init.d/nginx

Done.

Start, Stop and Restart

Now we can start, stop and restart nginx just as with any other service:

sudo /etc/init.d/nginx start
...
sudo /etc/init.d/nginx stop
...
sudo /etc/init.d/nginx restart

The script will also be called on a reboot so nginx will automatically start.

Summary

Adding a process to the run levels like this saves a lot of frustration and effort, not only in manually starting and stopping the process, but it having it automatically start on a reboot.

PickledOnion.

Ubuntu Hardy - Installing Nginx from source

2008-05-13T10:46:00Z

Nginx is a popular lightweight server for those who do not need the bulk and extra services that Apache may offer.

This article will look at installing Nginx from source on an Ubuntu Hardy Slice.

Versions

At the time of writing, the latest stable version of Nginx is 0.6.31. You can check the latest versions and change logs at the main nginx site.

Do note that Nginx is also available from Hardy's package manager (aptitude) and is at version 0.5.33.

Using the inbuilt package manager will ensure any dependencies are taken care of and any security issue (if any arise) are taken care of with a simple update.

Please see this article if you want to install Nginx with the package manager.

Layout

One final difference that is worth considering is the layout differences between using the packaged version and installing from source.

Ubuntu's packaged version of Nginx uses a 'sites-available' and 'sites-enabled' layout in the same manner as a Debian based Apache install.

Although installing from source does not automatically create this layout, I will show how to adjust the folders and config files to do so.

Mirroring the layout used in the packed version of Nginx gives us 'common ground' when moving onto creating virtual hosts and further configuration articles.

Dependencies

As we are not using the package manager to install nginx, we need to take care of some dependencies.

Not many are needed and include pcre, ssl and zlib packages:

sudo aptitude install libpcre3 libpcre3-dev libpcrecpp0 libssl-dev zlib1g-dev

Download

Now we can download the source code.

Create a 'sources' directory (you can download it anywhere you want to):

mkdir ~/sources

Now move into the folder:

cd ~/sources/

And then download the source code:

wget http://sysoev.ru/nginx/nginx-0.6.31.tar.gz

Unpack

Unpack the downloaded tar file and move into the newly created directory:

tar -zxvf nginx-0.6.31.tar.gz
...
cd nginx-0.6.31/

Options

There are quite a few compile time options that are available to use.

Have a look at the Install Options page of the nginx wiki for full details.

We're going to use just two options to customise the install. The first of which is:

--sbin-path=/usr/local/sbin

By default, nginx will be installed in /usr/local/nginx which, although a good place, does mean the main nginx binary will be found in /usr/local/nginx/sbin/nginx.

Not a location we are likely to find in our default search paths. So instead of adding new directories to our path (which may cause errors later on) we simply define where to put the binary.

The second option is:

--with-http_ssl_module

Probably self explanatory, but this will enable the ssl module to be compiled so we can parse https requests.

Compile

Let's go ahead and compile nginx using those two options:

./configure --sbin-path=/usr/local/sbin --with-http_ssl_module

There will be a nice summary at the end of the compile which includes such items as:

...
nginx path prefix: "/usr/local/nginx"
nginx binary file: "/usr/local/sbin"
nginx configuration file: "/usr/local/nginx/conf/nginx.conf"
...

Keep a note of the output as it does contain some useful paths and locations for various files.

Make

Ok, let's go ahead and 'make' and then 'make install':

make
...
sudo make install

Defaults

Done. We can test the install by starting nginx:

sudo /usr/local/sbin/nginx

and navigating to our Slice IP address (assuming you have no other server running):

http://123.45.67.890

You will be greeted with the standard welcome page:

Stop

If you have used Apache or some other web server (or even installing Nginx via a package manager), you may be used to using a script to start and stop it such as you might find in '/etc/init.d/'.

Unfortunately, compiling from source does not create a script like that (we will create an init script in the next article or two).

You may have noticed that one of the paths noted in the compile summary was:

nginx pid file: "/usr/local/nginx/logs/nginx.pid"

Let's make use of that to stop nginx:

sudo kill `cat /usr/local/nginx/logs/nginx.pid`

That will use the output of the pid file to kill the nginx process - note the use of backslashes (`) and not single quotes (') in the command.

Summary

Although quite detailed, we have installed the latest version of nginx from source and compiled it with some custom options to make life slightly easier.

We also know how to start and stop nginx by hand.

As mentioned, the next couple of articles will deal with learning how to create an init script so we have more control over Nginx and in mirroring the 'Debian' style layout to include sites-available and sites-enabled folders and so on.

Once done, we will then look at configuring nginx, setting up vhosts and proxying to a backend (such as a cluster of mongrels).

PickledOnion.

Ubuntu Hardy - Installing Nginx via aptitude

2008-05-13T10:07:00Z

Nginx is a popular lightweight server for those who do not need the bulk and extra services that Apache may offer.

This article will look at installing Nginx on an Ubuntu Hardy Slice using the 'aptitude' package manager.

Using the inbuilt package manager to install packages is a great idea as it solves dependency issues and you are assured of any security updates if, and when, they occur.

However, one drawback can be that it is rare for a version upgrade to be placed into the repositories. As such, it is possible for a newer version of an application to be released and not be placed into the repository.

Versions

Using aptitude, Ubuntu Hardy will instal Nginx version 0.5.33.

However, at the time of writing, the latest stable version of Nginx is 0.6.31. You can check the latest versions and change logs at the main nginx site.

Which one you choose is, of course, entirely up to you.

If you decide you would rather have a later version of Nginx than the one aptitude provides, then please refer to the sister article (link on the way) which will take you through the process of installing Nginx from source.

Install and Dependencies

Installing Nginx is incredibly simple as it involves one command:

sudo aptitude install nginx

This will install any and all dependencies that Nginx requires such as libpcre.

Start

One odd thing is that Nginx is not started automatically:

sudo /etc/init.d/nginx start

Done

Navigate

Now simply navigate to your IP address:

http://123.45.67.890

and you will see the wonderfully simple welcome screen:

Init scripts

As you would imagine when installing an application with the aptitude package manager, all init scripts have been created and added to the relevant run levels.

Controlling nginx is done with these commands:

sudo /etc/init.d/nginx start
...
sudo /etc/init.d/nginx stop
...
sudo /etc/init.d/nginx restart

That's it.

Summary

Using the aptitude package manager makes the installation of Nginx and associated dependencies very simple indeed.

The only thing to consider is the version disparity between the one offered by aptitude and the one available via source code.

PickledOnion.

Ubuntu Hardy - Apache, Rails and mongrels

2008-05-09T12:44:00Z

Following from the mongrel and mongrel cluster article, we can now look at creating and configuring Apache to proxy to a mongrel cluster so we can serve our Ruby on Rails application.

Prerequisites

To get the most out of this article you need to have a couple of things preinstalled:

Firstly, you need Apache installed (see this article) - if you don't require PHP then please feel free to leave that section out.

Secondly, you will need to have installed mongrels as per the mongrel and mongrel cluster article link above.

Rails application

To start with, we will need a basic Ruby on Rails application. Move into your public_html folder (create one if you do not have one already):

cd ~/public_html

Then create a Rails application. We'll use the default sqlite database for this example:

rails railsapp

Apache modules

Apache will need the proxy and rewrite modules enabled.

Depending on your Apache install you may need to issue all the following commands:

sudo a2enmod proxy
sudo a2enmod proxy_balancer
sudo a2enmod proxy_http
sudo a2enmod rewrite

Once done, reload Apache:

sudo /etc/init.d/apache2 force-reload

What's the plan, Stan?

Well, for our simple application we're going to create a mongrel cluster consisting of 3 mongrels running on port 5000 in production mode. We'll also add a symlink so the cluster will restart if the Slice is rebooted at any point.

Then we can create an Apache virtual host to serve the Ruby on Rails application.

Mongrel Cluster

I won't go into the details of explaining what the commands are in this section. Please refer to the main mongrel and mongrel cluster article for that.

Ensure you are in the rails folder:

cd ~/public_html/railsapp

Then create a mongrel cluster file as such:

mongrel_rails cluster::configure -e production -p 5000 -N 3 -c /home/demo/public_html/railsapp -a 127.0.0.1

It's always a good idea to check the created file (config/mongrel_cluster.yml):

cwd: /home/demo/public_html/railsapp
log_file: log/mongrel.log
port: "5000"
environment: production
address: 127.0.0.1
pid_file: tmp/pids/mongrel.pid
servers: 3

Looks good.

Now create a symlink to the /etc/mongrel_cluster folder. This ensures the cluster is restarted on a reboot:

sudo ln -s /home/demo/public_html/railsapp/config/mongrel_cluster.yml /etc/mongrel_cluster/railsapp.yml

Now all we need to do is start the cluster:

mongrel_cluster_ctl start

Done.

Apache Virtual Host

Now we can create the virtual host:

sudo nano /etc/apache2/sites-available/domain.com

he following will suffice for a basic application:

<VirtualHost *:80>
  ServerName domain.com
  ServerAlias www.domain.com

  DocumentRoot /home/demo/public_html/railsapp/public

  RewriteEngine On

  <Proxy balancer://mongrel1>
    BalancerMember http://127.0.0.1:5000
    BalancerMember http://127.0.0.1:5001
    BalancerMember http://127.0.0.1:5002
  </Proxy>

  # Redirect all non-static requests to thin
  RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f
  RewriteRule ^/(.*)$ balancer://mongrel1%{REQUEST_URI} [P,QSA,L]

  ProxyPass / balancer://mongrel1/
  ProxyPassReverse / balancer://mongrel1/
  ProxyPreserveHost on

  <Proxy *>
    Order deny,allow
    Allow from all
  </Proxy>

  # Custom log file locations
  ErrorLog  /home/demo/public_html/railsapp/log/error.log
  CustomLog /home/demo/public_html/railsapp/log/access.log combined

</VirtualHost>

Nice and simple and, as you may have noticed, is the pretty much the same as the Apache vhost we created when using the 'thin' web server (see this article).

There is a good reason they are the same - all they are doing is proxying rails requests to the 3rd party server. In this case, the requests are proxied to the mongrel cluster.

Enable

Now we must enable the vhost:

sudo a2ensite domain.com

Reload Apache:

sudo /etc/init.d/apache2 reload

If you get any port and NameVirtualHost errors then please read the Apache Virtual Host article which will take you through setting up said details.

Navigate

All that's left is to navigate to your domain:

http://www.domain.com

Where you will be greeted with the rails welcome page.

Summary

Setting up a virtual host to proxy to a mongrel cluster is fairly simple.

Although setting up and configuring mongrel, especially if you want them restart on a reboot, can be a bit complicated, once done it is a quick and powerful method in serving your Ruby on Rails application.

PickledOnion

Ubuntu Hardy - mongrel and mongrel clusters

2008-05-09T11:39:00Z

There are variety of options open to the sysadmin when serving Ruby applications.

One of the original ways is to use the mongrel web server. Requests are proxied to the mongrel(s) from the main web server (Apache, Nginx, etc).

The article may seem quite lengthy but two subjects are tackled here. One is the basic mongrel gem itself but then we move onto the mongrel_cluster gem.

Take each section at a time as each one builds on the previous explanation.

Prerequisites

I am assuming you have Ruby and Rubygems installed on your Slice. If you don't, please see the Ubuntu Hardy Ruby on Rails article).

Installation

Mongrel is a rubygem and installation is as simple as:

sudo gem instal mongrel

On the test Slice with a basic rubygems and Rails installation, the process installed the following gems:

gem_plugin-0.2.3
daemons-1.0.10
fastthread-1.0.1
cgi_multipart_eof_fix-2.5.0
mongrel-1.1.4

That can vary depending on what you already have installed.

Mongrel basics

The mongrel package has 3 main commands: start, stop and restart.

However, there are many options you could add to fit your needs such as the environment or the port and so on:

mongrel_rails start -e production -p 6000

You need to be in the rails application directory to issue that command and, perhaps obviously, it would start a mongrel instance in production mode on port 6000.

If you don't run it in the background (daemonised) then the output in the terminal will be similar to when using the inbuilt rails webbrick server.

To run it in the backgroud, simply add the '-d' option:

mongrel_rails start -e production -p 6000 -d

To stop the running process (assuming it is being run in a daemonised fashion):

mongrel_rails stop

Again, the command should be given when in the rails directory.

Mongrel Clusters

You can run as many individual mongrels as you like for your application but it does get a little unwieldy if you have more than one application.

One solution is to create what are called mongrel clusters. These 'clusters' are predefined groups of mongrels which are easy to start and stop, etc as a cluster and be configured to start on a Slice reboot (so your application will start itself on a reboot).

Installation

Just as with the original mongrel install, the mongrel_cluster is a rubygem:

sudo gem install mongrel_cluster

As I had already installed the mongrel gem with its dependencies, only the mongrel_cluster gem itself was installed. This may vary on your Slice, depending on what you already have installed.

Configuration

Configuring a mongrel cluster for your rails application runs along similar lines to the single mongrel options shown above.

To start a cluster of 2 mongrels in production mode starting from port 8000 would be as follows:

mongrel_rails cluster::configure -e production -p 8000 -N 2 -c /home/demo/public_html/testapp -a 127.0.0.1

Note that I set the full path of the rails application and set the port to bind to (localhost in this case).

There are plenty of option available when configuring a mongrel cluster and the easiest thing is to have a look at the help file:

mongrel_rails cluster::configure -h

YAML

You will have noticed the output of the command is as follows:

Writing configuration file to config/mongrel_cluster.yml.

The contents of which are:

cwd: /home/demo/public_html/testapp
log_file: log/mongrel.log
port: "8000"
environment: production
address: 127.0.0.1
pid_file: tmp/pids/mongrel.pid
servers: 2

Well, no real surprises there, it simply puts the mongrel cluster options into a YAML format.

You can edit the file by hand if you wish to change something and don't want to go through the configure command again.

Mongrel_cluster basics

Starting the cluster is a case of:

mongrel_rails cluster::start

Ensure you are in your rails application folder when you issue the command.

Stopping and restarting:

mongrel_rails cluster::restart
...
mongrel_rails cluster::stop

init scripts

The final configuration you may want to consider (and I recommend it) is to create an init script so the mongrel cluster is started on a reboot.

Unlike 'thin' or mod_rails there is no easy way of doing this so it does require a some work.

Firstly, create a folder in the /etc folder:

sudo mkdir /etc/mongrel_cluster

Then create a symlink from the cluster configuration file to the newly created folder:

sudo ln -s /home/demo/public_html/testapp/config/mongrel_cluster.yml /etc/mongrel_cluster/testapp.yml

You will have to do that for each and every mongrel_cluster you create (if you want them to start automatically). So if you have two rails applications, you will have two symlinks.

Next, copy the gem init script to the init.d directory:

sudo cp /usr/lib/ruby/gems/1.8/gems/mongrel_cluster-1.0.5/resources/mongrel_cluster /etc/init.d/

Make it executable:

sudo chmod +x /etc/init.d/mongrel_cluster

and then add the script to the runlevels:

sudo /usr/sbin/update-rc.d -f mongrel_cluster defaults

Wow. Quite a long and complicated procedure when compared to using 'thin' or mod_rails.

Cluster control

Let's take a quick look at controlling the clusters.

Getting a status of any running clusters is always nice:

mongrel_cluster_ctl status

The output will show something along the lines of:

Checking all mongrel_clusters...
mongrel_rails cluster::status -C testapp.yml
found pid_file: tmp/pids/mongrel.8000.pid
found mongrel_rails: port 8000, pid 2343

found pid_file: tmp/pids/mongrel.8001.pid
found mongrel_rails: port 8001, pid 2346

That matches the cluster we created earlier so no problems.

To start/stop/restart the cluster(s):

mongrel_cluster_ctl start
...
mongrel_cluster_ctl stop
...
mongrel_cluster_ctl restart

Remember you may need to put a sudo in front of the 'stop' command if you have just rebooted as the process started on reboot is owned by root.

Summary

There is a lot happening in this article but when followed all the way through, we have all the necessary gems and information to create mongrel clusters for each of our rails applications.

A simple symlink is then all it takes to ensure the cluster is restarted on a reboot.

PickledOnion

Ubuntu Hardy - Apache, Rails and thin

2008-05-06T13:25:00Z

Following from the thin web server for Ruby article, let's look at creating and configuring Apache to proxy to thin so we can serve our Ruby on Rails application.

Prerequisites

To get the most out of this article you need to have a couple of things preinstalled:

Firstly, you need Apache installed (see this article) - if you don't require PHP then please feel free to leave that section out.

Secondly, you will need to have thin installed - as mentioned above, please see the Ubuntu Hardy - thin web server for Ruby article for more details.

Rails application

To start with, we will need a basic Ruby on Rails application. Move into your public_html folder (create one if you do not have one already):

cd ~/public_html

Then create a Rails application. We'll use the default sqlite database for this example:

rails railsapp

Apache modules

Apache will need the proxy and rewrite modules enabled.

Depending on your Apache install you may need to issue all the following commands:

sudo a2enmod proxy
sudo a2enmod proxy_balancer
sudo a2enmod proxy_http
sudo a2enmod rewrite

Once done, reload Apache:

sudo /etc/init.d/apache2 force-reload

Apache Virtual Host

So what's the plan?

Well, for our simple application we'll set 3 thin instances running from port 5000 and in production mode.

Let's start off by creating the virtual host:

sudo nano /etc/apache2/sites-available/domain.com

The following will suffice for a basic application:

<VirtualHost *:80>
  ServerName domain.com
  ServerAlias www.domain.com

  DocumentRoot /home/demo/public_html/railsapp/public

  RewriteEngine On

  <Proxy balancer://thinservers>
    BalancerMember http://127.0.0.1:5000
    BalancerMember http://127.0.0.1:5001
    BalancerMember http://127.0.0.1:5002
  </Proxy>

  # Redirect all non-static requests to thin
  RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f
  RewriteRule ^/(.*)$ balancer://thinservers%{REQUEST_URI} [P,QSA,L]

  ProxyPass / balancer://thinservers/
  ProxyPassReverse / balancer://thinservers/
  ProxyPreserveHost on

  <Proxy *>
    Order deny,allow
    Allow from all
  </Proxy>

  # Custom log file locations
  ErrorLog  /home/demo/public_html/railsapp/log/error.log
  CustomLog /home/demo/public_html/railsapp/log/access.log combined

</VirtualHost>

Familiar?

Does that look familiar?

Well, it is pretty much the same as the virtual host used to proxy to mongrel servers.

If you think about it, we don't need anything different as all we are doing is rerouting non-static requests to thin in the same way we would for mongrels.

Enable

Don't forget to enable the vhost:

sudo a2ensite domain.com

And restart Apache:

sudo /etc/init.d/apache2 reload

If you get any port and NameVirtualHost errors then please read the Apache Virtual Host article which will take you through setting up said details.

Thin configuration

Next we need to configure thin on our application.

To kill two birds with one stone, we'll go straight into creating an init.d file so the thin servers are started on a Slice reboot.

Remember we want 3 servers running sequentially from port 5000 in production mode:

sudo thin config -C /etc/thin/railsapp.yml -c /home/demo/public_html/railsapp/  --servers 3 -p 5000 -e production

Have a quick check of the file we created:

cat /etc/thin/railsapp.yml

the contents of which look good:

pid: tmp/pids/thin.pid
log: log/thin.log
timeout: 30
max_conns: 1024
port: 5000
max_persistent_conns: 512
chdir: /home/demo/public_html/railsapp
environment: production
servers: 3
address: 0.0.0.0
daemonize: true

Stating thin

Now we'ce created our init script, let's start it:

sudo /etc/init.d/thin start

The terminal output confirms the actions:

[start] /etc/thin/railsapp.yml ...
Starting server on 0.0.0.0:5000 ... 
Starting server on 0.0.0.0:5001 ... 
Starting server on 0.0.0.0:5002 ...

Cool.

Navigate

All that's left is to navigate to your domain:

http://www.domain.com

Where you will be greeted with the rails welcome page.

Restart

As we created an init script for the thin servers you can restart them in the normal way:

sudo /etc/init.d/thin restart

Summary

Setting up a virtual host to proxy to the thin web server is fairly simple.

Add to that the ease of installing and configuring thin, the whole process in very quick and very powerful.

PickledOnion