Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Httpd Wiki" for change 
notification.

The "RunningMultipleApacheInstances" page has been changed by TimBannister:
http://wiki.apache.org/httpd/RunningMultipleApacheInstances?action=diff&rev1=7&rev2=8

Comment:
Changed “Apache” to “httpd” where this makes better sense, tidying, fixed some 
spelling errors

  = Running Multiple Apache Instances =
  
- This is a Recipe for configuring multiple apache instances. While writing 
this recipe I've noticed that there are other pages in this wiki that also deal 
with this subject, either tangently or in more direct ways:
+ This is a Recipe for configuring multiple https instances. While writing this 
recipe I've noticed that there are other pages in this wiki that also deal with 
this subject, either tangently or in more direct ways:
-  * [[ExtendingPrivilegeSeparation]] -- run several apache instances behind a 
reverse proxy, use high ports for the backend instances to improve security
+  * [[ExtendingPrivilegeSeparation]] -- run several httpd instances behind a 
reverse proxy, use high ports for the backend instances to improve security
-  * [[DifferentUserIDsUsingReverseProxy]] -- run several apache instances 
behind a reverse proxy, run each instance under an different unpriviliged user
+  * [[DifferentUserIDsUsingReverseProxy]] -- run several https instances 
behind a reverse proxy, run each instance under an different unprivileged user
  
  Some of the ideas in this recipe have already been advanced in these other 
wiki pages. However, the focus of this recipe is more on the operating system 
support (FreeBSD, Ubuntu) for this type of set up. The operating system usually 
provides facilities, such as rc(8) in BSD systems, or init(5) in Linux and 
other SysV systems, that help admins in launching processes after sucessfully 
booting the system. 
  
@@ -19, +19 @@

  
  === Or: why do we need to run multiple apache instances in one host? ===
  
- Although you can certainly have a single apache installation, running a 
single apache instance, and still have different virtual hosts that can be 
accessed separately, sometimes following this easy path can lead you to a heavy 
and bloated apache instance.
+ Although you can certainly have a single installation of Apache httpd, 
running a single instance, and still have different virtual hosts that can be 
accessed separately, sometimes following this easy path can lead you to a heavy 
and bloated web server.
   
- If your virtual hosts have different requirements (e.g. modperl for one 
virtual host, modpython for another, and maybe modphp for a third virtual 
host), then your apache instance is almost surely a RAM eater. Remember that 
apache will instantly spawn new child processes of the same instance as needed 
... if your perl web app is being frequently accessed, why spawn several 
instances of an httpd process that is also loaded with modpython, modphp and an 
assortment of other modules that, at least from the standpoint of the perl web 
app, are useless?
+ If your virtual hosts have different requirements (e.g. mod_perl for one 
virtual host, mod_python for another, and maybe mod_php for a third virtual 
host), then your apache instance is almost surely a RAM eater. Remember that 
httpd will instantly spawn new child processes of the same instance as needed 
... if your perl web app is being frequently accessed, why spawn several 
instances of an httpd process that is also loaded with mod_python, mod_php and 
an assortment of other modules that, at least from the standpoint of the perl 
web app, are useless?
  
- The answer to this, is simple: have separate lighter configurations for your 
modperl, modpython and modphp apps, listening on different ports (e.g. 81, 82, 
83), and have a reverse proxy apache instance with virtual hosts configured to 
pass requests to the corresponding apache instances. 
+ The answer to this, is simple: have separate lighter configurations for your 
mod_perl, mod_python and mod_php apps, listening on different ports (e.g. 81, 
82, 83), and have a reverse proxy instance of Apache with virtual hosts 
configured to pass requests to the corresponding apache instances. 
  
  In this recipe, I'll briefly explain how to do something along these lines: 
- Example: running different web applications listening in different ports, and 
using a reverse proxy that forwards incoming requests (e.g. blog.company.com, 
svn.company.com, www.company.com) to the corresponding apache instances.
+ Example: running different web applications listening in different ports, and 
using a reverse proxy that forwards incoming requests (e.g. blog.company.com, 
svn.company.com, www.company.com) to the corresponding https instances.
  
  == HowTo ==
  
  How do we configure apache so that we're able to start/stop/restart 
individual instances? 
  
- Because apache allows you to load modules dynamically, most of the time, a 
single installation of apache can serve the needs of multiple instances, and 
every instance may be configured to run different sets of modules. As an 
example, you can run a very lightweight proxy module, a modperl instance to run 
your perl web applications, a modpython instance with DAV to run subversion, a 
separate instance running PHP, etc, all from a single local installation of 
apache. Unless you have a requirement for a custom built apache instance (e.g. 
tweaking compile options differently for different instances), you don't really 
need to compile and install apache to different places (prefixes), as many 
online guides suggest. 
+ Because apache allows you to load modules dynamically, most of the time, a 
single installation of apache can serve the needs of multiple instances, and 
every instance may be configured to run different sets of modules. As an 
example, you can run a very lightweight proxy module, a mod_perl instance to 
run your perl web applications, a mod_python instance with DAV to run 
Subversion, a separate instance running PHP, etc, all from a single local 
installation of Apache. Unless you have a requirement for a custom built 
instance (e.g. tweaking compile options differently for different instances), 
you don't really need to compile and install httpd to different places 
(prefixes), as many online guides suggest. 
  
  In FreeBSD, a clever port maintainer had set up a number of rc scripts that 
simplify the task of launching all configured instances after booting the 
system. So if you're using FreeBSD as your server OS, then you're lucky, as the 
configuration is painless. 
  
@@ -51, +51 @@

   make clean && make install clean
   }}}
  
- This will fetch the sources for apache (currently 2.2.17), extract them, and 
run configure, make and finally install apache-22 on your system. As mentioned 
before, note that only one local installation is required to run multiple 
instances of apache. Also note that if you configure the port (''make config'') 
to enable mod_perl, mod_python (or any other dynamically loaded module that 
does not come with the standard apache distribution), then the FreeBSD ports 
system will 'Do The Right Thing(TM)' and will fetch, extract, configure, make 
and install the code for the corresponding modules. Easy, huh?
+ This will fetch the sources for Apache (currently 2.2.17), extract them, and 
run configure, make and finally install apache-22 on your system. As mentioned 
before, note that only one local installation is required to run multiple 
instances of apache. Also note that if you configure the port (''make config'') 
to enable mod_perl, mod_python (or any other dynamically loaded module that 
does not come with the standard apache distribution), then the FreeBSD ports 
system will 'Do The Right Thing(TM)' and will fetch, extract, configure, make 
and install the code for the corresponding modules. Easy, huh?
  
- Note also, that there are other alternative apache ports in FreeBSD that will 
install different flavours of apache:
+ Note also, that there are other alternative ports in FreeBSD that will 
install different flavours of Apache https:
  
   * www/apache22-event-mpm
   * www/apache22-peruser-mpm
@@ -64, +64 @@

  
  '''2. Create your apache configurations'''
  
- In FreeBSD, the configuration files for the recently installed port live in 
'/usr/local/etc/apache22'. There you will find a sample 'httpd.conf' file. This 
file may include directives found in other conf files located in a directory 
called 'extra', at the same location. Please read them, and familiarize 
yourself with their contents. If you've configured apache before, you'll find 
your way around easily.
+ In FreeBSD, the configuration files for the recently installed port live in 
'/usr/local/etc/apache22'. There you will find a sample 'httpd.conf' file. This 
file may include directives found in other conf files located in a directory 
called 'extra', at the same location. Please read them, and familiarize 
yourself with their contents. If you've configured Apache before, you'll find 
your way around easily.
  
  Now, let's create a number of separate apache configurations. Essentially 
this means creating different httpd.conf files, for example:
  
@@ -101, +101 @@

   LoadModule php5_module                        libexec/apache22/libphp5.so
  }}}
  
-  Now, we also need to configure the virtual hosts in the proxy instance, so 
that whenever a request comes for the subversion DAV server, it is passed onto 
your 'python-dav' apache, whereas requests for your wordpress blog are passed 
to your 'php' apache instance. Let's edit 'httpd-proxy.conf' again:
+  Now, we also need to configure the virtual hosts in the proxy instance, so 
that whenever a request comes for the Subversion DAV server, it is passed onto 
your 'python-dav' httpd instance, whereas requests for your wordpress blog are 
passed to your 'php' instance. Let's edit 'httpd-proxy.conf' again:
  
   {{{
   # httpd-proxy.conf
@@ -124, +124 @@

   # you might need to use the "ProxyPreserveHost On" directive, depending on 
your configuration
   }}}
  
- So we're finished with the configuration, and now we need to launch all the 
apache instances, and test that everything is working as expected. Of course 
you can do this using 'apachectl', e.g.
+ So we're finished with the configuration, and now we need to launch all the 
instances of httpd, and test that everything is working as expected. Of course 
you can do this using 'apachectl', e.g.
  
   {{{
   /usr/local/sbin/apachectl -f /usr/local/etc/apache22/proxy-httpd.conf 
configtest
@@ -163, +163 @@

  apache22_php_enable="YES"
  }}}
  
- When these ''profiles'' are configured in /etc/rc.conf, and ''enabled'', they 
will be started after successfully booting the system. If you want to declare a 
profile but you only want to start the corresponding apache instance manually, 
you can just edit '/etc/rc.conf' and say, e.g. :
+ When these ''profiles'' are configured in /etc/rc.conf, and ''enabled'', they 
will be started after successfully booting the system. If you want to declare a 
profile but you only want to start the corresponding httpd instance manually, 
you can just edit '/etc/rc.conf' and say, e.g. :
  
   {{{
   # the apache php instance
@@ -171, +171 @@

   apache22_php_enable="NO"
   }}}
  
- Later, you can start/stop any apache instance manually using just the profile 
name (proxy, perl, python, php), like this:
+ Later, you can start/stop any httpd instance manually using just the profile 
name (proxy, perl, python, php), like this:
  
   {{{
   /usr/local/etc/rc.d/apache22 start php
@@ -196, +196 @@

  
  '''2. Create your apache configurations'''
  
- In Ubuntu, the configuration files for your recently installed apache are 
under '/etc/apache2'.
+ In Ubuntu, the configuration files for your recently installed webserver are 
under '/etc/apache2'.
  [writing in progress ...]
  
  There is some Debian/Ubuntu specific information in 
/usr/share/doc/apache2/README.Debian.gz after installation.
@@ -204, +204 @@

  
  '''3. Configure the system to launch the apache instances after boot'''
  
- I'm not sure this will be similar (and painless) as in the case of FreeBSD 
(see section on rc.conf above). The apache rc scripts installed with the apache 
port in FreeBSD have been aware of the possibility of different profiles for 
years now. 
- 
- Recently, the ubuntu/debian init scripts (e.g. /etc/init.d/apache2) have been 
updated to support multiple instances of apache (e.g. multiple configurations, 
named /etc/apache2-$SUFFIX). Depending on the release of debian/ubuntu you're 
using you may be lucky ... or not. 
+ The Ubuntu/Debian init scripts (e.g. /etc/init.d/apache2) have been updated 
to support multiple instances of (e.g. multiple configurations, named 
/etc/apache2-$SUFFIX).
- 
- The feature appeared in Debian in version 2.2.14-6 in Feb 2010: 
http://lists.alioth.debian.org/pipermail/pkg-apache-commits/2010-February/000295.html
- 
- In Ubuntu, the apache2 packages in Maverick (10.10) contain these patches: 
- 
http://changelogs.ubuntu.com/changelogs/pool/main/a/apache2/apache2_2.2.16-1ubuntu3.1/changelog
- 
- However the Lucid (10.04, Long Term Support Release) apache2 apparently do 
not:
- 
http://changelogs.ubuntu.com/changelogs/pool/main/a/apache2/apache2_2.2.14-5ubuntu8.4/changelog
  
  Documentation can be found in /usr/share/doc/apache2/README.multiple-instances
  

---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscr...@httpd.apache.org
For additional commands, e-mail: docs-h...@httpd.apache.org

Reply via email to