[[user_switching]]
=== User switching (security) ===

There is a problem that plagues most PHP web hosts, namely the fact that all PHP
applications are run in the same user context as the web server. So for
example, Joe's PHP application will be able to read Jane's PHP application's
passwords. This is obviously undesirable on many servers.

Phusion Passenger solves this problem by implementing 'user switching'. A Rails
application is started as the owner of the file 'config/environment.rb',
and a Rack application is started as the owner of the file 'config.ru'.
So if '/home/webapps/foo/config/environment.rb' is owned by 'joe', then Phusion
Passenger will launch the corresponding Rails application as 'joe' as well.

This behavior is the default, and you don't need to configure anything. But
there are things that you should keep in mind:

- The owner of 'environment.rb' must have read access to the Rails application's
  folder, and read/write access to the Rails application's 'logs' folder.
  Likewise, the owner of 'config.ru' must have read access to the Rack application's
  folder.
- This feature is only available if Apache is started by 'root'. This is the
  case on most Apache installations.
- Under no circumstances will applications be run as 'root'. If
  'environment.rb'/'config.ru' is owned as root or by an unknown user, then the
  Rails/Rack application will run as the user specified by
  <<PassengerDefaultUser,PassengerDefaultUser (Apache)>>/<<PassengerDefaultUser,passenger_default_user (Nginx)>>.

User switching can be disabled with the
<<PassengerUserSwitching,PassengerUserSwitching (Apache)>>/<<PassengerUserSwitching,passenger_user_switching (Nginx)>>
option.


[[reducing_memory_usage]]
=== Reducing memory consumption of Ruby on Rails applications by 33% ===

Is it possible to reduce memory consumption of your Rails applications by 33% on average,
by using http://www.rubyenterpriseedition.com/[Ruby Enterprise Edition].
Please visit the website for details.

Note that this feature does not apply to Rack applications.

[[capistrano]]
=== Capistrano recipe ===

Phusion Passenger can be combined with link:http://capify.org/[Capistrano].
The following Capistrano recipe demonstrates Phusion Passenger support.
It assumes that you're using Git as version control system.

--------------------------------------------------
set :application, "myapp"
set :domain,      "example.com"
set :repository,  "ssh://#{domain}/path-to-your-git-repo/#{application}.git"
set :use_sudo,    false
set :deploy_to,   "/path-to-your-web-app-directory/#{application}"
set :scm,         "git"

role :app, domain
role :web, domain
role :db,  domain, :primary => true

namespace :deploy do
  task :start, :roles => :app do
    run "touch #{current_release}/tmp/restart.txt"
  end
  
  task :stop, :roles => :app do
    # Do nothing.
  end
  
  desc "Restart Application"
  task :restart, :roles => :app do
    run "touch #{current_release}/tmp/restart.txt"
  end
end
--------------------------------------------------


[[moving_phusion_passenger]]
=== Moving Phusion Passenger to a different directory ===

It is possible to relocate the Phusion Passenger files to a different directory. It
involves two steps:

1. Moving the directory.
2. Updating the ``PassengerRoot'' configuration option in Apache.

For example, if Phusion Passenger is located in '/opt/passenger/', and you'd like to
move it to '/usr/local/passenger/', then do this:

1. Run the following command:
+
------------------------------------
mv /opt/passenger /usr/local/passenger
------------------------------------
2. Edit your Apache configuration file, and set:
+
------------------------------------
PassengerRoot /usr/local/passenger
------------------------------------

=== Installing multiple Ruby on Rails versions ===

Each Ruby on Rails applications that are going to be deployed may require a
specific Ruby on Rails version. You can install a specific version with
this command:
-----------------------------
gem install rails -v X.X.X
-----------------------------
where 'X.X.X' is the version number of Ruby on Rails.

All of these versions will exist in parallel, and will not conflict with each
other. Phusion Passenger will automatically make use of the correct version.

=== Making the application restart after each request ===

In some situations it might be desirable to restart the web application after
each request, for example when developing a non-Rails application that doesn't
support code reloading, or when developing a web framework.

To achieve this, simply create the file 'tmp/always_restart.txt' in your
application's root folder. Unlike 'restart.txt', Phusion Passenger does not
check for this file's timestamp: Phusion Passenger will always restart the
application, as long as 'always_restart.txt' exists.

NOTE: If you're just developing a Rails application then you probably don't need
this feature. If you set 'RailsEnv development' in your Apache configuration,
then Rails will automatically reload your application code after each request.
'always_restart.txt' is only useful if you're working on Ruby on Rails itself,
or when you're not developing a Rails application and your web framework
does not support code reloading.

[[sub_uri_deployment_uri_fix]]
=== How to fix broken images/CSS/JavaScript URIs in sub-URI deployments

Some people experience broken images and other broken static assets when they
deploy their application to a sub-URI (i.e. 'http://mysite.com/railsapp/').
The reason for this usually is that you used a
static URI for your image in the views. This means your 'img' source probably refers
to something like '/images/foo.jpg'. The leading slash means that it's an absolute URI:
you're telling the browser to always load 'http://mysite.com/images/foo.jpg' no
matter what. The problem is that the image is actually at
'http://mysite.com/railsapp/images/foo.jpg'. There are two ways to fix this.

The first way (not recommended) is to change your view templates to refer to
'images/foo.jpg'. This is a relative URI: note the lack of a leading slash). What
this does is making the path relative to the current URI. The problem is that if you
use restful URIs, then your images will probably break again when you add a level to
the URI.
For example, when you're at 'http://mysite.com/railsapp' the browser will look for
'http://mysite.com/railsapp/images/foo.jpg'. But when you're at
'http://mysite.com/railsapp/controller'. the browser will look for
'http://mysite.com/railsapp/controller/images/foo.jpg'.
So relative URIs usually don't work well with layout templates.

The second and highly recommended way is to always use Rails helper methods to
output tags for static assets. These helper methods automatically take care
of prepending the base URI that you've deployed the application to. For images
there is `image_tag`, for JavaScript there is `javascript_include_tag` and for
CSS there is `stylesheet_link_tag`. In the above example you would simply remove
the '<img>' HTML tag and replace it with inline Ruby like this:

---------------------------------------
<%= image_tag("foo.jpg") %>
---------------------------------------

This will generate the proper image tag to `$RAILS_ROOT/public/images/foo.jpg`
so that your images will always work no matter what sub-URI you've deployed to.

These helper methods are more valuable than you may think. For example they also
append a timestamp to the URI to better facilitate HTTP caching. For more information,
please refer to
link:http://api.rubyonrails.org/classes/ActionView/Helpers/AssetTagHelper.html[the Rails API docs].