passenger 5.0.14 → 5.0.15

data/doc/users_guide_snippets/appendix_c_spawning_methods.txt

@@ -1,242 +1,36 @@
 [[spawning_methods_explained]]
 == Appendix C: Spawning methods explained
 
-At its core, Phusion Passenger is an HTTP proxy and process manager. It spawns
-application processes and forwards incoming HTTP request to one of them.
-
-While this may sound simple, there's not just one way to spawn application processes.
-Let's go over the different spawning methods. For simplicity's sake, let's
-assume that we're only talking about Ruby on Rails applications.
+This documentation has moved. Please visit https://www.phusionpassenger.com/library/indepth/spawn_methods/
 
 === The most straightforward and traditional way: direct spawning
 
-Phusion Passenger could create a new Ruby process, which will then load the
-Rails application along with the entire Rails framework. This process will then
-enter an request handling main loop.
-
-This is the most straightforward way to spawn processes, and each process contains
-a full copy of the Rails application and the Rails framework in memory.
+This documentation has moved. Please visit https://www.phusionpassenger.com/library/indepth/spawn_methods/
 
 === The smart spawning method
 
-NOTE: Smart spawning is only supported for Ruby applications. It's not supported for other languages.
-
-While direct spawning works well, it's not as efficient as it could be
-because each process has its own private copy of the Rails application
-as well as the Rails framework. This wastes memory as well as startup time.
-
-image:images/direct_spawning.png[Application processes and direct spawning] +
-'Figure: Application processes and direct spawning. Each process has its
-own private copy of the application code and Rails framework code.'
-
-It is possible to make the different processes share the memory occupied
-by application and Rails framework code, by utilizing so-called
-copy-on-write semantics of the virtual memory system on modern operating
-systems. As a side effect, the startup time is also reduced. This is technique
-is exploited by Phusion Passenger's 'smart' spawn method.
-
-The 'smart' spawn method is similar to Unicorn's `preload_app true` feature.
+This documentation has moved. Please visit https://www.phusionpassenger.com/library/indepth/spawn_methods/
 
 ==== How it works
 
-When the 'smart' spawn method is being used, Phusion Passenger will first
-create a so-called 'preloader' process. This process loads the
-entire Rails application along with the Rails framework, by evaluating
-`config.ru`. Then, whenever Phusion Passenger needs a new application process,
-it will instruct the preloader to create one. The preloader then then spawns
-a child process, which is an exact virtual copy of itself. This child process
-therefore already has the application code and the Rails framework code in memory.
-
-Creating a process like this is very fast, about 10 times faster than loading the
-Rails application/framework from scratch. On top of that, the OS also applies an
-optimization called 'copy-on-write'. This means that all memory that the child
-process hasn't modified, is shared with the parent process.
-
-image:images/smart_spawning.png[] +
-'Figure: Application processes and the smart spawn method. All processes,
-as well as the preloader, share the same application code and Rails
-framework code.'
-
-However, Ruby can only leverage this copy-on-write optimization if its garbage
-collector is friendly. This is only the case starting from Ruby 2.0.0. Earlier
-versions cannot leverage copy-on-write optimizations.
-
-Note that preloader processes have an idle timeout just like application processes.
-If a preloader hasn't been instructed to do anything for a while, it will be shutdown
-in order to conserve memory. This idle timeout is configurable.
+This documentation has moved. Please visit https://www.phusionpassenger.com/library/indepth/spawn_methods/
 
 ==== Summary of benefits
 
-Suppose that Phusion Passenger needs a process for an application
-that uses Rails 4.1.0.
-
-If the 'smart' spawning method is used, and a preloader for this application is
-already running, then process creation time is about 10 times faster than direct
-spawning. This process will also share application and Rails framework code memory
-with the preloader, as well as with other processes that have been spawned by the
-same preloader.
-
-In practice, the smart spawning method could mean a memory saving of about 33%,
-assuming that your Ruby interpreter is copy-on-write friendly.
-
-Of course, smart spawning is not without caveats. But if you understand the
-caveats you can easily reap the benefits of smart spawning.
+This documentation has moved. Please visit https://www.phusionpassenger.com/library/indepth/spawn_methods/
 
 === Smart spawning caveat #1: unintentional file descriptor sharing
 
-Because application processes are created by forking from a preloader process,
-it will share all file descriptors that are opened by the
-preloader process. (This is part of the semantics of the Unix
-'fork()' system call. You might want to Google it if you're not familiar with
-it.) A file descriptor is a handle which can be an opened file, an opened socket
-connection, a pipe, etc. If different application processes write to such a file
-descriptor at the same time, then their write calls will be interleaved, which
-may potentially cause problems.
-
-The problem commonly involves socket connections that are unintentionally being
-shared. You can fix it by closing and reestablishing the connection when Phusion
-Passenger is creating a new application process. Phusion Passenger provides the API
-call `PhusionPassenger.on_event(:starting_worker_process)` to do so. So you
-could insert the following code in your 'config.ru':
-
-[source, ruby]
------------------------------------------
-if defined?(PhusionPassenger)
-    PhusionPassenger.on_event(:starting_worker_process) do |forked|
-        if forked
-            # We're in smart spawning mode.
-            ... code to reestablish socket connections here ...
-        else
-            # We're in direct spawning mode. We don't need to do anything.
-        end
-    end
-end
------------------------------------------
-
-Note that Phusion Passenger automatically reestablishes the connection to the
-database upon creating a new application process, which is why you normally do not
-encounter any database issues when using smart spawning mode.
+This documentation has moved. Please visit https://www.phusionpassenger.com/library/indepth/spawn_methods/
 
 ==== Example 1: Memcached connection sharing (harmful)
 
-Suppose we have a Rails application that connects to a Memcached server in
-'environment.rb'. This causes the preloader to have a socket connection
-(file descriptor) to the Memcached server, as shown in the following figure:
-
- +--------------------+
- | Preloader          |-----------[Memcached server]
- +--------------------+
-
-Phusion Passenger then proceeds with creating a new Rails application process, which
-is to process incoming HTTP requests. The result will look like this:
-
- +--------------------+
- | Preloader          |------+----[Memcached server]
- +--------------------+      |
-                             |
- +--------------------+      |
- | App process 1      |-----/
- +--------------------+
-
-Since a 'fork()' makes a (virtual) complete copy of a process, all its file
-descriptors will be copied as well. What we see here is that Preloader
-and App process 1 both share the same connection to Memcached.
-
-Now supposed that your site gets a sudden large surge of traffic, and Phusion Passenger needs to
-spawn another process. It does so by forking Preloader. The result is now as follows:
-
- +--------------------+
- | Preloader          |------+----[Memcached server]
- +--------------------+      |
-                             |
- +--------------------+      |
- | App process 1      |-----/|
- +--------------------+      |
-                             |
- +--------------------+      |
- | App process 2      |-----/
- +--------------------+
-
-As you can see, App process 1 and App process 2 have the same Memcached
-connection.
-
-Suppose that users Joe and Jane visit your website at the same time. Joe's
-request is handled by App process 1, and Jane's request is handled by App
-process 2. Both application processes want to fetch something from Memcached. Suppose
-that in order to do that, both handlers need to send a "FETCH" command to Memcached.
-
-But suppose that, after App process 1 having only sent "FE", a context switch
-occurs, and App process 2 starts sending a "FETCH" command to Memcached as
-well. If App process 2 succeeds in sending only one bye, 'F', then Memcached
-will receive a command which begins with "FEF", a command that it does not
-recognize. In other words: the data from both handlers get interleaved. And thus
-Memcached is forced to handle this as an error.
-
-This problem can be solved by reestablishing the connection to Memcached after forking:
-
- +--------------------+
- | Preloader          |------+----[Memcached server]
- +--------------------+      |                   |
-                             |                   |
- +--------------------+      |                   |
- | App process 1      |-----/|                   |
- +--------------------+      |                   |  <--- created this
-                             X                   |       new
-                                                 |       connection
-                             X <-- closed this   |
- +--------------------+      |     old           |
- | App process 2      |-----/      connection    |
- +--------------------+                          |
-           |                                     |
-           +-------------------------------------+
-
-App process 2 now has its own, separate communication channel with Memcached.
-The code in 'environment.rb' looks like this:
-
-[source, ruby]
------------------------------------------
-if defined?(PhusionPassenger)
-    PhusionPassenger.on_event(:starting_worker_process) do |forked|
-        if forked
-            # We're in smart spawning mode.
-            reestablish_connection_to_memcached
-        else
-            # We're in direct spawning mode. We don't need to do anything.
-        end
-    end
-end
------------------------------------------
+This documentation has moved. Please visit https://www.phusionpassenger.com/library/indepth/spawn_methods/
 
 ==== Example 2: Log file sharing (not harmful)
 
-There are also cases in which unintentional file descriptor sharing is not harmful.
-One such case is log file file descriptor sharing. Even if two processes write
-to the log file at the same time, the worst thing that can happen is that the
-data in the log file is interleaved.
-
-To guarantee that the data written to the log file is never interleaved, you
-must synchronize write access via an inter-process synchronization mechanism,
-such as file locks. Reopening the log file, like you would have done in the
-Memcached example, doesn't help.
+This documentation has moved. Please visit https://www.phusionpassenger.com/library/indepth/spawn_methods/
 
 === Smart spawning caveat #2: the need to revive threads
 
-Another part of the 'fork()' system call's semantics is the fact that threads
-disappear after a fork call. So if you've created any threads in environment.rb,
-then those threads will no longer be running in newly created application process.
-You need to revive them when a new process is created. Use the
-`:starting_worker_process` event that Phusion Passenger provides, like this:
-
-[source, ruby]
------------------------------------------
-if defined?(PhusionPassenger)
-    PhusionPassenger.on_event(:starting_worker_process) do |forked|
-        if forked
-            # We're in smart spawning mode.
-            ... code to revive threads here ...
-        else
-            # We're in direct spawning mode. We don't need to do anything.
-        end
-    end
-end
------------------------------------------
+This documentation has moved. Please visit https://www.phusionpassenger.com/library/indepth/spawn_methods/

data/doc/users_guide_snippets/environment_variables.txt

@@ -1,276 +1,44 @@
-Environment variables are named values that affect how the system works. For example they tell the system where to look for commands (the `PATH` variable) or where to look for libraries (`LD_LIBRARY_PATH`). Their names are often in all-uppercase. Sometimes people refer to an environment variable with a dollar sign `$` in front, but that's the same thing: when people say "the $PATH environment variable" they mean "the PATH environment variable". This is because the dollar sign `$` is a shell syntax for refering to an environment variable, as you will learn later.
-
-Environment variables are set on a **per-process** basis, but they are **inherited** by child processes. This means that if you set environment variables in process A, another already running process B will not see these new environment variables. But if A spawns a child process C, then C will have all environment variables that A had. If you once again change the environment variables in A, then C will not see the changes.
-
-The per-process nature of environment variables some implications. When you set environment variables in your `bashrc` or other bash startup files...
-
- * ...only newly spawned bash shells see them.
- * ...the web server usually does not see them, because the web server tends to be started from init scripts, not from bash.
- * ...cron jobs do not see them, because cron jobs' environment variables are entirely dictated by their crontabs.
-
-NOTE: Because this chapter is meant for beginners, it assumes that the reader uses the bash shell. This chapter does not describe instructions for zsh, csh or other shells. We assume that users of other shells are familiar with the Bourne shell syntax, and know how to apply the instructions in this chapter in their shells' native syntaxes.
+This documentation has moved. Please visit https://www.phusionpassenger.com/library/indepth/environment_variables.html
 
 === Working with environment variables
 
-You can see all environment variables in your shell by running the following command:
-
-[source,sh]
----------------------------------
-env
----------------------------------
-
-You can set an evironment variable with the syntax `export <NAME>=<VALUE>`. For example, to set the `APXS2` variable to the value `/usr/sbin/apxs2`:
-
-[source,sh]
----------------------------------
-export APXS2=/usr/sbin/apxs2
----------------------------------
-
-Any process that you run from your shell from that point on will have said environment variable:
-
-[source,sh]
----------------------------------
-export APXS2=/usr/sbin/apxs2
-ruby -e 'p ENV["APXS2"]'
-# => "/usr/sbin/apxs2"
----------------------------------
-
-.The "export" keyword is important
-[NOTE]
-===================================================
-You **must** set the `export` keyword. If you omit the `export` keyword then the environment variable will not be visible to other processes:
-
-[source,sh]
----------------------------------
-APXS2=/usr/sbin/apxs2
-ruby -e 'p ENV["APXS2"]'
-# => nil
----------------------------------
-===================================================
-
-You can reference an environment variable in your shell by typing the `$` sign followed by the environment variable's name. For example, to see the value of the `PATH` variable:
-
-[source,sh]
----------------------------------
-echo $PATH
----------------------------------
-
-You can also use this trick to extend the value of an environment variable:
-
-[source,sh]
----------------------------------
-export PATH=/usr/bin
-
-# Prepends '/opt/local/bin', so that it becomes /opt/local/bin:/usr/bin
-export PATH=/opt/local/bin:$PATH
-# Appends '/usr/local/bin', so that it becomes /opt/local/bin:/usr/bin:/usr/local/bin
-export PATH=$PATH:/usr/local/bin
----------------------------------
+This documentation has moved. Please visit https://www.phusionpassenger.com/library/indepth/environment_variables.html#working-with-environment-variables
 
 [[the_path_env_var]]
 === The PATH environment variable
 
-The `PATH` environment variable dictates where the system looks for command. It is a colon-separated list of directories. If you get a "command not found" error while you know that the command is installed, then setting `PATH` will help. For example suppose that the command `frobnicator` is in `/opt/local/bin`:
-
-[source,sh]
-----------------------
-user@localhost bash$ frobnicator
-bash: frobnicator: command not found
-----------------------
-
-We verify that `/opt/local/bin` is not in `PATH`:
-
-[source,sh]
-----------------------
-user@localhost bash$ echo $PATH
-/bin:/usr/bin:/usr/local/bin
-----------------------
-
-We can run `frobnicator` through it's full path...
-
-[source,sh]
-----------------------
-user@localhost bash$ /opt/local/bin/frobnicator
-# => success!
-----------------------
-
-...or we can add `/opt/local/bin` to `PATH`.
-
-[source,sh]
-----------------------
-user@localhost bash$ export PATH=$PATH:/opt/local/bin
-user@localhost bash$ frobnicator
-# => success!
-----------------------
+This documentation has moved. Please visit https://www.phusionpassenger.com/library/indepth/environment_variables.html#the-path-environment-variable
 
 ==== Adding Phusion Passenger's administration tools to PATH
 
-If you get a "command not found" error when invoking one of the Phusion Passenger administration tools (e.g. `passenger-status` or `passenger-memory-stats` then that means the tools are not in `PATH`, so you need to add them.
-
- * If you <<rubygems_generic_install,installed Phusion Passenger with RubyGems>>, then the tools are in your RubyGems executable path. You can view the gem path using the command `gem env`:
-+
-------------------------------
-$ gem env
-RubyGems Environment:
-  - RUBYGEMS VERSION: 1.8.15
-  - RUBY VERSION: 1.8.7 (2011-12-28 patchlevel 357) [i686-darwin10.8.0]
-  - INSTALLATION DIRECTORY: /opt/ruby-enterprise-1.8.7-2010.01/lib/ruby/gems/1.8
-  - RUBY EXECUTABLE: /opt/ruby-enterprise-1.8.7-2010.01/bin/ruby
-  - EXECUTABLE DIRECTORY: /opt/ruby-enterprise-1.8.7-2010.01/bin    <--------- !!
-  - RUBYGEMS PLATFORMS:
-    - ruby
-    - x86-darwin-10
-  - GEM PATHS:
-     - /opt/ruby-enterprise-1.8.7-2010.01/lib/ruby/gems/1.8
-     - /Users/hongli/.gem/ruby/1.8
-  - GEM CONFIGURATION:
-     - :update_sources => true
-     - :verbose => true
-     - :benchmark => false
-     - :backtrace => false
-     - :bulk_threshold => 1000
-     - "gem" => "--no-ri --no-rdoc"
-  - REMOTE SOURCES:
-     - http://rubygems.org/
-------------------------------
-+
-As you can see, the RubyGems executable path in the example happens to be `/opt/ruby-enterprise-1.8.7-2010.01/bin`. So that directory must be added to `PATH`.
-
- * If you <<tarball_generic_install,installed Phusion Passenger using the tarball>>, then the tools are in the `bin` subdirectory of the Phusion Passenger tarball directory that you extracted. For example, if you extracted `passenger-4.9.0.tar.gz` inside `/opt`, then the tools are located in `/opt/passenger-4.0.9/bin`. In that case, you need to add `/opt/passenger-4.0.9/bin` to your `PATH`.
- * If you installed Phusion Passenger using native OS packages, then some Phusion Passenger administration tools are in `/usr/bin`, while others are in `/usr/sbin`. If you are not logged in as root, then `/usr/sbin` may not be in `PATH`, which would explain why you get a "command not found" when trying to invoke some of the tools. You should `/usr/sbin` to `PATH`.
- * If you are unsure where your Phusion Passenger directory is then you can use the `find` command to look them up. Go to the root directory and invoke `find` with `sudo`:
-+
---------------------------------
-$ cd /
-$ sudo find . -name passenger-status
-/usr/local/passenger/bin/passenger-status
---------------------------------
-+
-In this example, the administration tools happen to be in `/usr/local/passenger/bin`, so you must add that to `PATH`.
-
-NOTE: You may still get a "command not found" when invoking the tools through sudo, even after you've added the relevant directory to `PATH`. Please read <<env_vars_and_sudo,Environment variables and sudo>> to learn more.
+This documentation has moved. Please visit https://www.phusionpassenger.com/library/indepth/environment_variables.html#adding-passenger-s-administration-tools-to-path
 
 === Making environment variables permanent
 
-When you exit your shell, the evironment variable changes are lost. There is no standard method to set environment variables system-wide, so you have to set them in different configuration files for different services.
+This documentation has moved. Please visit https://www.phusionpassenger.com/library/indepth/environment_variables.html#making-environment-variables-permanent
 
 ==== bash
 
-To make environment variables permanent for future bash sessions **for the current user**, add them to your `~/.bashrc`:
-
-[source,sh]
----------------------------------
-echo 'export FOO=bar' >> ~/.bashrc
-echo 'export PATH=/usr/local/bin:$PATH' >> ~/.bashrc
----------------------------------
-
-To make them permanent for future bash sessions **for all users**, add them to `/etc/bashrc`.
-
-NOTE: Depending on the system, the bashrc file may have a different filename. On Debian and Ubuntu, it's `/etc/bash.bashrc`.
-NOTE: Make sure your `~/.bashrc` is actually included by your `~/.profile`, which might not be the case if you created the user with `useradd` instead of `adduser` for example
+This documentation has moved. Please visit https://www.phusionpassenger.com/library/indepth/environment_variables.html#bash
 
 ==== Apache
 
-NOTE: This subsection describes how to set environment variables on Apache itself, not on apps served through Phusion Passenger for Apache. The environment variables you set here will be passed to all apps, but you cannot customize them on a per-app basis. See also <<env_vars_passenger_apps,Setting environment variables on Phusion Passenger-served apps>>.
-
-On Debian and Ubuntu, with an Apache installed through apt, Apache environment variables are defined in the file `/etc/apache2/envvars`. This is a shell script so environment variables must be specified with the shell syntax.
-
-On Red Hat, Fedora, CentOS and ScientificLinux, with an Apache installed through YUM, Apache environment variables are defined in `/etc/sysconfig/httpd`.
-
-On OS X they are defined in `/System/Library/LaunchDaemons/org.apache.httpd.plist`, as explained link:http://stackoverflow.com/questions/6833939/path-environment-variable-for-apache2-on-mac[here on Stack Overflow].
-
-On other systems, or if you did not install Apache through the system's package manager, the configuration file for environment variables is specific to the vendor that supplied Apache. There may not even be such a configuration file. You should contact the vendor for support.
+This documentation has moved. Please visit https://www.phusionpassenger.com/library/indepth/environment_variables.html#apache
 
 ==== Nginx
 
-NOTE: This subsection describes how to set environment variables on Nginx itself, not on apps served through Phusion Passenger for Nginx. The environment variables you set here will be passed to all apps, but you cannot customize them on a per-app basis. See also <<env_vars_passenger_apps,Setting environment variables on Phusion Passenger-served apps>>.
-
-If you installed Nginx through <<install_on_debian_ubuntu,the Debian or Ubuntu packages>>, then you can define environment variables in `/etc/default/nginx`. This is a shell script so you must use the `export FOO=bar` syntax.
-
-Otherwise, environment variables are best set through the script which starts Nginx. For example, if you installed Nginx from source and you used
-ifdef::apache[]
-the Nginx init script described in the link:Users%20guide%20Nginx.html[Phusion Passenger Users Guide, Nginx version],
-endif::apache[]
-ifdef::nginx[]
-<<nginx_init_script,the Nginx init script described earlier in this manual>>,
-endif::nginx[]
-then you should edit that script to define the environment variables. Those init scripts are regular shell scripts, so use the `export FOO=bar` syntax. Just make sure your set your environment variables before the script starts Nginx.
-
-NOTE: Setting environment variables on Nginx has no effect on the <<flying_passenger,Flying Passenger daemon>> because the daemon is started seperately. You should set the environment variables in the shell right before starting the daemon.
+This documentation has moved. Please visit https://www.phusionpassenger.com/library/indepth/environment_variables.html#nginx
 
 ==== cron
 
-To make environment variables permanent for cron jobs, add those variables to the relevant crontab. But note that inside crontabs you cannot refer to existing environment variables with the `$` syntax because crontabs are not shell scripts. You have to specify the entire value.
-
-.What to put in "crontab -e"
--------------------------
-# Environment variable definitions
-FOO=bar
-APXS2=/usr/sbin/apxs2
-
-# **WRONG!** You cannot refer to existing variables with the `$` syntax!
-PATH=/usr/bin:$PATH
-# **WRONG!** You cannot use the 'export' keyword!
-export PATH=/usr/bin:/usr/local/bin
-# Correct:
-PATH=/usr/bin:/usr/local/bin
-
-# Jobs:
-# m h  dom mon dow   command
-  * *  *   *   *     frobnicator
--------------------------
+This documentation has moved. Please visit https://www.phusionpassenger.com/library/indepth/environment_variables.html#cron
 
 [[env_vars_passenger_apps]]
 ==== Phusion Passenger-served apps
 
-You can pass environment variables to Phusion Passenger-served apps through various methods:
-
- * When running Apache, use the `PassEnv` and `SetEnv` directives of link:http://httpd.apache.org/docs/2.4/mod/mod_env.html[mod_env]. This is supported starting from Phusion Passenger 4.0.
- * When running Nginx, use the <<PassengerEnvVar,passenger_env_var>> directive.
- * Through your `bashrc`. Starting from version 4.0, Phusion Passenger 4.0 spawns applications through bash and inherit all bash environment variables. Phusion Passenger Standalone tends to be started from the shell and thus inherits all environment variables set by the shell.
- * Through Apache and Nginx, as described earlier in this chapter. Any environment variables that you set on Apache and Nginx itself are inherited by Phusion Passenger, and thus by Phusion Passenger-served apps as well.
- * Through the application itself. Most programming languages provide APIs for setting environment variables. For example in Ruby you can write:
-+
-[source,ruby]
--------------------
-ENV['FOO'] = 'bar'
--------------------
-+
-In Python you can write:
-+
-[source,python]
--------------------
-import os
-os.environ['FOO'] = 'bar'
--------------------
+This documentation has moved. Please visit https://www.phusionpassenger.com/library/indepth/environment_variables.html#passenger-served-apps
 
 [[env_vars_and_sudo]]
 === Environment variables and sudo
 
-NOTE: RVM users should always use the `rvmsudo` command instead of `sudo`. However all information in this section apply to `rvmsudo` as well.
-
-The `sudo` command resets all environment variables before running the specified command, for security reasons. So if you set environment variables before running `sudo passenger-install-xxx-module`, `sudo passenger-status` or any other commands, then the environment variables are not correctly passed to the command. You can solve this by running sudo with `-E` (preserve environment variables):
-
-[source,sh]
--------------------------
-user@localhost bash$ export APXS2=/usr/sbin/apxs2
-user@localhost bash$ sudo -E passenger-install-apache2-module
--------------------------
-
-Alternatively, you can obtain a root prompt with sudo first, and *then* set the environment variables, before running any further commands:
-
--------------------------
-user@localhost bash$ sudo -s
-Password: ...
-root@localhost bash# export APXS2=/usr/sbin/apxs2
-root@localhost bash# passenger-install-apache2-module
--------------------------
-
-Note that for security reasons, `sudo` **always resets the `PATH` environment variable**, even if you pass `-E`! You can get around this problem by obtaining a root prompt first, and then set the environment variables:
-
--------------------------
-user@localhost bash$ sudo -s
-Password: ...
-root@localhost bash# export PATH=$PATH:/opt/myruby/bin
-root@localhost bash# passenger-install-apache2-module
--------------------------
+This documentation has moved. Please visit https://www.phusionpassenger.com/library/indepth/environment_variables.html#environment-variables-and-sudo