This commit was manufactured by cvs2svn to create branch 'avendor'.

#!/bin/sh

#

# binbuild.sh - Builds an Apache binary distribution.

# Initially written by Lars Eilebrecht <lars@apache.org>.

#

# This script falls under the Apache License.

# See http://www.apache.org/docs/LICENSE

APDIR=$(basename $(pwd))

VER=$(echo $APDIR |sed s/apache-//)

OS=$(src/helpers/GuessOS)

USER="$(src/helpers/buildinfo.sh -n %u@%h%d)"

TAR="$(src/helpers/findprg.sh tar)"

GTAR="$(src/helpers/findprg.sh gtar)"

GZIP="$(src/helpers/findprg.sh gzip)"

CONFIGPARAM="--with-layout=BinaryDistribution --enable-module=most --enable-shared=max"

if [ ! -f ./ABOUT_APACHE ]

then

  echo "ERROR: The current directory contains no valid Apache distribution."

  echo "Please change the directory to the top level directory of a freshly"

  echo "unpacked Apache 1.3 source distribution and re-execute the script"

  echo "'./src/helpers/bindbuild.sh'." 

  exit 1;

fi

if [ -d ./CVS ]

then

  echo "ERROR: The current directory is a CVS checkout of Apache."

  echo "Only a standard Apache 1.3 source distribution should be used to"

  echo "create a binary distribution."

  exit 1;

fi

echo "Building Apache $VER binary distribution..."

echo "Platform is \"$OS\"..."

( echo "Build log for Apache binary distribution" && \

  echo "----------------------------------------------------------------------" && \

  ./configure $CONFIGPARAM && \

  echo "----------------------------------------------------------------------" && \

  make clean && \

  rm -rf bindist install-bindist.sh *.bindist

  echo "----------------------------------------------------------------------" && \

  make && \

  echo "----------------------------------------------------------------------" && \

  make install-quiet root="bindist/" && \

  echo "----------------------------------------------------------------------" && \

  make clean && \

  echo "----------------------------------------------------------------------" && \

  echo "[EOF]" \

) > build.log 2>&1

if [ ! -f ./bindist/bin/httpd ]

then

  echo "ERROR: Failed to build Apache. See \"build.log\" for details."

  exit 1;

fi

echo "Binary images successfully created..."

echo "Creating supplementary files..."

( echo " " && \

  echo "Apache $VER binary distribution" && \

  echo "================================" && \

  echo " " && \

  echo "This binary distribution is usable on a \"$OS\"" && \

  echo "system and was built by \"$USER\"." && \

  echo "" && \

  echo "The distribution contains all standard Apache modules as shared" && \

  echo "objects. This allows you to enable or disable particular modules" && \

  echo "with the LoadModule/AddModule directives in the configuration file" && \

  echo "without the need to re-compile Apache." && \

  echo "" && \

  echo "See \"INSTALL.bindist\" on how to install the distribution." && \

  echo " " && \

  echo "NOTE: Please do not send support-related mails to the address mentioned" && \

  echo "      above or to any member of the Apache Group! Support questions" && \

  echo "      should be directed to the \"comp.infosystems.www.servers.unix\"" && \

  echo "      or \"comp.infosystems.www.servers.ms-windows\" newsgroup" && \

  echo "      (as appropriate for the platform you use), where some of the" && \

  echo "      Apache team lurk, in the company of many other Apache gurus" && \

  echo "      who should be able to help." && \

  echo "      If you think you found a bug in Apache or have a suggestion please" && \

  echo "      visit the bug report page at http://www.apache.org/bug_report.html" && \

  echo " " && \

  echo "----------------------------------------------------------------------" && \

  ./bindist/bin/httpd -V && \

  echo "----------------------------------------------------------------------" \

) > README.bindist

cp README.bindist ../apache-$VER-$OS.README

( echo " " && \

  echo "Apache $VER binary installation" && \

  echo "================================" && \

  echo " " && \

  echo "To install this binary distribution you have to execute the installation" && \

  echo "script \"install-bindist.sh\" in the top-level directory of the distribution." && \

  echo " " && \

  echo "The script takes the ServerRoot directory into which you want to install" && \

  echo "Apache as an option. If you ommit the option the default path" && \

  echo "\"/usr/local/apache\" is used." && \

  echo "Make sure you have write permissions in the target directory, e.g. switch" && \

  echo "to user \"root\" before you execute the script." && \

  echo " " && \

  echo "See \"README.bindist\" for further details about this distribution." && \

  echo " " && \

  echo "Please note that this distribution includes the complete Apache source code." && \

  echo "Therefore you may compile Apache yourself at any time if you have a compiler" && \

  echo "installation on your system." && \

  echo "See \"INSTALL\" for details on how to accomplish this." && \

  echo " " \

) > INSTALL.bindist

( echo "#!/bin/sh" && \

  echo "#" && \

  echo "# Usage: install-bindist.sh [ServerRoot]" && \

  echo "# This script installs the Apache binary distribution and" && \

  echo "# was automatically created by binbuild.sh." && \

  echo " " && \

  echo "if [ .\$1 = . ]" && \

  echo "then" && \

  echo "  SR=/usr/local/apache" && \

  echo "else" && \

  echo "  SR=\$1" && \

  echo "fi" && \

  echo "echo \"Installing binary distribution for platform $OS\"" && \

  echo "echo \"into directory \$SR ...\"" && \

  echo "./src/helpers/mkdir.sh \$SR" && \

  echo "cp -r bindist/proxy \$SR/proxy" && \

  echo "cp -r bindist/man \$SR/man" && \

  echo "cp -r bindist/logs \$SR/logs" && \

  echo "cp -r bindist/libexec \$SR/libexec" && \

  echo "cp -r bindist/include \$SR/include" && \

  echo "cp -r bindist/icons \$SR/icons" && \

  echo "cp -r bindist/cgi-bin \$SR/cgi-bin" && \

  echo "cp -r bindist/bin \$SR/bin" && \

  echo "if [ -d \$SR/conf ]" && \

  echo "then" && \

  echo "  echo \"[Preserving existing configuration files.]\"" && \

  echo "  cp -r bindist/conf/*.default \$SR/conf/" && \

  echo "else" && \

  echo "  cp -r bindist/conf \$SR/conf" && \

  echo "fi" && \

  echo "if [ -d \$SR/htdocs ]" && \

  echo "then" && \

  echo "  echo \"[Preserving existing htdocs directory.]\"" && \

  echo "else" && \

  echo "  cp -r bindist/htdocs \$SR/htdocs" && \

  echo "fi" && \

  echo "sed -e s%/usr/local/apache%\$SR/% \$SR/conf/httpd.conf.default > \$SR/conf/httpd.conf" && \

  echo "sed -e s%PIDFILE=%PIDFILE=\$SR/% -e s%HTTPD=%HTTPD=\\\"\$SR/% -e \"s%/httpd$%/httpd -d \$SR\\\"%\" bindist/bin/apachectl > \$SR/bin/apachectl" && \

  echo " " && \

  echo "echo \"Ready.\"" && \

  echo "echo \" +--------------------------------------------------------+\"" && \

  echo "echo \" | You now have successfully installed the Apache $VER   |\"" && \

  echo "echo \" | HTTP server. To verify that Apache actually works      |\"" && \

  echo "echo \" | correctly you now should first check the (initially    |\"" && \

  echo "echo \" | created or preserved) configuration files              |\"" && \

  echo "echo \" |                                                        |\"" && \

  echo "echo \" |   \$SR/conf/httpd.conf\"" && \

  echo "echo \" |                                                        |\"" && \

  echo "echo \" | and then you should be able to immediately fire up     |\"" && \

  echo "echo \" | Apache the first time by running:                      |\"" && \

  echo "echo \" |                                                        |\"" && \

  echo "echo \" |   \$SR/bin/apachectl start \"" &&\

  echo "echo \" |                                                        |\"" && \

  echo "echo \" | Thanks for using Apache.       The Apache Group        |\"" && \

  echo "echo \" |                                http://www.apache.org/  |\"" && \

  echo "echo \" +--------------------------------------------------------+\"" && \

  echo "echo \" \"" \

) > install-bindist.sh

chmod 755 install-bindist.sh

sed -e "s%\"/htdocs%\"/usr/local/apache/htdocs%" \

    -e "s%\"/icons%\"/usr/local/apache/icons%" \

    -e "s%\"/cgi-bin%\"/usr/local/apache/cgi-bin%" \

    -e "s%^ServerAdmin.*%ServerAdmin you@your.address%" \

    -e "s%#ServerName.*%#ServerName localhost%" \

    -e "s%Port 8080%Port 80%" \

    bindist/conf/httpd.conf.default > bindist/conf/httpd.conf

cp bindist/conf/httpd.conf bindist/conf/httpd.conf.default

echo "Creating distribution archive and readme file..."

if [ ".`grep -i error build.log > /dev/null`" != . ]

then

  echo "ERROR: Failed to build Apache. See \"build.log\" for details."

  exit 1;

else

  if [ ".$GTAR" != . ]

  then

    $GTAR -zcf ../apache-$VER-$OS.tar.gz -C .. --owner=root --group=root apache-$VER

  else

    if [ ".$TAR" != . ]

    then

      $TAR -cf ../apache-$VER-$OS.tar -C .. apache-$VER

      if [ ".$GZIP" != . ]

      then

        $GZIP ../apache-$VER-$OS.tar

      fi

    else

      echo "ERROR: Could not find a 'tar' program!"

      echo "       Please execute the following commands manually:"

      echo "         tar -cf ../apache-$VER-$OS.tar ."

      echo "         gzip ../apache-$VER-$OS.tar"

    fi

  fi

  if [ -f ../apache-$VER-$OS.tar.gz ] && [ -f ../apache-$VER-$OS.README ]

  then

    echo "Ready."

    echo "You can find the binary archive (apache-$VER-$OS.tar.gz)"

    echo "and the readme file (apache-$VER-$OS.README) in the"

    echo "parent directory."

    exit 0;

  else

    exit 1;

  fi

fi

<html><head>

<title>PATH_INFO Changes in the CGI Environment</title>

</head><body>

<!--#include virtual="header.html" -->

<h1>PATH_INFO Changes in the CGI Environment</h1>

<hr>

<h2><a name="over">Overview</a></h2>

<p>As implemented in Apache 1.1.1 and earlier versions, the method

Apache used to create PATH_INFO in the CGI environment was

counterintiutive, and could result in crashes in certain cases. In

Apache 1.2 and beyond, this behavior has changed. Although this

results in some compatibility problems with certain legacy CGI

applications, the Apache 1.2 behavior is still compatible with the

CGI/1.1 specification, and CGI scripts can be easily modified (<a

href="#compat">see below</a>).

<h2><a name="prob">The Problem</a></h2>

<p>Apache 1.1.1 and earlier implemented the PATH_INFO and SCRIPT_NAME

environment variables by looking at the filename, not the URL. While

this resulted in the correct values in many cases, when the filesystem

path was overloaded to contain path information, it could result in

errant behavior. For example, if the following appeared in a config

file:

<pre>

     Alias /cgi-ralph /usr/local/httpd/cgi-bin/user.cgi/ralph

</pre>

<p>In this case, <code>user.cgi</code> is the CGI script, the "/ralph"

is information to be passed onto the CGI. If this configuration was in

place, and a request came for "<code>/cgi-ralph/script/</code>", the

code would set PATH_INFO to "<code>/ralph/script</code>", and

SCRIPT_NAME to "<code>/cgi-</code>". Obviously, the latter is

incorrect. In certain cases, this could even cause the server to

crash.</p>

<h2><a name="solution">The Solution</a></h2>

<p>Apache 1.2 and later now determine SCRIPT_NAME and PATH_INFO by

looking directly at the URL, and determining how much of the URL is

client-modifiable, and setting PATH_INFO to it. To use the above

example, PATH_INFO would be set to "<code>/script</code>", and

SCRIPT_NAME to "<code>/cgi-ralph</code>". This makes sense and results

in no server behavior problems. It also permits the script to be

gauranteed that

"<code>http://$SERVER_NAME:$SERVER_PORT$SCRIPT_NAME$PATH_INFO</code>"

will always be an accessable URL that points to the current script,

something which was not neccessarily true with previous versions of

Apache.

<p>However, the "<code>/ralph</code>"

information from the <code>Alias</code> directive is lost. This is

unfortunate, but we feel that using the filesystem to pass along this

sort of information is not a recommended method, and a script making

use of it "deserves" not to work. Apache 1.2b3 and later, however, do

provide <a href="#compat">a workaround.</a>

<h2><a name="compat">Compatibility with Previous Servers</a></h2>

<p>It may be neccessary for a script that was designed for earlier

versions of Apache or other servers to need the information that the

old PATH_INFO variable provided. For this purpose, Apache 1.2 (1.2b3

and later) sets an additional variable, FILEPATH_INFO. This

environment variable contains the value that PATH_INFO would have had

with Apache 1.1.1.</p>

<p>A script that wishes to work with both Apache 1.2 and earlier

versions can simply test for the existance of FILEPATH_INFO, and use

it if available. Otherwise, it can use PATH_INFO. For example, in

Perl, one might use:

<pre>

    $path_info = $ENV{'FILEPATH_INFO'} || $ENV{'PATH_INFO'};

</pre>

<p>By doing this, a script can work with all servers supporting the

CGI/1.1 specification, including all versions of Apache.</p>

<!--#include virtual="footer.html" -->

</BODY>

</HTML>

<html><head>

<title>PATH_INFO Changes in the CGI Environment</title>

</head><body>

<!--#include virtual="header.html" -->

<h1>PATH_INFO Changes in the CGI Environment</h1>

<hr>

<h2><a name="over">Overview</a></h2>

<p>As implemented in Apache 1.1.1 and earlier versions, the method

Apache used to create PATH_INFO in the CGI environment was

counterintiutive, and could result in crashes in certain cases. In

Apache 1.2 and beyond, this behavior has changed. Although this

results in some compatibility problems with certain legacy CGI

applications, the Apache 1.2 behavior is still compatible with the

CGI/1.1 specification, and CGI scripts can be easily modified (<a

href="#compat">see below</a>).

<h2><a name="prob">The Problem</a></h2>

<p>Apache 1.1.1 and earlier implemented the PATH_INFO and SCRIPT_NAME

environment variables by looking at the filename, not the URL. While

this resulted in the correct values in many cases, when the filesystem

path was overloaded to contain path information, it could result in

errant behavior. For example, if the following appeared in a config

file:

<pre>

     Alias /cgi-ralph /usr/local/httpd/cgi-bin/user.cgi/ralph

</pre>

<p>In this case, <code>user.cgi</code> is the CGI script, the "/ralph"

is information to be passed onto the CGI. If this configuration was in

place, and a request came for "<code>/cgi-ralph/script/</code>", the

code would set PATH_INFO to "<code>/ralph/script</code>", and

SCRIPT_NAME to "<code>/cgi-</code>". Obviously, the latter is

incorrect. In certain cases, this could even cause the server to

crash.</p>

<h2><a name="solution">The Solution</a></h2>

<p>Apache 1.2 and later now determine SCRIPT_NAME and PATH_INFO by

looking directly at the URL, and determining how much of the URL is

client-modifiable, and setting PATH_INFO to it. To use the above

example, PATH_INFO would be set to "<code>/script</code>", and

SCRIPT_NAME to "<code>/cgi-ralph</code>". This makes sense and results

in no server behavior problems. It also permits the script to be

gauranteed that

"<code>http://$SERVER_NAME:$SERVER_PORT$SCRIPT_NAME$PATH_INFO</code>"

will always be an accessable URL that points to the current script,

something which was not neccessarily true with previous versions of

Apache.

<p>However, the "<code>/ralph</code>"

information from the <code>Alias</code> directive is lost. This is

unfortunate, but we feel that using the filesystem to pass along this

sort of information is not a recommended method, and a script making

use of it "deserves" not to work. Apache 1.2b3 and later, however, do

provide <a href="#compat">a workaround.</a>

<h2><a name="compat">Compatibility with Previous Servers</a></h2>

<p>It may be neccessary for a script that was designed for earlier

versions of Apache or other servers to need the information that the

old PATH_INFO variable provided. For this purpose, Apache 1.2 (1.2b3

and later) sets an additional variable, FILEPATH_INFO. This

environment variable contains the value that PATH_INFO would have had

with Apache 1.1.1.</p>

<p>A script that wishes to work with both Apache 1.2 and earlier

versions can simply test for the existance of FILEPATH_INFO, and use

it if available. Otherwise, it can use PATH_INFO. For example, in

Perl, one might use:

<pre>

    $path_info = $ENV{'FILEPATH_INFO'} || $ENV{'PATH_INFO'};

</pre>

<p>By doing this, a script can work with all servers supporting the

CGI/1.1 specification, including all versions of Apache.</p>

<!--#include virtual="footer.html" -->

</BODY>

</HTML>

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">

<html><head>

<title>Issues Regarding DNS and Apache</title>

</head><body>

<!--#include virtual="header.html" -->

<h1>Issues Regarding DNS and Apache</h1>

<p>This page could be summarized with the statement: <i>don't require

Apache to use DNS for any parsing of the configuration files</i>.

If Apache has to use DNS to parse the configuration files then your

server may be subject to reliability problems (it might not boot), or

denial and theft of service attacks (including users able to steal hits

from other users).

<h3>A Simple Example</h3>

Consider this configuration snippet:

<blockquote><pre>

    <VirtualHost www.abc.dom>

    ServerAdmin webgirl@abc.dom

    DocumentRoot /www/abc

    </VirtualHost>

</pre></blockquote>

<p>In order for Apache to function properly it absolutely needs

to have two pieces of information about each virtual host: the

<a href="mod/core.html#servername"><code>ServerName</code></a>

and at least one ip address that the server

responds to.  This example does not include the ip address, so Apache

must use DNS to find the address of <code>www.abc.dom</code>.  If for

some reason DNS is not available at the time your server is parsing its

config file, then this virtual host <b>will not be configured</b>.  It

won't be able to respond to any hits to this virtual host (prior to

Apache version 1.2 the server would not even boot).

<p>Suppose that <code>www.abc.dom</code> has address 10.0.0.1.  Then

consider this configuration snippet:

<blockquote><pre>

    <VirtualHost 10.0.0.1>

    ServerAdmin webgirl@abc.dom

    DocumentRoot /www/abc

    </VirtualHost>

</pre></blockquote>

<p>Now Apache needs to use reverse DNS to find the <code>ServerName</code>

for this virtualhost.  If that reverse lookup fails then it will partially

disable the virtualhost (prior to Apache version 1.2 the server would not

even boot).  If the virtual host is name-based then it will effectively

be totally disabled, but if it is ip-based then it will mostly work.

However if Apache should ever have to generate a full URL for the server

which includes the server name then it will fail to generate a valid URL.

<p>Here is a snippet that avoids both of these problems.

<blockquote><pre>

    <VirtualHost 10.0.0.1>

    ServerName www.abc.dom

    ServerAdmin webgirl@abc.dom

    DocumentRoot /www/abc

    </VirtualHost>

</pre></blockquote>

<h3>Denial of Service</h3>

<p>There are (at least) two forms that denial of service can come in.

If you are running a version of Apache prior to version 1.2 then your

server will not even boot if one of the two DNS lookups mentioned above

fails for any of your virtual hosts.  In some cases this DNS lookup may

not even be under your control.  For example, if <code>abc.dom</code>

is one of your customers and they control their own DNS then they

can force your (pre-1.2) server to fail while booting simply by deleting the

<code>www.abc.dom</code> record.

<p>Another form is far more insidious.  Consider this configuration

snippet:

<blockquote><pre>

    <VirtualHost www.abc.dom>

    ServerAdmin webgirl@abc.dom

    DocumentRoot /www/abc

    </VirtualHost>

</pre></blockquote>

<blockquote><pre>

    <VirtualHost www.def.dom>

    ServerAdmin webguy@def.dom

    DocumentRoot /www/def

    </VirtualHost>

</pre></blockquote>

<p>Suppose that you've assigned 10.0.0.1 to <code>www.abc.dom</code> and

10.0.0.2 to <code>www.def.dom</code>.  Furthermore, suppose that

<code>def.com</code> has control of their own DNS.  With this config

you have put <code>def.com</code> into a position where they can steal

all traffic destined to <code>abc.com</code>.  To do so, all they have to

do is set <code>www.def.dom</code> to 10.0.0.1.

Since they control their own DNS you can't stop them from pointing the

<code>www.def.com</code> record wherever they wish.

<p>Requests coming in to 10.0.0.1 (including all those where users typed

in URLs of the form <code>http://www.abc.dom/whatever</code>) will all be

served by the <code>def.com</code> virtual host.  To better understand why

this happens requires a more in-depth discussion of how Apache matches

up incoming requests with the virtual host that will serve it.  A rough

document describing this <a href="vhosts-in-depth.html"> is available</a>.

<h3>The "main server" Address</h3>

<p>The addition of <a href="host.html">non-IP-based virtual host

support</a> in Apache 1.1 requires Apache to know the IP address(es) of

the host that httpd is running on.  To get this address it uses either

the global <code>ServerName</code> (if present) or calls the C function

<code>gethostname</code> (which should return the same as typing

"hostname" at the command prompt).  Then it performs a DNS lookup on

this address.  At present there is no way to avoid this lookup.

<p>If you fear that this lookup might fail because your DNS server is down

then you can insert the hostname in <code>/etc/hosts</code> (where you

probably already have it so that the machine can boot properly).  Then

ensure that your machine is configured to use <code>/etc/hosts</code>

in the event that DNS fails.  Depending on what OS you are using this

might be accomplished by editing <code>/etc/resolv.conf</code>, or maybe

<code>/etc/nsswitch.conf</code>.

<p>If your server doesn't have to perform DNS for any other reason

then you might be able to get away with running Apache with the

<code>HOSTRESORDER</code> environment variable set to "local".  This all

depends on what OS and resolver libraries you are using.  It also affects

CGIs unless you use <a href="mod/mod_env.html"><code>mod_env</code></a>

to control the environment.  It's best to consult the man pages or FAQs

for your OS.

<h3>The _default_ Address</h3>

<p>Any address that happens to go to your webserver which doesn't match

the ip address of any of the webservers will be served from the "main" or

"default" server configurations.  The "main" server configuration consists

of all those definitions appearing outside of any VirtualHost section.

You may want instead to define a <code>&lt;VirtualHost _default&gt;</code>

which returns 403 or 404 for all hits.

<a name="tips"><h3>Tips to Avoid these problems</h3></a>

<ul>

<li> use ip addresses in <code>&lt;VirtualHost&gt</code>

<li> use ip addresses in <code>Listen</code>

<li> use ip addresses in <code>BindAddress</code>

<li> ensure all virtual hosts have an explicit <code>ServerName</code>

<li> create a <code>&lt;VirtualHost _default_&gt;</code> server that

    has no pages to serve

</ul>

<h3>Appendix: Future Directions</h3>

<p>The situation regarding DNS is highly undesirable.  For Apache

1.2 we've attempted to make the server at least continue booting

in the event of failed DNS, but it might not be the best we

can do.  In any event requiring the use of explicit ip addresses in

configuration files is highly undesirable in today's Internet where <a

href="http://www.ietf.org/html.charters/pier-charter.html">renumbering

</a> is a necessity.

<p>A possible work around to the theft of service attack described above

would be to perform a reverse DNS lookup on the ip address returned by

the forward lookup and compare the two names.  In the event of a mismatch

the virtualhost would be disabled.  This would require reverse DNS to be

configured properly (which is something that most admins are familiar with

because of the common use of "double-reverse" DNS lookups by FTP servers

and TCP wrappers).

<p>In any event it doesn't seem possible to reliably boot a virtual-hosted

web server when DNS has failed unless IP addresses are used.  Partial

solutions such as disabling portions of the configuration might be worse

than not booting at all depending on what the webserver is supposed

to accomplish.

<p>As HTTP/1.1 is deployed and browsers and proxies start issuing the 

<code>Host</code> header it will become possible to avoid the use of

ip-based virtual hosts entirely.  In this event a webserver has no requirement

to do DNS lookups during configuration.  But as of March 1997 these

features have not been deployed widely enough to be put into use on

critical webservers.

<!--#include virtual="footer.html" -->

</BODY>

</HTML>