2006-12-20 18:01:15 +01:00
|
|
|
README.SuSE for Apache 2
|
|
|
|
|
|
|
|
|
|
|
|
For The Impatient
|
|
|
|
=================
|
|
|
|
|
|
|
|
o There are several MPM packages (MPM = multiprocessing module, which implements
|
|
|
|
the threads/processes model). The MPM packages contain the actual apache binary.
|
|
|
|
At least one MPM package must be installed.
|
|
|
|
|
|
|
|
o The apache v1 and v2 packages can be installed and run side by side :)
|
|
|
|
|
|
|
|
o Some commands have a "2" suffix, and are thus easily confused with Apache 1
|
|
|
|
commands -- if you have an old apache (1.3) installation around.
|
|
|
|
|
|
|
|
o Edit /etc/sysconfig/apache2 to configure the list of modules to load, and other things.
|
|
|
|
It is no longer required to run SuSEconfig after such changes. (In fact, the
|
|
|
|
SuSEconfig.apache2 does no longer exist.)
|
|
|
|
|
|
|
|
|
|
|
|
o For building apache modules, there are 4 apxs commands (all come with the
|
|
|
|
apache2-devel package):
|
|
|
|
apxs2 builds a common module for all MPMs and installs to /usr/lib/apache2
|
|
|
|
apxs2-prefork builds for prefork and installs to /usr/lib/apache2-prefork
|
|
|
|
apxs2-worker builds for worker and installs to /usr/lib/apache2-worker
|
|
|
|
|
|
|
|
If you build apache modules, the configure script might not find apxs, and
|
|
|
|
you'll need an option like --with-apxs=apxs2[-worker, ...], or of course you can set
|
|
|
|
a symlink to apxs2.
|
|
|
|
|
|
|
|
o The Apache Runtime (APR) is in the "libapr0" package (this package was named "apr"
|
|
|
|
in the past (8.1))
|
|
|
|
|
|
|
|
|
|
|
|
Choosing the right MPM for your application
|
|
|
|
===========================================
|
|
|
|
|
|
|
|
apache2-prefork is implemented with a prefork regime, while
|
|
|
|
apache2-worker uses a hybrid threaded/preforked model.
|
|
|
|
|
|
|
|
Which one to use? The short answer is:
|
|
|
|
- if in doubt, simply use prefork
|
|
|
|
- use prefork if you use mod_php4
|
|
|
|
- use worker if you need maximal performance with (possibly) less resources
|
|
|
|
(smaller memory footprint of threade compared to the same number as processes)
|
|
|
|
|
|
|
|
The following nice article has a more in depth answer:
|
|
|
|
http://www.onlamp.com/pub/a/apache/2004/06/17/apacheckbk.html
|
|
|
|
|
|
|
|
See
|
2014-09-26 17:16:44 +02:00
|
|
|
http:///httpd.apache.org/docs/2.4/mpm.html and
|
|
|
|
http:///httpd.apache.org/docs/2.4/misc/perf-tuning.html#compiletime
|
2006-12-20 18:01:15 +01:00
|
|
|
for more technical details.
|
|
|
|
|
|
|
|
In general, using a threaded MPM (worker) requires that all libraries that are
|
|
|
|
loaded into apache (and libraries loaded by them in turn) be threadsafe as well.
|
|
|
|
See
|
2014-09-26 17:16:44 +02:00
|
|
|
http:///httpd.apache.org/docs/2.4/developer/thread_safety.html for a status on
|
2006-12-20 18:01:15 +01:00
|
|
|
some libraries.
|
|
|
|
|
|
|
|
|
|
|
|
Upgrading from apache 1.3
|
|
|
|
=========================
|
|
|
|
|
|
|
|
For a smooth transition from apache 1.3, apache 2 is installable alongside apache
|
|
|
|
1.3. There are a few modules for apache 1 that have not been ported or enough
|
|
|
|
tested for apache 2, but most important modules are available by now.
|
|
|
|
|
|
|
|
The mechanism of specifying modules to load into the server has been cleaned up
|
|
|
|
so a reasonable default set of modules is loaded. (It is not useful to load all
|
|
|
|
available modules by default, it would make the server quite big and slow. This
|
|
|
|
is important given as the number of modules in the apache base distribution is
|
|
|
|
rising and rising (about 50 at this time).
|
|
|
|
|
|
|
|
In previous apache packages (1.3), modules were activated by setting a
|
|
|
|
APACHE_MOD_XYZ variable to "yes" and running SuSEconfig.
|
|
|
|
Nowadays, modules are activated by adding them to a the APACHE_MODULES
|
|
|
|
variable in /etc/sysconfig/apache2, and simply restarting apache.
|
|
|
|
|
|
|
|
|
|
|
|
Building modules for apache 2
|
|
|
|
=============================
|
|
|
|
|
|
|
|
Therefore, the different MPMs will be needed and a mechanism to build
|
|
|
|
the modules spesific to them. This can now be done with the apxs2,
|
|
|
|
apxs2-worker or apxs2-prefork script.
|
|
|
|
|
|
|
|
For a module's configure script, you would typically use
|
|
|
|
--which-apxs=/usr/sbin/apxs2-prefork
|
|
|
|
|
|
|
|
In RPM spec files, you can use
|
|
|
|
%define apxs apxs2
|
|
|
|
%define apache_libexecdir %(%{apxs} -q libexecdir)
|
|
|
|
to build modules, or use apxs2-prefork (for instance) to build a module
|
|
|
|
specifically for the prefork MPM.
|
|
|
|
|
|
|
|
To further the example, apxs2-prefork will install a module below
|
|
|
|
/usr/lib/apache2-prefork/, while "apxs2" will install it below
|
|
|
|
/usr/lib/apache2/.
|
|
|
|
|
|
|
|
-a adds the module to APACHE_MODULES in /etc/sysconfig/apache2, which in turn
|
|
|
|
takes care of loading the module.
|
|
|
|
|
|
|
|
Thus, usually you will only have to call
|
|
|
|
apxs2 -cia my_module.c
|
|
|
|
and all is fine.
|
|
|
|
|
|
|
|
|
|
|
|
--
|
|
|
|
Suggestions or bug reports (via http://bugzilla.novell.com/) are most
|
|
|
|
welcome.
|
|
|
|
|
|
|
|
|
|
|
|
Mar 14 2005, Peter Poeml
|