PC World 2004 May

home *** CD-ROM | disk | FTP | other *** search

/ PC World 2004 May / PCWorld_2004-05_cd.bin / komunikace / apache / apache_2.0.48-win32-x86-no_ssl.msi / Data.Cab / F252227_install.xml < prev next >

Wrap

Extensible Markup Language | 2003-09-01 | 25.0 KB | 644 lines

<?xml version='1.0' encoding='UTF-8' ?> <!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd"> <?xml-stylesheet type="text/xsl" href="./style/manual.en.xsl"?> <manualpage metafile="install.xml.meta"> <title>Compiling and Installing</title> <summary> This document covers compilation and installation of Apache on Unix and Unix-like systems only. For compiling and installation on Windows, see <a href="platform/windows.html">Using Apache with Microsoft Windows</a>. For other platforms, see the <a href="platform/">platform</a> documentation. Apache 2.0's configuration and installation environment has changed completely from Apache 1.3. Apache 1.3 used a custom set of scripts to achieve easy installation. Apache 2.0 now uses <code>libtool</code> and <code>autoconf</code> to create an environment that looks like many other Open Source projects. If you are upgrading from one minor version to the next (for example, 2.0.50 to 2.0.51), please skip down to the <a href="#upgrading">upgrading</a> section. </summary> <seealso><a href="invoking.html">Starting Apache</a></seealso> <seealso><a href="stopping.html">Stopping and Restarting</a></seealso> <section id="overview"><title>Overview for the impatient</title> <table> <columnspec><column width=".13"/><column width=".80"/></columnspec> <tr> <td><a href="#download">Download</a></td> <td><code>$ lynx http://httpd.apache.org/download.cgi</code> </td> </tr> <tr> <td><a href="#extract">Extract</a></td> <td><code>$ gzip -d httpd-2_0_NN.tar.gz $ tar xvf httpd-2_0_NN.tar</code> </td> </tr> <tr> <td><a href="#configure">Configure</a></td> <td><code>$ ./configure --prefix=PREFIX</code> </td> </tr> <tr> <td><a href="#compile">Compile</a></td> <td><code>$ make</code> </td> </tr> <tr> <td><a href="#install">Install</a></td> <td><code>$ make install</code> </td> </tr> <tr> <td><a href="#customize">Customize</a></td> <td><code>$ vi PREFIX/conf/httpd.conf</code> </td> </tr> <tr> <td><a href="#test">Test</a></td> <td><code>$ PREFIX/bin/apachectl start</code> </td> </tr> </table> NN must be replaced with the current minor version number, and PREFIX must be replaced with the filesystem path under which the server should be installed. If PREFIX is not specified, it defaults to <code>/usr/local/apache2</code>. Each section of the compilation and installation process is described in more detail below, beginning with the requirements for compiling and installing Apache HTTPD. </section> <section id="requirements"><title>Requirements</title> The following requirements exist for building Apache: <dl> <dt>Disk Space</dt> <dd>Make sure you have at least 50 MB of temporary free disk space available. After installation Apache occupies approximately 10 MB of disk space. The actual disk space requirements will vary considerably based on your chosen configuration options and any third-party modules.</dd> <dt>ANSI-C Compiler and Build System</dt> <dd>Make sure you have an ANSI-C compiler installed. The <a href="http://www.gnu.org/software/gcc/gcc.html">GNU C compiler (GCC)</a> from the <a href="http://www.gnu.org/">Free Software Foundation (FSF)</a> is recommended (version 2.7.2 is fine). If you don't have GCC then at least make sure your vendor's compiler is ANSI compliant. In addition, your <code>PATH</code> must contain basic build tools such as <code>make</code>.</dd> <dt>Accurate time keeping</dt> <dd>Elements of the HTTP protocol are expressed as the time of day. So, it's time to investigate setting some time synchronization facility on your system. Usually the <code>ntpdate</code> or <code>xntpd</code> programs are used for this purpose which are based on the Network Time Protocol (NTP). See the Usenet newsgroup <a href="news:comp.protocols.time.ntp">comp.protocols.time.ntp</a> and the <a href="http://www.eecis.udel.edu/~ntp/">NTP homepage</a> for more details about NTP software and public time servers.</dd> <dt><a href="http://www.perl.org/">Perl 5</a> [OPTIONAL]</dt> <dd>For some of the support scripts like <a href="programs/apxs.html">apxs</a> or <a href="programs/dbmmanage.html">dbmmanage</a> (which are written in Perl) the Perl 5 interpreter is required (versions 5.003 or newer are sufficient). If no such interpreter is found by the `<code>configure</code>' script there is no harm. Of course, you still can build and install Apache 2.0. Only those support scripts cannot be used. If you have multiple Perl interpreters installed (perhaps a Perl 4 from the vendor and a Perl 5 from your own), then it is recommended to use the <code>--with-perl</code> option (see below) to make sure the correct one is selected by <code>./configure</code>.</dd> </dl> </section> <section id="download"><title>Download</title> Apache can be downloaded from the <a href="http://httpd.apache.org/download.cgi">Apache HTTP Server download site</a> which lists several mirrors. You'll find here the latest stable release. After downloading, especially if a mirror site is used, it is important to verify that you have a complete and unmodified version of the Apache HTTP Server. This can be accomplished by testing the downloaded tarball against the PGP signature. This, in turn, is a two step procedure. First, you must obtain the <a href="http://www.apache.org/dist/httpd/KEYS"><code>KEYS</code></a> file from the Apache distribution site, too. (To assure that the <code>KEYS</code> file itself has not been modified, it may be a good idea to use a file from a previous distribution of Apache or import the keys from a public key server.) The keys are imported into your personal key ring using one of the following commands (depending on your pgp version): <example>$ pgp < KEYS</example> or <example>$ gpg --import KEYS</example> The next step is to test the tarball against the PGP signature, which should always be obtained from the <a href="http://httpd.apache.org/download.cgi">main Apache website</a>. A link to the signature file is placed behind the corresponding download link or may be found in the particular directory at the <a href="http://www.apache.org/dist/httpd/">Apache distribution site</a>. Its filename is identical to the source tarball with the addition of <code>.asc</code>. Then you can check the distribution with one of the following commands (again, depending on your pgp version): <example>$ pgp httpd-2_0_NN.tar.gz.asc</example> or <example>$ gpg --verify httpd-2_0_NN.tar.gz.asc</example> You should receive a message like <example>Good signature from user "Martin Kraemer <martin@apache.org>".</example> Depending on the trust relationships contained in your key ring, you may also receive a message saying that the relationship between the key and the signer of the key cannot be verified. This is not a problem if you trust the authenticity of the <code>KEYS</code> file. </section> <section id="extract"><title>Extract</title> Extracting the source from the Apache HTTPD tarball is a simple matter of uncompressing, and then untarring: <example> $ gzip -d httpd-2_0_NN.tar.gz $ tar xvf httpd-2_0_NN.tar </example> This will create a new directory under the current directory containing the source code for the distribution. You should <code>cd</code> into that directory before proceeding with compiling the server. </section> <section id="configure"><title>Configuring the source tree</title> The next step is to configure the Apache source tree for your particular platform and personal requirements. This is done using the script <code>configure</code> included in the root directory of the distribution. (Developers downloading the CVS version of the Apache source tree will need to have <code>autoconf</code> and <code>libtool</code> installed and will need to run <code>buildconf</code> before proceeding with the next steps. This is not necessary for official releases.) To configure the source tree using all the default options, simply type <code>./configure</code>. To change the default options, <code>configure</code> accepts a variety of variables and command line options. Environment variables are generally placed before the <code>./configure</code> command, while other options are placed after. The most important option here is the location prefix where Apache is to be installed later, because Apache has to be configured for this location to work correctly. But there are a lot of other options available for your pleasure. For a short impression of what possibilities you have, here is a typical example which compiles Apache for the installation tree <code>/sw/pkg/apache</code> with a particular compiler and flags plus the two additional modules <module>mod_rewrite</module> and <module>mod_speling</module> for later loading through the DSO mechanism: <example> $ CC="pgcc" CFLAGS="-O2" \ ./configure --prefix=/sw/pkg/apache \ --enable-rewrite=shared \ --enable-speling=shared </example> When <code>configure</code> is run it will take several minutes to test for the availability of features on your system and build Makefiles which will later be used to compile the server. The easiest way to find all of the configuration flags for Apache is to run <code>./configure --help</code>. What follows is a brief description of most of the arguments and environment variables. <section id="environment"><title>Environment Variables</title> The <code>autoconf</code> build process uses several environment variables to configure the build environment. In general, these variables change the method used to build Apache, but not the eventual features of the server. These variables can be placed in the environment before invoking <code>configure</code>, but it is usually easier to specify them on the <code>configure</code> command line as demonstrated in the example above. <dl> <dt><code>CC=...</code></dt> <dd>The name of the C compiler command.</dd> <dt><code>CPPFLAGS=...</code></dt> <dd>Miscellaneous C preprocessor and compiler options.</dd> <dt><code>CFLAGS=...</code></dt> <dd>Debugging and optimization options for the C compiler.</dd> <dt><code>LDFLAGS=...</code></dt> <dd>Miscellaneous options to be passed to the linker.</dd> <dt><code>LIBS=...</code></dt> <dd>Library location information ("<code>-L</code>" and "<code>-l</code>" options) to pass to the linker.</dd> <dt><code>INCLUDES=...</code></dt> <dd>Header file search directories ("<code>-Idir</code>").</dd> <dt><code>TARGET=...</code> [Default: <code>httpd</code>]</dt> <dd>Name of the executable which will be built.</dd> <dt><code>NOTEST_CPPFLAGS=...</code></dt> <dt><code>NOTEST_CFLAGS=...</code></dt> <dt><code>NOTEST_LDFLAGS=...</code></dt> <dt><code>NOTEST_LIBS=...</code></dt> <dd>These variables share the same function as their non-<code>NOTEST</code> namesakes. However, the variables are applied to the build process only after autoconf has performed its feature testing. This allows the inclusion of flags which will cause problems during feature testing, but must be used for the final compilation.</dd> <dt><code>SHLIB_PATH=...</code></dt> <dd>Options which specify shared library paths for the compiler and linker.</dd> </dl> </section> <section id="output"><title>autoconf Output Options</title> <dl> <dt><code>--help</code></dt> <dd>Prints the usage message including all available options, but does not actually configure anything.</dd> <dt><code>--quiet</code></dt> <dd>Prevents the printing of the usual "<code>checking...</code>" messages.</dd> <dt><code>--verbose</code></dt> <dd>Prints much more information during the configuration process, including the names of all the files examined.</dd> </dl> </section> <section id="pathnames"><title>Pathnames</title> There are currently two ways to configure the pathnames under which Apache will install its files. First, you can specify a directory and have Apache install itself under that directory in its default locations. <dl> <dt><code>--prefix=PREFIX</code> [Default: <code>/usr/local/apache2</code>]</dt> <dd>Specifies the directory under which the Apache files will be installed.</dd> </dl> It is possible to specify that architecture-dependent files should be placed under a different directory. <dl> <dt><code>--exec-prefix=EPREFIX</code> [Default: <code>PREFIX</code>]</dt> <dd>Specifies the directory under which architecture-dependent files will be placed.</dd> </dl> The second, and more flexible way to configure the install path locations for Apache is using the <code>config.layout</code> file. Using this method, it is possible to separately specify the location for each type of file within the Apache installation. The <code>config.layout</code> file contains several example configurations, and you can also create your own custom configuration following the examples. The different layouts in this file are grouped into <code><Layout FOO>...</Layout></code> sections and referred to by name as in <code>FOO</code>. <dl> <dt><code>--enable-layout=LAYOUT</code></dt> <dd>Use the named layout in the <code>config.layout</code> file to specify the installation paths.</dd> </dl> </section> <section id="modules"><title>Modules</title> Apache is a modular server. Only the most basic functionality is included in the core server. Extended features are available in various modules. During the configuration process, you must select which modules to compile for use with your server. You can view a <a href="mod/">list of modules</a> included in the documentation. Those modules with a <a href="mod/module-dict.html#Status">status</a> of "Base" are included by default and must be specifically disabled if you do not want them (e.g. <module>mod_userdir</module>). Modules with any other status must be specifically enabled if you wish to use them (e.g. <module>mod_expires</module>). There are two ways for a module to be compiled and used with Apache. Modules may be statically compiled, which means that they are permanently included in the Apache binary. Alternatively, if your operating system supports Dynamic Shared Objects (DSOs) and <code>autoconf</code> can detect that support, then modules may be dynamically compiled. DSO modules are stored separately from the Apache binary, and may be included or excluded from the server using the run-time configuration directives provided by <module>mod_so</module>. The mod_so is automatically included in the server if any dynamic modules are included in the compilation. If you would like to make your server capable of loading DSOs without actually compiling any dynamic modules, you can explicitly <code>--enable-so</code>. <dl> <dt><code>--enable-MODULE[=shared]</code></dt> <dd>Compile and include the module MODULE. The identifier MODULE is the <a href="mod/module-dict.html#ModuleIdentifier">Module Identifier</a> from the module documentation without the "_module" string. To compile the module as a DSO, add the option <code>=shared</code>.</dd> <dt><code>--disable-MODULE</code></dt> <dd>Remove the module MODULE which would otherwise be compiled and included.</dd> <dt><code>--enable-modules=MODULE-LIST</code></dt> <dd>Compile and include the modules listed in the space-separated MODULE-LIST.</dd> <dt> <code>--enable-mods-shared=MODULE-LIST</code></dt> <dd>Compile and include the modules in the space-separated MODULE-LIST as dynamically loadable (DSO) modules.</dd> </dl> The MODULE-LIST in the <code>--enable-modules</code> and <code>--enable-mods-shared</code> options is usually a space-separated list of module identifiers. For example, to enable <module>mod_dav</module> and <module>mod_info</module>, you can either use <example>./configure --enable-dav --enable-info</example> or, equivalently, <example>./configure --enable-modules="dav info"</example> In addition, the special keywords <code>all</code> or <code>most</code> can be used to add all or most of the modules in one step. You can then remove any modules that you do not want with the <code>--disable-MODULE</code> option. For example, to include all modules as DSOs with the exception of <module>mod_info</module>, you can use <example> ./configure --enable-mods-shared=all --disable-info </example> In addition to the standard set of modules, Apache 2.0 also includes a choice of <a href="mpm.html">Multi-Processing Modules</a> (MPMs). One, and only one MPM must be included in the compilation process. The default MPMs for each platform are listed on the <a href="mpm.html">MPM documentation page</a>, but can be overridden on the <code>configure</code> command line. <dl> <dt><code>--with-mpm=NAME</code></dt> <dd>Choose the mpm NAME.</dd> </dl> To activate an MPM called <var>mpm_name</var>, you can use <example> ./configure --with-mpm=<var>mpm_name</var> </example> </section> <section id="dbm"><title>DBM</title> Several Apache features, including <module>mod_auth_dbm</module> and <module>mod_rewrite</module>'s DBM <directive module="mod_rewrite">RewriteMap</directive> use simple key/value databases for quick lookups of information. Apache includes SDBM with its source-code, so this database is always available. If you would like to use other database types, the following <code>configure</code> options are available: <dl> <dt><code>--with-gdbm[=path]</code></dt> <dt><code>--with-ndbm[=path]</code></dt> <dt><code>--with-berkeley-db[=path]</code></dt> <dd>If no path is specified, Apache will search for the include files and libraries in the usual search paths. An explicit path will cause Apache to look in path<code>/lib</code> and path<code>/include</code> for the relevant files. Finally, the path may specify specific include and library paths separated by a colon.</dd> </dl> </section> <section id="suexec"><title>Suexec</title> Apache includes a support program called <a href="suexec.html">suexec</a> which can be used to isolate user CGI programs. However, if suexec is improperly configured, it can cause serious security problems. Therefore, you should carefully read and consider the <a href="suexec.html">suexec documentation</a> before implementing this feature. </section> </section> <section id="compile"><title>Build</title> Now you can build the various parts which form the Apache package by simply running the command: <example>$ make</example> Please be patient here, since a base configuration takes approximately 3 minutes to compile under a Pentium III/Linux 2.2 system, but this will vary widely depending on your hardware and the number of modules which you have enabled. </section> <section id="install"><title>Install</title> Now it's time to install the package under the configured installation PREFIX (see <code>--prefix</code> option above) by running: <example>$ make install</example> If you are upgrading, the installation will not overwrite your configuration files or documents. </section> <section id="customize"><title>Customize</title> Next, you can customize your Apache HTTP server by editing the <a href="configuring.html">configuration files</a> under <code>PREFIX/conf/</code>. <example>$ vi PREFIX/conf/httpd.conf</example> Have a look at the Apache manual under <a href="./">docs/manual/</a> or consult <a href="http://httpd.apache.org/docs-2.0/" >http://httpd.apache.org/docs-2.0/</a> for the most recent version of this manual and a complete reference of available <a href="mod/directives.html">configuration directives</a>. </section> <section id="test"><title>Test</title> Now you can <a href="invoking.html">start</a> your Apache HTTP server by immediately running: <example>$ PREFIX/bin/apachectl start</example> and then you should be able to request your first document via URL <code>http://localhost/</code>. The web page you see is located under the <directive module="core">DocumentRoot</directive> which will usually be <code>PREFIX/htdocs/</code>. Then <a href="stopping.html">stop</a> the server again by running: <example>$ PREFIX/bin/apachectl stop</example> </section> <section id="upgrading"><title>Upgrading</title> The first step in upgrading is to read the release announcement and the file <code>CHANGES</code> in the source distribution to find any changes that may affect your site. When changing between major releases (for example, from 1.3 to 2.0 or from 2.0 to 2.2), there will likely be major differences in the compile-time and run-time configuration that will require manual adjustments. All modules will also need to be upgraded to accomodate changes in the module API. Upgrading from one minor version to the next (for example, from 2.0.55 to 2.0.57) is easier. The <code>make install</code> process will not overwrite any of your existing documents, log files, or configuration files. In addition, the developers make every effort to avoid incompatible changes in the <code>configure</code> options, run-time configuration, or the module API between minor versions. In most cases you should be able to use an identical <code>configure</code> command line, an identical configuration file, and all of your modules should continue to work. (This is only valid for versions after 2.0.41; earlier versions have incompatible changes.) If you kept the source tree from your last installation, upgrading is even easier. The file <code>config.nice</code> in the root of the old source tree contains the exact <code>configure</code> command line that you used to configure the source tree. Then to upgrade from one version to the next, you need only copy the <code>config.nice</code> file to the source tree of the new version, edit it to make any desired changes, and then run: <example> $ ./config.nice $ make $ make install $ PREFIX/bin/apachectl stop $ PREFIX/bin/apachectl start </example> <note type="warning">You should always test any new version in your environment before putting it into production. For example, you can install and run the new version along side the old one by using a different <code>--prefix</code> and a different port (by adjusting the <directive module="mpm_common">Listen</directive> directive) to test for any incompatibilities before doing the final upgrade.</note> </section> </manualpage>