Search
Translations of this page:

Proxying to a port

See the ports page on how to pick a port assigned for your account

.

If you have an application running on a port on your account (e.g. a Mongrel listening on port 8001), it's only available at e.g. http://yoursite.com:8001/), which makes it undesirable for production use. Proxying lets you get rid of the port number and hide the application behind your domain (e.g. at http://yoursite.com/). The following steps will show you how to proxy your Rails application to a domain and also to a subdomain.

Make sure you have enabled the web virtual server, otherwise you will not be able to serve websites from your domain. You can enable the web virtual server from Virtualmin by doing the following:

  1. Sign in to Virtualmin (see Account logins and important URLs).
  2. Select a virtual server from the drop-down in the left-hand navigation (your main virtual server should be already selected when you first login to Virtualmin).
  3. Click Edit Virtual Server in the left-hand navigation.
  4. Click Enabled features
  5. Select Apache website enabled? and click Save Virtual Server

There are two ways to proxy to a port:

  • Using Virtualmin: This is probably easiest to accomplish because you can use the interface controls in Virtualmin. However, it doesn't give you any fine grain control over what's being proxied: it merely switches all traffic of your domain to proxy down to an application on a port, which makes it good for situations where your entire domain will be powered by the application.
  • Using mod_rewrite in a .htaccess file: This is a powerful approach, as it gives you full control over what kind of hostnames and paths are being proxied. On the other hand, it will require you to dive into the htaccess syntax and customize the template file we provide as needed. Also, this is the approach you should choose if you only need a sub-domain proxied, and keep the rest of the domain handled in another way.

Rails applications previously did not work well on subdirectories (e.g. http://yoursite.com/wiki/) without some adjustment to the Rails configuration, so it was difficult to proxy to a subdirectory only. We suggest you stick with proxying to a subdomain as shown below (the .htaccess way). Mongrel provides a workaround in the form of the --prefix parameter, but this is experimental from our point of view.

Rails applications should be installed outside web/public/. Unless you install your application directly into web/ (ie the simple method for a single app) Virtualmin proxying won’t let you do .htaccess redirects, because the app’s public folder will be outside document_root. For multiple apps on one domain use .htaccess proxying, and web/public/ for static (Apache-served) files.

Virtualmin Proxy (Easy)

Let's start with the Virtualmin way:

  1. Sign in to Virtualmin (see Account logins and important URLs).
  2. Select a domain from the drop-down in the left-hand navigation (your main domain should be already selected when you first login to Virtualmin). This is the domain that you'll add a proxy to.
  3. Click Server Configuration, then Edit Proxy Website.
  4. Set Proxying enabled? to Yes.
  5. For Proxy to URL, enter the destination URL of your application, e.g. http://127.0.0.1:8001/, replacing 8001 with the port your application is running on.
  6. Click Save and Apply.

Do not forget the trailing slash on the Proxy to URL. The correct proxying URL ends with a port number followed by a slash. Failing to provide the slash can result in non-functional URLs on your application.

.htaccess Proxy (Advanced)

To use a .htaccess file file for proxying, you'll be employing the proxying capabilities of the Apache mod_rewrite module. This means that you can have complex regular expression rules that trigger the Apache proxying features.

You can construct your own .htaccess file if you know what you are doing, or use our example template here:

You'll need to edit the template file first to make sure it suits your needs. The contents of the file are commented and should be self-explanatory. The rules and exceptions that are inactive by default have been commented out using a # character at the beginning of line. Feel free to enable/disable rules as needed, and add additional RewriteRules between section A and B. The layout of the template is simple:

  1. Enable mod_rewrite (the A section).
  2. Define rules and action for requests that should not be proxied (the B section).
  3. Define rules and action for requests that should be proxied (the C section)

When uploading the .htaccess file to your virtual server's document root directory, make sure that the resulting uploaded file is named '.htaccess' (starts with a dot) and is formatted with UNIX line breaks - you may need to configure your local text editor for that. Also, make the file world readable (644 permissions), because Apache reads this before it locks itself down to execute as 'your' user.

.htaccess Proxy to a subdirectory

Mongrel now supports easily deploying a rails application to a sub directory. The following settings allow you to set up your site so that the only portion proxied to your rails application is the sub directory you want to deploy it to.

Your .htaccess file should look like this (replacing the directory and port, with those appropriate to your set up):

RewriteEngine on
RewriteCond %{REQUEST_URI} ^/(directory)
RewriteRule ^(.*)$ http://127.0.0.1:8001/$1 [P,QSA,L]

You should start your rails app using mongrel:

 mongrel_rails start -e production -p 8001 --prefix=/directory -d 
 
shared/kb/proxying.txt · Last modified: 2010/01/04 11:45 by filip
 
Recent changes RSS feed Creative Commons License Driven by DokuWiki