Apache

TechRepublic SolutionSeries Apache: The engine that powers the Web
TechRepublic SolutionSeries
Table of Contents
Apache: The engine Introduction ..................................................................................................3
that powers the Web
What's new in Apache 2.2.4? ......................................................................4
Executive Editor Setting up a simple Web site with Apache 2.2.4 ......................................8
Jason Hiner Make the move from IIS to Apache 2.2.x ..............................................13
Section Editor
John Sheesley
Troubleshoot Apache with these tips ......................................................18
Contributing Editors Ten tips for securing Apache ....................................................................24
Scott Lowe, Jack Wallen, Setting up Apache as a Web server under Linux via GUI....................31
and Vincent Danen
Creating virtual hosts with Apache..........................................................35
Assistant Editor | Graphic Artist
Christina Cathcart
Copyright ©1995-2007
by CNET Networks, Inc. All rights
reserved. TechRepublic and its logo
are trademarks of CNET Networks,
Inc. All other product names or
services identified throughout this
book are trademarks or registered
trademarks of their respective
companies. Reproduction of this
publication in any form without prior
written permission is forbidden.
Disclaimer
The information contained herein has
been obtained from sources believed
to be reliable. CNET Networks, Inc.
disclaims all warranties as to the
accuracy, completeness, or adequacy
of such information. CNET Networks,
Inc. shall have no liability for errors,
omissions, or inadequacies in the
information contained herein or for
the interpretations thereof. The reader
assumes sole responsibility for the
selection of these materials to achieve
its intended results. The opinions
expressed herein are subject to
change without notice.
TechRepublic
1630 Lyndon Farm Court
Louisville, KY 40223
Tel.: 1.800.217.4339
Online Customer Support:
http://www.techrepublic.com/cshelp
Published by TechRepublic
August 2007
This TechRepublic PDF is best viewed in
Facing page layout in Adobe Acrobat Reader.
©2007 CNET Networks, Inc. All rights reserved. 2

Introduction
W
hen people think of the term “Open Source Software”, usually the first
thing that comes to mind is the Linux operating system. Linux has been the
poster child for the open source movement for some time, but it's certainly
not the only member of the family.
Beyond Linux, the most famous and widely used piece of open source software is
the Apache Web server. Once by far the most dominant Web server software on the
Internet, Apache still powers about half of the Web sites you'll run into.
One of Apache's key benefits is that it runs on a multitude of operating systems.
You can obtain a version of Apache for such network operating systems as:
X Windows
X Linux
X Mac OS X
X OS/2
X NetWare
X Unix
Apache's chief rival for market share is Microsoft's IIS. Microsoft's Internet
Information Services has shipped with every version of Windows since it was created
as part of an Option Pack for Windows NT back in the late 90's.
Even though no one “owns” Apache, and the open source nature of it means that
anyone can get and modify the original source code, Apache still has a reputation of
being more secure than IIS.
Sometimes you'll hear Apache's name used in concert with other open source soft-
ware, such as Linux, MySQL, and PHP. Together, these products are referred to by the
acronym LAMP. The easiest way to think of them is a software suite which are often
used together to create rich full-featured Web sites.
One of the major drawbacks to Apache is that it's not always as easy to use as IIS.
Whereas Microsoft has gone to great lengths to ensuring that setting up and using IIS
is largely a point-and-click affair, Apache makes use of 80's-era configuration files. This
gives you more flexibility, but makes managing the Apache configurations more chal-
lenging.
In the sections that follow in this guide, we'll show you some of the essentials of
working with Apache 2.2.4. You'll see how to install Apache, how the configuration
files work, and even how to do some advanced things like setting up virtual hosts.

What's new in Apache 2.2.4?
R
eleased in early 2007, Apache 2.2.4 is the latest version of Apache released in the
2.2 branch. Apache 2.2 is a major update from Apache 2.0 and provides a number
of new features and enhancements over previous versions of the server. Apache
2.2.4 is available for most operating systems, including Windows, OS X, UNIX and Linux.
Database handling changes

In versions of Apache prior to the 2.2 release, each module requiring database con-
nectivity (PHP, Perl, Python, etc.) was responsible for implementing its own database
connection pool. Apache 2.2 introduces mod_dbd, which provides SQL database sup-
port directly to modules that need it and further pools database connections server-
wide, thus making connections dynamically available and persistent, resulting in better
use of resources, improved performance, and great scalability.
The new mod_dbd current supports Oracle, MySQL, PostgreSQL, SQLite2 and SQLite3.
Apache 2.2.4 fixes some bugs in mod_dbd and improves some of mod_dbd's behavior
to make it more efficient. For example, mod_dbd now shares per-request database han-
dles across subrequests and internal redirects and keys database connection pools to
virtual hosts correctly even when the ServerName directive has not been set. By ensur-
ing that the right database connections are made available to the right virtual host, the
overall security of the system is improved as well.
Addition of caching and proxy load balancing

Apache has long had the capability to be used as a typical proxy server and offers
support for both forward and reverse proxy services. For some time as well, Apache
has been able to cache content, but this functionality has been labeled as experimental,
indicating that users should proceed at their own risk with a caching implementation.
For 2.2, the Apache folks have stripped the experimental label from the caching system
and replaced it with the 'stable' moniker and enabled a much more robust proxy system
through the addition of load balancing for the proxy service.
On the caching side of the house, Apache can use either disk (mod_disk_cache) or
RAM (mod_mem_cache) to hold the appropriate content, although it has been indicated
that RAM caching does not provide an advantage over disk-based caching. Caching in
general, whether it's in conjunction with a proxy service or just used to statically pro-
vide dynamic content that has not changed, can result in a huge performance boost for
the end-user and for the Web server.
On the end-user front, the person doesn't need to wait for a page to be generated
since the content is being provided from the cache. The Web server itself can enjoy a
performance boost for the same reason. After all, it takes CPU cycles to provide
dynamic content. Apache 2.2's disk-caching engine is very good and is limited only by
the speed of the disk subsystem only. In fact, in some tests, the caching engine has
been able to saturate even a gigabit Ethernet connection.
For Apache 2.2.4, the caching module has been updated to conform to RFC3986, which
states that if an address contains an authority component and an empty path, the empty
path is to be equivalent to "/". Therefore, http://example.com, http://example.com/,
©2007 CNET Networks, Inc. All Rights Reserved. 4

http://example.com:/, and http://example.com:80/ are all equivalent URLs.

Apache 2.2.4's mod_cache module also fixes a bug in which dates in the past could be
used for a request's expiration. By using a date in the past, mod_cache would cache the
URL 100 percent of the time, and the bug could lead to errors when Apache was used
on Windows servers.
The addition of proxy load balancing for the Apache 2.2 release provides a simpler
way for organizations to implement a more highly available proxy service that is not
dependent on a single-server solution and does not require the installation of third-
party tools. Apache 2.2's proxy service provides support for the HTTP/0.9, HTTP/1.0
and HTTP/1.1 as well as for SSL traffic, AJP13 and FTP. The fact that the proxy serv-
ice supports SSL makes Apache extremely viable as a reverse proxy solution.
The load balancer's role is to distribute the load between multiple servers, a job that
Apache 2.2 handles in a couple of different ways: request counting and weighted traffic
average. Request counting simply counts requests and distributes them until they have
each load balance member has served an equal number of requests. Weighted traffic
works similarly, but individual members can be weighted so certain ones handle more
requests than others.
Other improvements in Apache 2.2's proxy-handling features include connection pool-
ing and failover capability, making Apache a choice for enterprise-grade applications.
Filtering improvements
Apache's filtering module, which provides you with the ability to make changes to
the way that Apache handles certain tasks related to the traversal of data to and from
the server, has also undergone a transformation in Apache 2.2. Called Smart Filtering,
it does away with dependencies and ordering problems that were inherent in the inflex-
ible filtering model offered by older versions of Apache.
Instead, the new filtering system provides dynamic configuration capabilities by
enabling filters to be conditionally inserted into the filter chain. This conditional pro-
cessing allows Apache to process different content types through different filters, even
when Apache can't tell what kind of content is being handled. Previously, filters were
added in a static, serial way, and each filter had to make a determination whether or not
to run and all filters had to be evaluated. Under the new model, the filters can be
dynamically configured based on the outcome of a filter handler.
Configuration files changes

If you've used Apache at all in the past, you're well aware of what it takes to main-
tain the one-size-fits-all httpd.conf configuration file. Some people find it intuitive and
easy to handle, while others long for a GUI while they try to find the entries to define
a new virtual server. While Apache 2.2 is also capable of working with the single
httpd.conf configuration file, out of the box (or off of the Internet, in this case), this
new release breaks the configuration file up into a number of files, each focused on
one particular area, such as virtual servers, SSL configuration, or user home directories.
Regardless, the httpd.conf file is still used, but may have just a few server-wide configura-
tion parameters along with a number of "Include" directives that load other configura-
tion files. The httpd.conf file now contains only essential information, with configuration
settings for more advanced features being located in the /conf/extra directory.

Authentication
The Apache 2.2 developers have reworked much of the server's authentication func-
tionality, resulting in a number of changes to modules and configuration directives. In
short, Apache 2.2 separates the authentication and authorization functions of Apache
and provides an easier means by which to develop new authentication back-ends.
The module named mod_auth has been broken up into four new modules:
X mod_auth_basic : Allows the user of HTTP Basic Authentication.
X mod_authn_file : Provides the ability to authenticate users through the user of plain-
text password files.
X mod_authz_user : Allows a user to be granted access to or denied access to particular
sections of the Web site. If the user is listed in a "require user" directive, access is
granted.
X mod_authz_groupfile : Provides similar services to those offered by mod_authz_user,
but works on group membership instead.
The LDAP authentication module, mod_auth_ldap had been renamed to
mod_authnz_ldap.
Note that each module's name includes "auth", "authz", "authn", or "authnz" some-
where. Each of these means something:
X auth : Anything that has to do with HTTP authentication.
X authn : A back-end authentication system. These kinds of modules help to verify that
someone is who they claim to be. In most cases, this consists of the user providing
a username and password, but could also be accomplished through the user of a
smartcard, or some other means.
X authz : An authorization module. Authorization takes place after a user has been
identified by an authentication system and determines whether or not that user is
permitted access to a resource.
X authnz : A module that uses both authentication and authorization.
If you're upgrading from 1.3, or 2.0 to 2.2, and you're using authentication/authori-
zation, make sure to read upgrade docs before you take the plunge, as the httpd.conf
directives related to these services have changed significantly.
Other items of note

There are a few miscellaneous items that were also changed in the Apache 2.2
branch, some of which may create problems if you don't do a little research and test-
ing before upgrading. Here are some more improvements and changes that have been
made in Apache 2.2. Take note of the changes, as they could be potential gotchas dur-
ing an upgrade.
X Almost all Apache 2.0 modules are source-compatible: This means that, in
many cases, modules created for Apache 2.0 will just need to be recompiled in order
to work with 2.2.
X Large file support (up to 2 GB): A new addition, along with support for request
bodies greater than 2 GB.
X New command line parameter: -M: Lists all loaded static and shared modules, as

seen in Figure A.
X New command line parameter: The -l (that's an "el") parameter has always been
able to list modules compiled into the server, but does not include dynamically
loaded modules included using the LoadModule directive in httpd.conf. You can see
this in Figure B.
X Mod_imap has been renamed mod_imagemap : These kinds of changes actually
improve the usability of the product by reducing what could be significant confusion.
X SSL support is no longer included by using apachectl startssl: Instead, add the
necessary SSL directives to http.conf and just use apachectl start. Note that an example
configuration files, conf/extra/httpd-ssl.conf, has been included to help you in this.
X The default setting for the UseCanonicalName directive is now off: A self-referring
directive will now be constructed using the hostname and port supplied by the client. If
you would rather have a self-referring directive that is built using the value in httpd.conf's
ServerName directive, include a line in http.conf that reads "UseCanonicalName On".
Summary
Even though Apache 2.2 isn't the massive upgrade that 1.3 to 2.0 was, there are a
number of modifications and improvements that make this latest release worth consid-
ering, particularly if you want to use Apache's proxy or caching features. Apache 2.2.4
builds on the overall 2.2 release and rolls up all of the bugs fixes and minor enhance-
ments that have been introduced to the product since the 2005 release of Apache 2.2.
Figure A Figure B
The -M parameter lists all loaded static and shared The -l parameter shows you the modules compiled
modules. into Apache.

Setting up a simple Web site

with Apache 2.2.4
W
ith the release of the 2.2 branch of the Apache Web server, the Apache
group has improved upon an already outstanding service. If you're in the
market for a new Web server, or are interested in putting Apache 2.2.4 -- the
latest version as of this writing -- through its paces, it very easy to create a simple
Apache site on either Windows or Linux.
Linux
The installation of Apache 2.2.4 on Linux can be handled in almost unlimited different
ways, some dependent on your preferred Linux distribution. For example, if you're a Red
Hat or Fedora fan, RPM is your best choice. If you're using some other distribution, you
may be able to use RPM, or your distribution may have its own package format.
If you're installing your Linux server from scratch, you can usually choose Apache as
an installation option. If you have this option, take it, unless you need something
unusual in your installation.
If you're using an existing server and don't want to reinstall the OS, or if you want
to have the most granular control over how your Apache installation is configured,
your best bet is to build Apache from source code. If you're somewhat new to Linux
and the sound of this makes you nervous, it's actually a whole lot easier than it sounds.
Better yet, this option works on any Linux distribution out there. It even works for
Windows if you have an appropriate compiler installed.
For the example installation in this section, I'm going to build Apache 2.2.4 from
source and install it on a Fedora 7 installation. You won't see anything fancy in this
build -- just the basics will be included -- but your Linux server will be serving Web
pages in just minutes.
Note: Although I could have just chosen the "Web server" option when I installed
Fedora, that would have defeated the purpose of this article.
Before you can compile Apache, you need the source, which is available for down-
load from the Apache Web site. As of this writing, the latest version of Apache
available is 2.2.4. I've saved the file, named httpd-2.2.4.tar.gz to a folder named
/usr/src/apache-2.2.4 on my server. I like to save installations in this location so I have
them for the future.
The next few commands are entered from a command line. I've put them, in order,
in Table A.

Table A
cd /usr/src/apache-2.2.4 Change to the directory to which you saved the
Apache source download.
tar -zxvf httpd-2.2.4.tar.gz Extract the contents of the downloaded file into a
subdirectory named httpd-2.2.4.
cd httpd-2.2.4 Change to the new source directory.
./configure --prefix= Install the Web server to the directory identified

/usr/local/apache by the prefix directive. This step may take quite
some time, as the installer checks for a number
of items on your system. I'm not including any
other directives, but note that a standard Apache
installation automatically includes a number of
modules that, if you don't want, you need to indi-
vidually exclude. Further, there are a number of
modules that are disabled by default that have to
be specifically included if you need the feature. A
complete list of what is included and excluded is
listed in Table B.
make Compile Apache.
make install Copy the newly compiled binaries to the

/usr/local/apache directory/ (and to other places
on your system, as needed).
/usr/local/apache/bin/apachectl Start Apache with its default configuration file.

start
When you're done with the steps in Table A, browse to your new server. You should
get a "It works!" message, as shown in Figure A.
Before you do too much, you should configure Apache to automatically start when
your system boots. The steps to make this happen depend on which Linux distribution
you're using. Please refer to your system docs for more information. Until you get that
set straight, use the "start" command in the last part of Table A.
Table B (page 39) lists the various modules available for your control during the ./configure por-
Figure A
Apache was successfully installed.

tion of the instructions in Table A. I've indicated whether a module is enabled by

default or disabled by default, the module name, the configure directive you need to
use to enable or disable the module and an explanation of the module, and linked it to
the official Apache documentation page. I gathered this information from the Apache
2.2.4 documentation site and reformatted it to be easier to read.
Installing Apache 2.2.4 on Windows

The Windows installation of Apache is substantially easier than installing Apache
from source under Linux. While you can install Apache using source under Windows,
how many Windows administrators do you know that actually do this? Yeah … I don't
know any either.
The Apache group provides a Windows MSI installer version of their Web server
just for the purpose of easily installing under Windows. Before you get started, make
sure that you don't have IIS installed on your server. If you continue with IIS installed,
Apache will not be able to listen for requests on port 80. You can run Apache and IIS
side-by-side if you want to run one of the products on a port other than 80 or if the
two products listen to different IP addresses.
After you make sure IIS is removed from your Windows server, download the
Apache Windows binary. As of this writing, the latest edition of Apache for Windows
is 2.2.4. I've downloaded the file named apache_2.2.4-win32-x86-no_ssl.msi. As you can
probably guess, this is a basic Apache build without SSL support, which will suffice
perfectly for a simple Apache site.
After download, execute the MSI file and follow the on-screen instructions.
The first screen you get provides you with an introduction. Press the Next button to
move on. And, of course, there is the obligatory license screen. Accept the license and
press the Next button to continue with the installation.
Next, provide the Apache installer with information about your server, including your
network domain, the server name, the e-mail address of a server administrator, and decide
how you want to run the Apache Web server service, as shown in Figure B. If your server
is joined to a domain, most, if not all, of this information will be filled in. Otherwise, you
will need to provide this information for the Apache installer. Where possible, stick with
the defaults. If you plan to run Apache only for testing, run "only for the Current User."
Now choose your installation type. While a Typical installation is perfectly fine, I chose
to perform a Custom installation in order to demonstrate your installation options.
By default, everything on the Custom screen is selected for installation and the serv-
er is installed to C:\Program Files (x86)\Apache Software Foundation\Apache2.2\. If you
want to change the installation path, press the Change button and choose a new path.
Note that, since I am installing Apache to a server running Windows Server 2003 x64,
the path indicates "Program Files (x86)." If this was a 32-bit Windows installation, the
path would simply read "Program Files."
Once you've made your selections, the Apache installer gives you one final chance to
bow out. If you're ready to forge ahead, press the Install button.
After the installation options screen, the installer does its job and installs Apache
using the options you provided. When you're done, open a Web browser on another
system and point it to your new Apache server. You should get a test page that says "It
works!" just like you saw in Figure A.

Adding and modifying pages

Congratulations on getting your Linux- or Windows-based Apache server up and run-
ning. Now I'll go over how you can add new and edit current pages on your site. After
all, you probably don't want to keep the sample pages around for a production site.
As you start adding pages, you'll need a decent editor to make changes to the HTML
files. You could use something like FrontPage, but if you want to keep things simple,
you can just use a text editor. Under Linux, I usually use pico or nano for this purpose.
For Windows, I've fallen in love with the open source Notepad++.
To add or edit pages on your site, you need to know the location of your document
root, the folder in which all of your Web pages are stored:
X 64-bit Windows: C:\Program Files (x86)\Apache Software Foundation\Apache2.2\htdocs
X 32-bit Windows: C:\Program Files\Apache Software Foundation\Apache2.2\htdocs
X Linux: /usr/local/apache/htdocs
Make sure that you give any files you create an extension of .html so Apache knows
how to handle them. Apache is very dependent on the extension to determine which
module should handle a file.
As an example, on my Windows system, I've created a file in the C:\Program Files
(x86)\Apache Software Foundation\Apache2.2\htdocs folder named tr-test.html with the con-
tents "TechRepublic test."
Figure B
All of this information is filled in for you.

Managing Apache
In this article, I won't be going too deeply into managing an Apache configuration
file, but will provide you with some general tips. First off, Apache, under both Linux
and Windows, is managed through the manipulation of the file named httpd.conf. These
files are located here:
X 64-bit Windows: C:\Program Files (x86)\Apache Software Foundation\Apache2.2\conf
X 32-bit Windows: C:\Program Files\Apache Software Foundation\Apache2.2\conf
X Linux: /usr/local/apache/conf/httpd.conf
Httpd.conf is a long text file full of directives that tell Apache what to do. For exam-
ple, on both servers, the httpd.conf file has a line that reads "Listen 80." This directive
tells Apache to listen on port 80 for incoming requests. Going through the various
directives is beyond the scope of this article (I will go over the possible options in a
future article). However, after you make changes to the file, you need to restart the
Apache service. To do this:
X In Windows: Click Start | Control Panel | Administrative Tools | Services. Locate
the Apache2 service and click the Restart button.
X In Linux: execute the command:
/usr/local/apache/bin/apachectl restart
Summary
For a simple site, this is all you really need to know to get up and running. Once you
get used to it, Apache is very easy to work with and provides an outstanding platform
for robust Web development and page serving. As you get into more advanced tech-
niques, such as scripting languages and database access, you'll come to appreciate
Apache's flexibility.

Make the move from

IIS to Apache 2.2.x
E
ver since Netcraft has started tracking statistics regarding Web server usage, IIS
has never beat Apache when it comes to the number of sites using the two
servers. In general, the gap between IIS and Apache has been anything but
small. Until fairly recently, early 2002 saw Apache's worst day with only a 30% gap
between the two products. Today (in mid-2007), however, Apache's share (52.65%) is
very slowly eroding in favor of IIS (32.8%), which is bundled with the ubiquitous
Windows OS. Of course, these statistics take into consideration all of the free and
cheap hosting services that use Apache and don't consider internal use of IIS in many
companies, so the "real" values are likely more similar than they appear.
Even so, 20 percent is still a fairly significant gap! There are a number of reasons that
your company might consider making the jump from an IIS solution to Apache. I'll quick-
ly explain some of these reasons and then go over some of the ramifications of such a
decision and provide some advice for mitigating problems related to this kind of a move.
The focus of this article is on moving from IIS to Apache. As such, I'm not going
to spend a lot of time balancing the argument. While I personally consider both IIS
and Apache to be worthy products, in this article, I'm not arguing for either option, but
letting you know some things you may run into as a part of a transition.
Why change?
IIS is a good Web server, and it's getting better with each new version. Moreover, with
each new release, Microsoft improves the security of IIS, making the case for change a
little less compelling. And, for some organizations -- particularly those that have a heavy
reliance on other Microsoft tools -- a change would simply not make any sense.
Given these facts, why make a jump from a perfectly good Web server to Apache?
For those of you that do not have tools -- such as Exchange Outlook Web Access,
SharePoint or SQL Server Reporting Service -- that are tightly tied to IIS, are there
compelling arguments for making the leap?
The answer: If you have a need to operate in a heterogeneous environment, and
have a need to choose a single Web server to use across all platforms, you simply can't
beat Apache. The lines have blurred with regard to other issues that used to set Apache
apart from IIS, including the security and manageability of the servers.
Another answer: If you need to implement a significant Web service and want to be
able to do so with a minimal license cost, consider Apache on Linux for your solution.
The direct licensing cost for this solution is exactly zero dollars, unless you choose to
make use of a commercial Linux distribution.
For argument's sake, I'm going to assume your organization has made the decision
to at least consider moving from IIS to Apache and you want to know what to expect
should you decide to begin an actual migration.
Plan for ASP

One significant hindrance to migration efforts from IIS to Apache lies with the issue
of dynamic scripting language choice. For most Windows Web environments, ASP or

ASP.NET is the language of choice since both are very well-supported and included
with IIS. Unfortunately, both are native to Windows, and Microsoft has not moved
them outside this playground. However, there are numbers of ways that you can still
make the move to the open source Apache/Linux combination (or Apache/Windows,
for that matter).
Change to another language
If you only use ASP casually on your site, you can opt to migrate your ASP code to
another language, such as PHP. With smaller sites, this is probably best handled manu-
ally, but for larger sites, the prospect of converting code could be a major undertaking.
However, there are some tools available that can help you with a conversion. For exam-
ple, asp2php is a free tool that can help you make this leap. While this free tool is
only provided to help you make the move (it doesn't do it all, by any means), it can help
you avoid some of the tedious task of recoding hundreds of pages of code.
Also, consider the use of a Java-based framework for a site if you decide to take the
plunge and migrate to another language. Apache's Tomcat provides you with a free,
open source servlet container to help make this change.
If you do decide to make the jump to a new language, remember that it's not the
syntax that was difficult to write in the first place, but the logic. Since you already have
the logic completely documented in your ASP code, migrating to another language isn't
generally as difficult as starting anew.
Keep ASP and still run Apache
One great thing about open source and an open market is that for just about any
need, you can find a reasonable solution. In the case of continuing to run ASP code
after moving to Apache, there are many solutions available for you to peruse.
The most well-known solution, Chilisoft ASP, is now a product from Sun called Sun
Java System Active Server Pages 4.0 and provides ASP support for certain versions of
Solaris, Red Hat Enterprise Linux, HP-UX, AIX, and Windows (without IIS, of
course). Sun Java System ASP 4.0 supports Apache 1.3 and 2.0 (see below for informa-
tion about Apache 2.2). Sun's solution also provides ADO support, as well as a full line
of ODBC database drivers for use with the product. Among the ODBC database driv-
ers included are drivers that allows Sun's product with work with both SQL Server and
Microsoft Access databases. As with anything, a conversion process using this software
is probably not going to be 100 percent perfect, and you may need to make some
minor code changes to make everything work exactly as you expect; there are some
instances -- if you use Visual Basic objects, for example -- in which this solution won't
work at all.
Alas, the data sheet for Sun Java System Active Server Pages does not include
Apache 2.2 as a supported Web server. Further, Sun Java System Active Server Pages
has not been updated in quite some time; and, in a forum, it was indicated that there is
no time frame for a future release. This could mean that either Sun just hasn't gotten
around to planning an update, or that they bought Chilisoft's product and are no
longer updating it.
Another option is to use Apache's mod_perl module and a perl-based solution called
Apache::ASP. This is not as clean of a solution as others, so do a lot of research
before you decide on this free solution.

If you decide to scrap your IIS --> Apache project, one major reason will likely be
dealing with ASP or .NET Framework applications that run great under IIS.
Learn a new management style

If you're an IIS guru, the Internet Services Manager has probably become a familiar
tool for you. In IIS 6.0, the Internet Services Manager manipulates the XML-based IIS
metabase. What Apache administrators have been able to enjoy for a very long time is
the manipulation of server configuration files using nothing more than a text editor.
While this is possible in IIS 6.0, it's far from a well-known fact! In versions of IIS prior
to IIS 6.0, the metabase was a binary file that required special tools to manipulate.
Apache, on the other hand, uses simple, (usually) readable, plain-text configuration
files to handle 100 percent of its configuration. When you need to change the path of
your server's document root file, you just load up httpd.conf (Apache's main configura-
tion file) into a text editor, look for the DocumentRoot directive and change the path.
It's a big plus that you don't need any special tools to make configuration changes
to your Web server. GUI-based tools, at times, can make the reconfiguration job more
difficult.
Second, for a production Web server, the corruption of a single file should not
result in an unusable Web server. While you always need to back up configuration files,
it's easier to back up the contents of a text-based configuration file in multiple places.
For example, for Apache, you can print the contents of your httpd.conf file after you
make changes.
On the flip side of the complexity equation, if you do like Apache's text-based
approach, you'd be prudent to install some kind of versioning system so that you can
easily track changes made to these files. That's one thing you don't really have to con-
tend with under Windows, since it's a little harder to make mistakes that bring the sys-
tem down that you have trouble finding later on.
Note: The upcoming IIS 7.0 (coming with Windows Server 2008) will drastically
change the way IIS is managed, and will support text-based configuration files, a la
Apache. The jury is still out on how successful this endeavor will be, but we'll all find
out soon after Windows Server 2008 is released.
Of course, Windows admins are very used to GUI-based management tools, so con-
verting to a text-based approach may require some time and training. Make sure to
allow yourself enough time to become familiar with Apache's various directives and
commands.
Go modular
There's a module for PHP, a module for Perl, a module for MySQL, a module for
this and a module for that. Simply put, Apache is nothing if not incredibly modular.
The Apache approach is this: Install only what you need and nothing else. This serious-
ly reduces the attack surface of the Web server and also improves performance. Yes,
you can disable certain IIS services, particularly under IIS 6.0, but a default IIS 6.0
installation is still less efficient -- and more prone to attack -- than a default Apache
installation.
What do you need to learn here? First off, everything in Apache is handled through
some kind of module. Want database access, scripting, or proxy services? Get a mod-

ule. This is definitely a good way to handle this kind of service, but Windows adminis-
trators may not be used to the flexibility offered by a system like Apache. There are
hundreds of modules available that help you make Apache do new and interesting
things.
For example, with IIS, you're somewhat limited with your authentication methods.
With Apache, as of this writing, there were 74 modules listed on the Apache Module
Registry that are all designed to extend Apache's authentication methods to other sys-
tems, including PostgreSQL databases, IMAP servers, LDAP directories, NT servers,
Oracle databases, and a whole lot more.
In total, the Apache Module Registry has well over 400 modules, all designed to help
Apache help you meet your goals.
This brings up the issue of how you handle direct connections to things like
Microsoft SQL Server, which is commonly used with IIS. An open source implementa-
tion called FreeTDS provides your Linux or IIS-less Windows Server with the capability
to continue to communication directly with SQL (or Sybase) servers.
Or, while you migrate from IIS, you could also consider migrating to a lower cost
database such as MySQL or PostgreSQL.
Note: IIS 7.0 is also supposed to "go modular," a la Apache.
As for other modules, such as IIS-specific ISAPI modules, you will need to migrate
these to something that works outside of IIS, such as NSAPI. Apache does include the
mod_isapi module, which provides basic ISAPI extensions, but not support for ISAPI
filters.
Understand platform differences

Default.htm vs. index.html. The difference is subtle, but will bite you if you don't notice
it. Apache's default document is "index.html" whereas IIS uses "default.htm". Further,
Windows systems use path names with backslashes, while Linux and UNIX use normal
slashes.
As you migrate your site, make sure to be aware of platform differences and adjust
appropriately. I would recommend adding another default document named
"index.htm" to your Apache configuration file and also allow Apache to process files
with both ".htm" and ".html" extensions.
The birds-eye steps

The migration from IIS to Apache is not trivial, but it can be broken down into just
a few high-level decision-making steps.
Decide on a platform
The good news: Apache runs on practically anything you have. Run it on Windows,
Linux, UNIX, or NetWare, and it will work.
The bad news: This makes your decision about where to run Apache a little more
difficult.
After all, with IIS, your platform decision was made for you. With Apache, you're
free to choose to run Apache anywhere you like. The answer to this question lies in
your overall environment. If you're open to trying open source in your environment,
or you're trying to move to open source, consider Linux. If you're only moving away
from IIS for security reasons, consider sticking with Windows.

Decide the future for scripting in your organization

If your IIS servers use ASP, I recommend you try Sun's ASP server product. It does
a surprisingly good job at working with your ASP code on any platform. However, be
wary, since Sun may not be taking development of this platform seriously, particularly
since they've indicated that version 4.0.3 is slated for release in late 2007. Version 4 was
announced two or three years ago.
If you're not doing any scripting yet and are serving just static pages, this point is
moot; but if you do, look for something pervasive, like Java or PHP.
Choose your database
While there is no reason to move off SQL Server, if you're in an organization com-
mitted to moving off closed-source products, consider the use of MySQL or
PostgreSQL for your database needs. I've used PostgreSQL for some significant data-
bases and have directly migrated SQL Server databases to the product, and have found
it to be a very worthy replacement.
Find modules
Does your IIS server authenticate users against Active Directory? You'll need
Apache's mod_ldap. Go through your entire site and ask yourself exactly how it works,
and locate the Apache modules that you will need to support your business.
Install, migrate and test!
Once you've made all of your selections, install your new servers, install the supporting
services, such as Apache modules or Sun ASP, migrate your code, and test it thoroughly.
Summary
As you would expect, any conversion like this can't be broken down into two or
three steps and called good, except for the simplest of sites. Decide if it's worth taking
the plunge, and then plan your strategy very well. With Apache's wealth of support
resources, you will probably be able to conquer any problem that comes your way.

Troubleshoot Apache with these tips
A
s a community supported project, the open source Apache Web server is well-
proven, but can still offer an administrator headaches from time to time when
things don't go quite as planned.
In this article, I will provide you with ten tips to help you solve the most common
Apache dilemmas.
Stay current with Apache releases

The Apache group regularly releases updates that correct bugs or improve potentially
undesirable behavior. If you are having a particular problem with your Apache installa-
tion, look at the changelog for the latest version to see if your problem is addressed.
Even if your problem is not specifically addressed, it's good practice to stay current
with software updates as many changes will also improve the security of your system.
Know where to find Apache community resources

You're probably not the first person to run into a particular problem. The Apache
Foundation has established a troubleshooting wiki that is updated with new information
as situations arise. Further, Apache has an array of pretty good official documentation.
There are also a number of Web forums that focus specifically on Apache. These forums
include www.apacheforum.com and www.webmasterworld.com/apache.
With that said, the Apache community is huge, and there are a ton of places to go
for help when you have a problem. In my Apache experience, I've used TechRepublic
and other professional sites, but my first stop is Google. Type in the exact error mes-
sage or symptom, and the chances are really good that you'll get some hits back.
Failing that, here are some other outstanding resources that you can use for help:
X Apache support WebRing: This is the main page of the Apache support
WebRing that houses a plethora of information about Apache and provides a place
to start when trying to solve a difficult problem.
X IRC channel #Apache: This is an IRC room with live Apache experts that, if you are
patient, are willing to help you through a problem. When using this resource, make sure
to understand that these folks do this out of the goodness of their hearts, so be thankful.
Know where to look

If you're having trouble with Apache or one of its modules, your first stop should
be in looking over Apache's detailed error log. Depending on how your system and
Apache are configured, the error log may live in different locations. The default loca-
tion for this file is a file named error_log, located in the logs directory inside your
Apache root installation. If you can't find your error log, open the httpd.conf configura-
tion file and look for the ErrorLog directive, which defines the location.
Apache is initially configured to the "warn" log level, meaning that any problem
more serious than a warning (critical, emergency, error, alert, and warn) is logged. You
can adjust the logging level in httpd.conf my manipulating the LogLevel directive.
From the Apache documentation, Table A outlines the eight available warning levels
and provides an example of what would be logged at that level.

Table A
Level Description Example
Emerg Emergencies - system is unusable. "Child cannot open lock file. Exiting"
Alert Action must be taken immediately. "getpwuid: couldn't determine user name from uid"
Crit Critical Conditions. "socket: Failed to get a socket, exiting child"
Error Error conditions. "Premature end of script headers"
Warn Warning conditions. "child process 1234 did not exit, sending another SIGHUP"
Notice Normal but significant condition. "httpd: caught SIGBUS, attempting to dump core in ..."
Info Informational. "Server seems busy, (you may need to increase

StartServers, or Min/MaxSpareServers)..."
Debug Debug-level messages "Opening config file ..."
Apache's logging levels
If you can't figure out why your Apache server is having a problem, try adjusting the
log level to a higher threshold to capture more information. After you change the level,
stop and restart your server.
There are actually two log files in Apache: error_log, which I described in this section,
and access_log. The error_log file, as you might expect, is the log of most interest for
troubleshooting purposes. However, also make use of the access_log when looking for
problems. This file lists all of the items pulled down by clients along with the HTTP
error or success code.
Part of knowing where to look involves knowing what's actually running on your
server, too. Used in conjunction with the httpd command, use the -l and -M parameters
to see what is loaded in your Apache configuration. The -l (el) parameter lists modules
compiled into the server, but does not include dynamically loaded modules included
using the LoadModule directive in httpd.conf. The -M parameter does show you more
information and lists all loaded static and shared modules.
Don't allow an AllowOverride to ruin your day

Depending on how you want to run your Web site, you can selectively alter the
behavior of your Apache server by making use of .htaccess files. Simply put, an .htaccess
file is a file in a directory that lets you make configuration changes that affect just that
folder. For example, if you've disabled the "Indexes" in httpd.conf for all directories,
none of your visitors will be able to access a directory listing. You may have a single
folder for which this access should be allowed. In this case, you would have an .htaccess
file with the "Options Indexes" directive.
You can probably begin to see some reasons why .htaccess files can be problematic.
First of all, for very large sites, keeping track of these files could be a very difficult
task. Now, when you have a functionality problem, you can't just look to one source
for possible configuration problems; you now need to traverse your directory structure
and look for .htaccess files.
Second, by allowing the use of these files, you may be allowing users the lack your

Apache security prowess to make potentially insecure changes to your Web site.
Finally, use of .htaccess can exact a performance penalty on your web site due to the
need of the web server to look for an .htaccess file in the current directory and in every
superior directory all the way to the document root of the Web server.
Unless you have a really good reason, avoid the use of .htaccess files. Instead, in the
httpd.conf file, make liberal use of "Directory" sections to set per-directory options.
On the other hand, if you are using .htaccess files and they don't seem to be activated,
look to the httpd.conf file and make sure the directive "AllowOverride" is not set to
"None". You can limit what options are allowed in an .htaccess file by further manipulat-
ing the AllowOverride directive's type. Table B, based on the Apache documentation,
provides you with a list of possible AllowOverride options. Only use the options you
need.
Table B
Type Description
All Allow use of all directives listed in this table. This is generally considered to be a major
security risk since it allows users to override httpd.conf settings such as disallowing the
following of symbolic links along with other things.
None Disallow the use of .htaccess files.
AuthConfig Allow use of the authorization directives (AuthDBMGroupFile, AuthDBMUserFile,

AuthGroupFile, AuthName, AuthType, AuthUserFile, Require, etc.).
FileInfo Allow use of the directives controlling document types (DefaultType, ErrorDocument,
ForceType, LanguagePriority, SetHandler, SetInputFilter, SetOutputFilter, and mod_mime
Add* and Remove* directives, etc.).
Indexes Allow use of the directives controlling directory indexing (AddDescription, AddIcon,
AddIconByEncoding, AddIconByType, DefaultIcon, DirectoryIndex, FancyIndexing,
HeaderName, IndexIgnore, IndexOptions, ReadmeName, etc.).
Limit Allow use of the directives controlling host access (Allow, Deny and Order).
Options Allow use of the directives controlling specific directory features (Options and XBitHack).
AllowOverride types
A newly installed module/extension

(such as PHP) is not working
Suppose, for example, that you recently installed the PHP extension, but, upon visit-
ing your site, you're seeing the PHP code itself instead of the results of that code's
execution. First off, for folks new to Linux, installing new modules and getting every-
thing working perfectly can be akin to setting up a Christmas tree with your hands tied
behind your back.
Since it's among the most popular available, let's use the PHP module for an example.
Your problem could be something very simple. Apache may not be configured to do
anything with the .php extension. Look at your httpd.conf configuration file and look for

the DirectoryIndex directive. Make sure the line reads:

DirectoryIndex index.html index.php
The default Apache installation omits the "Index.php" file, rendering many PHP-
based sites useless.
Further, your httpd.conf file needs to tell Apache about the .php extension through
the use of the AddType directive. If you're using PHP, you should have a line in your
configuration that reads:
AddType application/x-httpd-php .php
Normally, this line is commented out.

Finally, make sure your httpd.conf file is actually loading a supported PHP module. If
you're not loading the PHP handling module, Apache won't know what to do with
.php pages, no matter how many AddType directives you include. Here is an example
LoadModule directory for PHP 4.
(Apache 2+) LoadModule php4_module modules/libphp4.so
(Apache 1.3) LoadModule php4_module libexec/libphp4.so
Apache 1.3 also requires a fourth directive:

AddModule mod_php4.c
If this still isn't working, make sure your module is compatible with the version of
Apache you're running. The PHP developers, for example, recommend that, for
Apache 2 and later, you use at least PHP 4.3.0.
The short answer: Make sure you've strictly followed the instructions for setting up
Apache with additional modules. I've highlighted some of PHP's requirements in this
tip, but every module has its own nuances.
Don't worry about ‘connection reset by peer’ errors

When a user cancels a request to your site (presses the Stop button or hits Escape),
your server logs will be appended with the message "connection reset by peer". If you see
this message only occasionally, it probably means someone typed in the wrong address or
just got impatient while waiting for your site to load. If you're seeing this message on a
regular basis, you might have congestion issues slowing your site to a point beyond the tol-
erance of some people. You may have other network issues creating this problem.
Make sure Apache is actually running

I'm going to confess; this one has gotten me in the past. I spent quite some time
looking through error logs and the httpd.conf file before I even bothered to make sure
Apache was running. After reprimanding myself, I started the service and, until today,
have never told a soul.
The point: Any day can be an off day! Look for the simple things, too.
Check for port conflicts

If you've installed Apache with the defaults, the httpd service listens on port 80 for
traffic. If you have some other services -- perhaps a different Web server -- also listen-

ing on port 80, Apache will not be able to listen to requests (or, Apache will work fine,
but the other application will be broken). In these cases, make sure Apache is the only
service listening on port 80.
A combination of the fuser and ps commands handily accomplishes this goal.
Use the command fuser -n tcp 80 to get a list of processes that are listening on port
80. Then, use the ps command to see which processes are used by the httpd daemon. ps
-ef | grep httpd accomplishes this part. You'll see results similar to those in Figure A.
Now, match up the list of ports provided by the fuser command and those provided
by the ps command. If there are more ports listed by fuser than are accounted for by ps,
use the ps command to find out exactly which other services are listening on port 80.
Use configtest
So you've made some modifications to your httpd.conf file and now Apache isn't
working properly, but you don't have a handy backup of the original file to find out
what's wrong?
Well, the good folks that created Apache have provided you with a way to scan your
httpd.conf file and make sure it's free from obvious errors. This error-checking tool is
provided as a part of the apachectl program. To use it, execute apachectl -configtest from
the command line. The apachectl program is located in the bin directory of your Apache
installation.
If no errors are found, the utility will execute like this example:
[root@localhost bin]# ./apachectl configtest
Syntax OK
To show how this tool works, I've intentionally create an httpd.conf file with an
error or two.
Syntax error on line 22 of /usr/local/apache/conf/httpd.conf:
Invalid command 'sserversignature', perhaps misspelled or
defined by a module not included in the server configuration
Figure A
Show which processes are listening on port 80.

In this case, I have misspelled a directive, which should read "ServerSignature", not
"SServerSignature". Even if you correct the error, run the tool again as more errors
may be found. As a highlight to this, I actually had another error in my httpd.conf file.
Syntax error on line 108 of /usr/local/apache/conf/httpd.conf:
DocumentRoot must be a directory
In this case, the directory name in the DocumentRoot directive also had a spelling
error which would have resulted in Apache being unable to serve any content since the
directory does not exist.
The apachectl program has a number of options. You've probably used "start" and
"stop", but there are many more that may be useful, depending on what you're trying
to do. Some of the options you can use with apachectl include:
X configtest : Checks for errors in httpd.conf.
X fullstatus : (Requires mod_status) Provides you with a configuration report at the loca-
tion specified in the module's httpd.conf configuration.
X Graceful: Restarts Apache, maintaining current connections.
X Restart: Restarts Apache, killing all connections.
X Start: Starts the Apache server.
X Status: (Requires mod_status) Same as fullstatus, except omits details of current
requests.
X Stop: Stops Apache.
Understand the various HTTP/1.1 error codes

Specific HTTP errors on a client or in your server logs can help point you in the
right direction. For example, if you have users complaining that they always get "404"
errors when they click a link to visit your site, the host link is pointing to a page on
your Apache server that does not exist. Or, if a client receives a "501" error, the client
is attempting to access content on your server for which no handler exists. Often this
error can be the result of a problem with a CGI script. The W3C is the organization
responsible for keeping HTTP error messages consistent.
Summary
Will these ten tips help you solve all of your problems? Probably not, but these tips
were designed to help point you in the right direction to solve problems.

Ten tips for securing Apache
O
ne of the reasons Apache powers over half of the world's domains is its
track record when it comes to being a safe and secure Web operating envi-
ronment. The Apache group has done a great job at keeping its product safe
and, at the times when the product has been found to have a defect related to security,
the Apache group gets a patch out as quickly as possible.
However, even with Apache's focus on producing a secure product, the Web server
can still be vulnerable to any number of attacks if you fail to take some security pre-
cautions as you build your server.
In this article, I will provide you with 10 tips that will help you keep your Apache
Web server protected from predators. Bear in mind that you need to carefully evaluate
each of these tips to make sure that they are right for your organization.
Harden your operating system and keep it current

If your operating system is not properly installed and secured, or you have failed to
keep current on OS security releases, your Apache installation could be compromised
through an avenue totally unrelated to the Web server itself. Keep up to date on all
security patches and services packs.
Further, take recommended steps to harden your operating system. In most cases,
this means only installing services that are absolutely necessary for your system, turning
off unnecessary protocols, using ACLs to define what kind of traffic can get to the
system, and from where that traffic can originate.
Also make sure your server runs antivirus and antispyware software and that these
software packages are kept current.
Beyond the OS, make sure that your network is well-protected with a firewall and
appropriate intrusion detection systems are in place.
Install only what you need

One of Apache's greatest strengths -- its flexibility and sheer number of installable
modules -- can also be a great weakness when it comes to security. The more you
install, the larger attack surface you create for a would-be hacker. A standard Apache
install includes more than twenty modules, including CGI capability, and some authen-
tication mechanisms. If you don't plan to use CGI and you're only going to use a static
site and don't need users to authenticate, you may not need any of the services offered
by either of these modules, disable these modules at the time you install Apache.
If you've inherited a running Apache server and do not want to reinstall it, go
through the httpd.conf configuration file and look for lines that start with
LoadModule. Check the Apache documentation (or Google) to find information about
the purpose of each module and comment out the modules that you don't need.
Afterwards, restart Apache.
Less disclosure equals less information for a hacker

You know by now that Apache is helpful. After all, it's easy to install and fairly easy
to administer. Unfortunately, many Apache installations tend to be too helpful by pro-
viding perfect strangers with information about your server, such as the Apache ver-

sion number and information related to your operating system. With this information,
a potential hacker can go after specific exploits that may affect your system, particularly
if you haven't been able to stay current with all patches. Now, instead of a hacker's
exploit attempt being handled by trial and error, he knows exactly what you're running
and he can tailor his attack.
To help keep your server from broadcasting sensitive information, make sure the
"ServerSignature" directive in httpd.conf is set to "off". As a note, a default Apache
installation sets this directive to off by default, but many administrators enable it.
Figures A and B show you the result of changing this directive.
Likewise, it's a good idea to disable directory browsing. When directory browsing is
enabled, users that browse to a directory that does not contain a default document are
Figure A
This is a sample 404 page when you have ServerSignature set to 'on'.
Figure B
This is the same page, but the ServerSignature directive is set to 'off'.

instead provided with a complete list of the contents of that directory. While you
shouldn't store sensitive materials in plain text on a Web server unless you have to, you
shouldn't allow people to see more than they need.
Directory browsing is enabled by default. To disable this feature, edit the httpd.conf
file; and, for each "Directory" directive, remove the "Indexes" reference.
For example, on my lab Apache 2.2.4 server, this is the default Directory directive:
<Directory "/usr/local/apache/htdocs">
Options Indexes FollowSymLinks
AllowOverrride None
Order allow,deny
Allow from all
</Directory>
Remove the Indexes reference so that this reads:

Options FollowSymLinks
AllowOverrride None
Order allow,deny
Allow from all
</Directory>
You can also leave the Indexes directive and precede it with a dash to disable the
directive (i.e., "-Indexes").
Figures C and D show you the results of this change.
Figure C
This is a sample folder on a server for which directory browsing is allowed.

Run mod_security
Mod_security, an Apache module written by Ivan Ristic, provides Apache with a
front-end firewall through which all incoming requests are filtered before being sent on
to other Web server modules. Among other features, mod_security includes:
X As indicated above, powerful request filtering that also works for HTTPS traffic.
X Anti-evasion techniques, such as the removal of null bytes (%00), multiple slashes,
etc., from URLs.
X Identity obfuscation. The identity of the Web server can be changed to thwart hackers.
X Full audit logging for future analysis if necessary.
Among the reasons that mod_security was developed was to protect servers prone to
SQ injection attacks from being compromised and databases lost. Under a SQL injec-
tion attack, SQL code is passed to a database process via a URL. If proper precautions
aren't taken, an Internet miscreant could send a command such as "DROP DATA-
BASE" through a URL string and render a Web site useless in a matter of seconds.
Mod_security does much more than what I've outlined here. Follow the link above
to visit the mod_security Web site for a more thorough overview of this module.
Run Apache as a non-privileged user

Under Apache 2.2.4, the default Apache installation sets the User and Group direc-
tives in httpd.conf to daemon (a good change). In older versions of Apache, these values
were often set to nobody, which, under certain situations, can have significant security
implications, particularly since other services often run as this user as well. Depending
on who you talk to, use of the nobody account for running services and for owning files
can go either direction.
So, change it.
Figure D
This is the same folder with the Indexes directive removed.

Generally, administrators that decide to take this step create a user and group on
their Apache server named "Apache", and the Apache service runs under this account.
Files related to the web site are then made readable by this account.
To make this change, open the httpd.conf file and change the contents of the User
and Group directives to "Apache", or the account name you have selected.
You will likely need to also make changes to the file permissions and ownership of
the files in your Apache directory as well.
Disable the following of symbolic links

If you're the only person proving Web content to the world -- and you rarely make
mistakes when you create new symbolic links -- you may not have to worry about this
step. If, however, you have many people adding content directly to your site, and they
are not as savvy as you, there is a risk that a user may accidentally create a symbolic
link to a part of your file system that you really don't want people to be able to see.
For example, what would you do if someone, in your Apache server's document root
directory, created a symbolic link to the "/" folder?
To disable the ability for Apache to allow users to follow symbolic links in their
requests, remove the FollowSymLinks directive on your Directory commands.
For example, on my lab Apache 2.2.4 server, this is the Directory directive:
Options Indexes FollowSymLinks
AllowOverrride None
Order allow,deny
Allow from all
</Directory>
Remove the FollowSymLinks reference so that this reads:

Options Indexes
AllowOverrride None
Order allow,deny
Allow from all
</Directory>
If some users need the ability to follow symbolic links, consider the use of the
SymLinksIfOwnerMatch directive instead.
Be specific on the Listen directive

When you first install Apache, the httpd.conf file is populated with a directive that
reads "Listen 80". Shore things up and change this to "Listen ww.xx.yy.zz:80", where
the "ww.xx.yy.zz" is the IP address on which you want Apache to listen for requests.
This is especially important if you have Apache running on a server with multiple IP
addresses. If you don't take this precaution, the default "Listen 80" directive tells
Apache to listen to every IP address on port 80.
Depending on your environment, this may not be important.

Don't allow users near the root directory

Under no circumstances should you allow users (or Apache) access to files and
directories higher up the folder hierarchy. Apache 2.2.4 includes a restrictive option that
achieves most of the goal, but still leaves the FollowSymLinks option available for the
root ("/") folder.
<Directory />
Options FollowSymLinks
AllowOverride None
Order Deny,Allow
Deny from all
</Directory>
It's better to turn this option off. Change your httpd.conf

to reflect the following:
<Directory />
Options None
AllowOverride None
Order Deny,Allow
Deny from all
</Directory>
Remove the default comments from httpd.conf

Apache 2.2.4's default httpd.conf file exceeds 400 lines. Of these 400 lines, only a frac-
tion are actually Apache directives. The rest are nothing but comments designed help
you place appropriate directives into httpd.conf. In my experience with Apache, I've
found that the comments seriously get in the way to such an extent that you may leave
dangerous directives in the file. One of the first things I've done on many Apache
servers I've managed is to copy the httpd.conf file to something else (say, httpd.conf.orig)
and then totally strip out the superfluous comments. The file becomes much more
readable and you're less likely to overlook a potential security problem or make a mis-
take with your configuration.
Protect Apache from Denial of Service (DoS) attacks

While you can never completely protect yourself from DoS attacks, Apache provides
you with a number of directives that you should consider manipulating to help protect
your server from these kinds of affronts. Table A lists the directives recommended for
review by the Apache group for servers that may become the subject of a DoS attack.

Table A
Directive Apache 2.2/2.3 default Advice/Description
TimeOut 300 seconds Should be lowered on sites that are subject to
DoS attacks. Setting this to as low as a few sec-
onds may be appropriate, but could pose prob-
lems for some CGI scripts.
KeepAliveTimeout 5 seconds May be also lowered or even disabled (not rec-

ommended) on sites that are subject to DoS
attacks.
LimitRequestBody 0 bytes (unlimited) Restricts the total size of the HTTP request
body sent from the client. If DoS attacks are
occurring as a result of large requests, limit
request size.
LimitRequestFields 100 fields Limits the number of HTTP request header

fields that will be accepted from the client. If
DoS attacks are occurring as a result of too
many HTTP request headers, lower this number.
LimitRequestFieldSize 8190 bytes Limits the size of the HTTP request header
allowed from the client.
LimitRequestLine 8190 bytes This directive sets the number of bytes that will
be allowed on the HTTP request-line.
MaxClients 256 requests Sets the limit on the number of simultaneous

requests that will be served.
Parameters that may aid in avoiding DoS attacks.

Setting up Apache as a Web server

under Linux via GUI
L
inux is increasingly becoming a popular alternative to Microsoft Windows for net-
work administrators wanting to provide services for their organization. Learning a
new OS like Linux can present some challenges to a long-time Windows adminis-
trator, however. This is the beginning of a series of articles aimed at the IT administrator
new to Linux wanting to set up various servers. This first article will describe the steps to
setting up an Apache server as a Web server for your organization.
Configuring Apache
To configure an Apache server in SuSe Linux, you’ll use the YaST tool. To do so, go
to the Control Center. Select Administrator Settings from the Common Tasks section
to open the YaST Admin Tool. Next, select Network Services to reveal a listing of the
various Network Services that can be configured from within YaST. Now you can start
administering Apache. Press the HTTP Server button to open up the Apache
Configuration tool, as shown in Figure A.
From the main configuration window, you’ll notice a number of options. One of
those options is the Firewall Details. By default, the http daemon is enabled, and the port
(80) are open in the firewall. From this screen, you can’t do much with editing the fire-
Figure A
You are now ready to begin your quest to set up the Apache server.

wall; you can only enable or disable the http port. If you press the Firewall Details button,
a new window appears, which allows you to select the interface assigned to the firewall.
From the main window, there are four tabs. The default tab is the Listen Ports and
Addresses tab. From this tab, you can handle the action above, add additional ports for
Apache to listen to, and view access and error logs.
One of the first issues I ran into was YaST not reading the access and/or error logs for
Apache. By opening up a console and issuing the command less /var/log/apache2/access_log, I
was able to read the log file. In order to successfully be able to read the Apache log files, go
back to the YaST Control Center and select Miscellaneous | View System Log. The View
System Log window will open (as shown in Figure B), defaulting to /var/log/messages. If you
click on the drop-down, you will not see the Apache logs listed. What you will need to do is
type out /var/log/apache2/access_log, and the log will appear as it is in Figure B.
Server modules
As we all know, Apache would be fairly useless without modules. Today’s Web site
denizens have grown used to the increasingly robust content available. With that in mind,
let’s take a look at the Server Modules tab within YaST’s Apache2 configuration window.
Figure C shows the main window for the Server Module configuration. There are two
configurations within this window: toggle a modules status (enable/disable), or add a
module. Obviously, everyone’s HTTP needs are going to vary, so you’ll have to go
through the module listing to decide what you need. If the module isn’t listed, press the
Figure B
After you have typed out the log you want to view, it will appear in the drop-down the next time you need it.

Add Module button for a new window, allowing you to select from a good number of
modules, ranging from auth_alias to version. When you add a new module, it will be
appended to the bottom of the module listing, and its status will be enabled.
Once you add a module or change the status of a module, you will need to reload
Apache2 so the server will be made aware of the new module. To reload the service,
simply press the Finish button at the bottom right of the YaST window. Once the
service is reloaded, the YaST window will disappear.
Apache hosts
The next tab is the Apache Main Host tab. From this window, the servers Apache
information is listed (and can be edited). Like all of the YaST GUI tools, this tool edits
the httpd.conf file directly. But from this window, that will be made quite obvious. As you
can see in Figure D, the listing in the GUI window already should look familiar to those
of you who have taken a crack at editing an Apache conf file. The good news for those
of you who haven’t — this makes it very easy.
Most of the defaults should work for you. Of course, there are special needs where
you might have to edit one of the various entries. One entry you’ll definitely have to
edit is the Server Administrator e-mail entry. To do this, highlight the entry and press
the Edit button, enter the administrators e-mail, and press OK.
There is one really cool feature here called Server Resolution. What this enables you
to do is set up virtual hosting based on either IP Address or HTTP headers. Let’s set
Figure C
You can change the listing of the modules by selecting one of the headings: Name, Status, or Description.

up a virtual site using IP Address routing.

Press the Add button and a new window with a drop-down list will appear. Select
Server Resolution and press OK. Now move on to the New Host tab. From in this tab,
you will press the Add button, and a new window will appear.
The information necessary is pretty obvious, but you will want to determine how the
virtual host will be determined. I opted to determine requests by IP address. Select the
appropriate check box and press the Change VirtualHost ID button. The VirtualHost
ID window will allow you to choose one of the IP addresses configured on your
machine. If you have only one network-attached device, you will be given two address-
es: the address of the configured device, and the loopback address (127.0.0.1).
Obviously, the loopback address is only going to be good for that machine. That’s not
such a bad thing if you are using the virtual host for testing purposes. The one prob-
lem you might face is if your firewall will not allow traffic on the loopback device. So
we’ll configure ours on the 192.168.1.25 address to avoid the issue.
The next screen contains site-specific details such as CGI Options, SSL Support,
Directory Options, and Enable Public HTML. Chose the options your virtual site will
need and press Next. You are finally ready to finish the setup. Press finish to apply the
changes and restart Apache. Voila! Virtual hosting made GUI.
The last thing you want to do is make sure you actually have an index.html (or some
referencing file) in the directory you are hosting your virtual site. Without the index.html
file, your browser will not find the virtual site.
Figure D
As the instructions say, if you opt to use Server Resolution, the default server will not be served.

Creating virtual hosts with Apache
O
ne of Apache's most underused features is its ability to host virtual sites.
Being able to host more than one site allows for one machine to host all of
your Web needs. Here's how you make it work.
What do virtual sites do?

How do virtual sites work? Let's say you host a small company site that allows its
users to browse products or services; on that server, you want to offer your employees
Web mail access.
Assume your site is www.yourcompany.com. A Web mail setup that allows your
employees to go to www.yourcompany.com/webmail could easily be created, but why
not set up webmail.yourcompany.com with the same access? It's quicker to type and
easier to remember. You could also set up sales.yourcompany.com or editorial.your-
company.com, for example, all on a single IP address. That's what virtual sites are for.
Name vs. IP
There are two types of virtual hosting: name-based and IP-based. IP-based virtual
hosting uses an IP address to determine which virtual host to send the connection to.
This scheme requires each host to have a separate IP address, which isn't a problem if
you're working on a small network. If your network is larger, IP addresses could quick-
ly grow scarce. Name-based virtual hosting uses a hostname to determine where the
connection must be sent. Using name-based virtual hosting allows many different hosts
to share the same IP address. I suggest name-based virtual hosting for anyone unless:
X You have a short supply of IP addresses. You have to support obsolete clients (such
clients will not send the correct Host: header information).
X You have to use SSL (name-based cannot be used with secure servers
X Your OS or networking hardware can not differentiate between hosts unless they are
on different IP addresses.
Otherwise, you are able to move forward with name-based virtual hosting.
First steps to setting up virtual hosts
Virtual hosts can be defined and configured in Apache's config file. This config file can be
found in Fedora Core by default in /etc/httpd/conf/httpd.conf, but the location of this file
may vary on other distributions. For example, in Ubuntu, the Apache configuration file is
in the /etc/apache2/ directory. If you're having trouble finding this file, you can locate it
with the command locate httpd.conf. Once you've located your configuration file, open it
with your favorite editor (such as Pico) and search for the NameVirtualHost entry.
Hint: If you use the Pico editor, you can find the entry by running the grep -n
NameVirtualHost command to see exactly where the line is. Once you know the exact
line number, you can open the file in Pico, scroll down a bit, and hit [Ctrl]C to see
exactly which line you are on. If the line is not in your conf file, add it.
Now, make sure the entry is uncommented and looks like the following:
NameVirtualHost *

This will use whatever IP address to which you assign your server to point to all the
hosts configured in the httpd.conf virtual hosts configuration. (The NameVirtualHost *
configuration only works with Apache 1.3.13 and greater.) You can also configure a
specific IP address for the server in place of the asterisk (*).
The following example will require you to have the document root located in
/var/www/ (as it is in Apache2) and the new Web mail will be installed in
/var/www/Web mail. If your locations vary, change the example accordingly before
adding them to httpd.conf.
To get it up and running quickly, add these lines below NameVirtualHost *:
<VirtualHost *>
ServerName www.yourcompany.com
DocumentRoot /www/yourcompany
</VirtualHost>
<VirtualHost *>
ServerName Web mail.yourcompany.com
DocumentRoot /www/Web mail
</VirtualHost>
where www.yourcompany.comis the FQDN of your company. Do not leave a trail-

ing / at the end of the DocumentRoot directive.
There are many more advanced configurations for virtual hosting. You can add the
following configurations:
X Logging
By default, Apache will record all messages to the access_log and error_log files locat-
ed in /var/log/httpd. However, if you want each virtual site to have separate logs, add
these directives to the virtual host section (assume you're adding log files for your
virtual Web mail):
ErrorLog /var/log/httpd/Web mail-error_log common

CustomLog /var/log/httpd/Web mail-access_log common
So, if you want your Web mail site to record messages to Web mail-access_log and Web
mail-error_log, then your VirtualHost section for the Web mail site will look like this:
<VirtualHost *:80>
ServerName Web mail.yourdomain.com
DocumentRoot /www/Web mail
ErrorLog /var/log/httpd/Web mail-error_log common
CustomLog /var/log/httpd/Web mail-access_log common
</VirtualHost>
X Error Pages
You can set Apache to serve a custom page when a visitor gets a 404 (not found)
or 500 (internal server error) or any other error code, for that matter. For
instance, you can redirect any visitor who receives a 404 error to the main index file,

or to a 404 file you created. To accomplish this, add the following directives to the
virtual host block, just like in the above example:
ErrorDocument 404 /index.htm

ErrorDocument 500 /index.htm
The error page could be anything. But remember, the location starts with the direc-
tory set in DocumentRoot in httpd.conf. For instance, if your DocumentRoot is
/var/www/html and the error page is in /var/www/html/messages/404.htm, then you'll
have to append /messages/404.htm to the ErrorDocument directive.
X Server Aliases
If you want to use your virtual host for more than one domain name, you can use
the ServerAlias directive inside the virtual host block in order to link the two domains
together. In the httpd.conf file, enter:
ServerAlias yourcompany.com yoursecondcompany.com
Take this a step further by using the wildcard to point all requests to
yourcompany.com:
ServerAlias yourcompany.com *
One caveat: You cannot simply make up host names and put them in the ServerAlias
or ServerName directives. All host names must be correctly mapped in your DNS server
configuration so those names will properly map to the right server.
Something old, something new

Earlier, I mentioned clients who do not have to send the required data for name-
based virtual hosts. If you're one of the lucky few to be running such clients, fear not;
there is a work-around using the ServerPatch directive. Always send these clients pages
from the first virtual host listed for the primary name-based virtual host.
Here is the sample configuration for subdomain solution:
NameVirtualHost 192.168.1.42
<VirtualHost 192.168.1.42>
ServerName www.domain.yourcompany.com
ServerPath /domain
DocumentRoot /web/domain
RewriteEngine On
</VirtualHost>
The above configuration means that any request for any URL beginning with
/domain will be served from the virtual host www.domain.yourcompany.com. These
pages can be accessed as http://www.domain.yourcompany.com/domain/ for all
clients. Of course any client sending the proper Host: header will also be able to access
www.domain.yourcompany.com.We have also added the RewriteEngine directive to
ensure that clients who send the proper Host:header information will be able to use
both iterations of the URL.

To make this work within your primary hosts

page, put a link to Customize Apache's
www.domain.yourcompany.comand then, in the default error pages
When Apache encounters an error, it
virtual hosts pages, use only relative links such as displays a designated error message that's
<a href="shop.html"> or prebuilt into the server. For example, let's
<a href="../images/image.jpg">. You can also say that you try to load a page that Apache
can't find or that doesn't exist. Apache
use the domain preface with links like: returns a 404 (page not found) error and
<a href="/domain/images/image.jpg">. provides a rather drab Web page that indi-
cates the error (and often the e-mail
Note: Relative links are links that specify the address of the Webmaster).
name of the file to be linked to only as it is related to Apache draws this information from the
data stored in the httpd.conf configuration
the current document. So if the current document, pic- file. However, you can spice things up by
tures.html resides in /var/www and points to the creating your own error documents.
image image.jpg that resides in /var/www/images, the Your error documents can be regular
HTML, PHP, or any other Web document
only necessary link is <a href="/images/image.jpg">. that the server supports. For instance, to
Or if the pictures.html file is already in the create a new error message for a 404 error
that better fits your site, use something like
/var/www/images directory, the links would only the following:
need to look like <a href="image.jpg"> ErrorDocument 404 /404.php
Don't forget You can use this globally or inside a

VirtualHost stanza to affect one particular
Once you have your entire configuration com- domain.
Of course, you must supply the file; in
plete, remember to restart the Apache daemon. this example, it's 404.php, located at
Otherwise, the changes won't take effect. If you http://www.yoursite.com/404.php. This file
have problems, don't forget your error and log should contain the error message and any-
thing else you want to specify.
files; they will tell you everything you need to You can also do this for any other error
know about what has gone wrong. message type. In addition, you can present
custom error messages without creating a
Apache is one of the most powerful, flexible whole page. Here's an example:
tools in the open source world. The capabilities of ErrorDocument 500 "The server has encoun-
Apache are near that of proprietary servers; addi- tered a problem. Please send flowers."
tionally, there are many things Apache can do that
proprietary systems cannot. The virtual hosting fea-
ture is only a small example of the power of Apache.

Table B (from page 8)
Default Module Configure Explanation and link
directive
Enabled mod_actions --disable-actions Disable action triggering on requests, which is provided by mod_actions.
Enabled mod_alias --disable-alias Disable the mapping of requests to different parts of the filesystem, which is provided by
mod_alias.
Enabled mod_asis --disable-asis Disable support for as-is filetypes, which is provided by mod_asis.
Disabled mod_auth_anon --enable-auth-anon Enable anonymous user access provided by mod_auth_anon.
Enabled mod_auth_basic --disable-auth-basic Allows the use of HTTP Basic Authentication to restrict access.
Disabled mod_auth_dbm --enable-auth-dbm mod_auth_dbm provides for HTTP Basic Authentication, where the usernames and pass-
words are stored in DBM type database files. Use this option to enable the module.
Disabled mod_auth_digest --enable-auth-digest Enable RFC2617 Digest authentication provided by mod_auth_digest. This module uses
plain text files to store the credentials.
Disabled mod_authn_alias --enable-authn-alias Provides the ability to create extended authentication providers based on actual providers
Disabled mod_authn_dbd --enable-authn-dbd User authentication using an SQL database.
Enabled mod_authn_default --disable-authn-default Authentication fallback module.
Enabled mod_authn_file --disable-authn-file User authentication using text files.
Disabled mod_authnz_ldap --enable-authnz-ldap Enable LDAP based authentication provided by mod_authnz_ldap.
Disabled mod_authz_dbm --enable-authz-dbm Group authorization using DBM files.
Enabled mod_authz_default --disable-authz-default Authorization fallback module.
Enabled mod_authz_groupfile --disable-authz-groupfile Group authorization using plaintext files.
Enabled mod_authz_host --disable-authz-host Group authorizations based on host (name or IP address).
Disabled mod_authz_owner --enable-authz-owner Authorization based on file ownership.
Enabled mod_authz_user --disable-authz-user User Authorization.
Enabled mod_autoindex --disable-autoindex Disable the directory listing functionality provided by mod_autoindex.
Disabled mod_cache --enable-cache Enable dynamic file caching provided by mod_cache. This experimental module may be
interesting for servers with high load or caching proxy servers. At least one storage manage-
ment module (e.g. mod_disk_cache or mod_mem_cache) is also necessary.
Disabled mod_cern_meta --enable-cern-meta Enable the CERN-type meta files support provided by mod_cern_meta.
Enabled mod_cgi --disable-cgi mod_cgi, which provides support for CGI scripts, is enabled by default when using a non-
threaded MPM. Use this option to disable CGI support.
Enabled mod_cgid --disable-cgid When using the threaded MPMs worker support for CGI scripts is provided by mod_cgid by
default. To disable CGI support use this option.
Disabled mod_charset_lite --enable-charset-lite Enable character set translation provided by mod_charset_lite. This module will be installed
by default only on EBCDIC systems. On other systems, you have to enable it.
Disabled mod_dav --enable-dav Enable the WebDAV protocol handling provided by mod_dav. Support for filesystem
resources is provided by the separate module mod_dav_fs. This module is also automati-
cally enabled with --enable-dav.
Disabled mod_dav_fs --enable-dav-fs Enable DAV support for filesystem resources, which is provided by mod_dav_fs. This mod-
ule is a provider for the mod_dav module, so you should also use --enable-dav.
Disabled mod_dav_lock --enable-dav-lock Enable mod_dav_lock which provides generic DAV locking support for backend modules.
This module needs at least mod_dav to function, so you should also use --enable-dav.
Disabled mod_dbd --enable-dbd Manages SQL database connections.
Disabled mod_deflate --enable-deflate Enable deflate transfer encoding provided by mod_deflate.
Enabled mod_dir --disable-dir Disable directory request handling provided by mod_dir.
Disabled mod_disk_cache --enable-disk-cache Enable disk caching provided by mod_disk_cache.
Disabled mod_dumpio --enable-dumpio Dumps all I/O to error log as desired.

Disabled mod_echo --enable-echo A simple echo server to illustrate protocol modules.
Enabled mod_env --disable-env Enable setting and clearing of environment variables, which is provided by mod_env.
Disabled mod_expires --enable-expires Enable Expires header control provided by mod_expires.
Disabled mod_ext_filter --enable-ext-filter Enable the external filter support provided by mod_ext_filter.
Disabled mod_file_cache --enable-file-cache Enable the file cache provided by mod_file_cache.
Enabled mod_filter --disable-filter Context-sensitive smart filter configuration module.
Disabled mod_headers --enable-headers Enable control of HTTP headers provided by mod_headers.

Enabled mod_http --disable-http Disable the HTTP protocol handling. The http module is a basic one, enabling the server to
function as an HTTP server. It is only useful to disable it if you want to use another protocol
module instead. Don't disable this module unless you are really sure what you are doing.
Disabled mod_ident --enable-ident RFC 1413 ident lookups.
Enabled mod_imagemap --disable-imagemap Disable support for server based imagemaps, which provided by mod_imagemap.
Enabled mod_include --disable-include Disable Server Side Includes provided by mod_include.

Disabled mod_info --enable-info Enable the server information provided by mod_info.
Disabled mod_isapi --enable-isapi Enable the isapi extension support provided by mod_isapi.
Disabled mod_ldap --enable-ldap Enable LDAP caching and connection pooling services provided by mod_ldap.
Enabled mod_log_config --disable-log-config Disable the logging configuration provided by mod_log_config. You won't be able to log
requests to the server without this module.
Disabled mod_log_forensic --enable-log-forensic Forensic Logging of the requests made to the server.
Disabled mod_logio --enable-logio Enable logging of input and output bytes including headers provided by mod_logio.
Disabled mod_mem_cache --enable-mem-cache Enable memory caching provided by mod_mem_cache.
Enabled mod_mime --disable-mime mod_mime associates the requested filename's extensions with the file's behavior and con-
tent (mime-type, language, character set and encoding). Disabling this module is normally
not recommended.
Disabled mod_mime_magic --enable-mime-magic Enable automatical determining of MIME types, which is provided by mod_mime_magic.
Enabled mod_negotiation --disable-negotiation Disable content negotiation provided by mod_negotiation.
Disabled mod_proxy --enable-proxy Enable the proxy/gateway functionality provided by mod_proxy. The proxying capabilities
for AJP13, CONNECT, FTP, HTTP and the balancer are provided by the separate modules
mod_proxy_ajp, mod_proxy_connect, mod_proxy_ftp, mod_proxy_http and mod_proxy_bal-
ancer. These five modules are also automatically enabled with --enable-proxy.
Disabled mod_proxy_ajp --enable-proxy-ajp Enable proxy support for AJP13 (Apache JServ Protocol 1.3) request handling, which is
provided by mod_proxy_ajp. This module is an extension for the mod_proxy module, so you
should also use --enable-proxy.
Disabled mod_proxy_balancer --enable-proxy-balancer Enable load balancing support for the AJP13, FTP and HTTP protocols, which is provided
by mod_proxy_balancer. This module is an extension for the mod_proxy module, so you
should also use --enable-proxy.
Disabled mod_proxy_connect --enable-proxy-connect Enable proxy support for CONNECT request handling, which is provided by mod_proxy_
connect. This module is an extension for the mod_proxy module, so you should also use
--enable-proxy.
Disabled mod_proxy_ftp --enable-proxy-ftp Enable proxy support for FTP requests, which is provided by mod_proxy_ftp. This module is
an extension for the mod_proxy module, so you should also use --enable-proxy.
Disabled mod_proxy_http --enable-proxy-http Enable proxy support for HTTP requests, which is provided by mod_proxy_http. This module
is an extension for the mod_proxy module, so you should also use --enable-proxy.
Disabled mod_rewrite --enable-rewrite Enable rule based URL manipulation provided by mod_rewrite.
Enabled mod_setenvif --disable-setenvif Disable support for basing environment variables on headers, which is provided by mod_
setenvif.
Disabled mod_so --enable-so Enable DSO capability provided by mod_so. This module will be automatically enabled if
you use the --enable-mods-shared option.
Disabled mod_speling --enable-speling Enable the functionality to correct common URL misspellings, which is provided by mod_
speling.
Disabled mod_ssl --enable-ssl Enable support for SSL/TLS provided by mod_ssl.
Enabled mod_status --disable-status Enable the process/thread monitoring, which is provided by mod_status.
Disabled mod_suexec --enable-suexec Allows CGI scripts to run as a specified user and Group.
Disabled mod_unique_id --enable-unique-id Enable the generation of per-request unique ids, which is provided by mod_unique_id.
Enabled mod_userdir --disable-userdir Disable the mapping of requests to user-specific directories, which is provided by mod_user-
dir.
Disabled mod_usertrack --enable-usertrack Enable user-session tracking provided by mod_usertrack.
Disabled mod_vhost_alias --enable-vhost-alias Enable mass virtual hosting provided by mod_vhost_alias.

Apache

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Apache

Uploaded by

Copyright:

Available Formats

TechRepublic SolutionSeries Apache: The engine that powers the Web

©2007 CNET Networks, Inc. All rights reserved. 2

©2007 CNET Networks, Inc. All rights reserved. 3

What's new in Apache 2.2.4?

Database handling changes

Addition of caching and proxy load balancing

©2007 CNET Networks, Inc. All Rights Reserved. 4

http://example.com:/, and http://example.com:80/ are all equivalent URLs.

Configuration files changes

©2007 CNET Networks, Inc. All rights reserved. 5

Other items of note

©2007 CNET Networks, Inc. All rights reserved. 6

©2007 CNET Networks, Inc. All rights reserved. 7

Setting up a simple Web site

©2007 CNET Networks, Inc. All rights reserved. 8

cd httpd-2.2.4 Change to the new source directory.

./configure --prefix= Install the Web server to the directory identified

make Compile Apache.

make install Copy the newly compiled binaries to the

/usr/local/apache/bin/apachectl Start Apache with its default configuration file.

Apache was successfully installed.

©2007 CNET Networks, Inc. All rights reserved. 9

tion of the instructions in Table A. I've indicated whether a module is enabled by

Installing Apache 2.2.4 on Windows

©2007 CNET Networks, Inc. All rights reserved. 10

Adding and modifying pages

All of this information is filled in for you.

©2007 CNET Networks, Inc. All rights reserved. 11

©2007 CNET Networks, Inc. All rights reserved. 12

Make the move from

Plan for ASP

©2007 CNET Networks, Inc. All rights reserved. 13

©2007 CNET Networks, Inc. All rights reserved. 14

Learn a new management style

©2007 CNET Networks, Inc. All rights reserved. 15

Understand platform differences

The birds-eye steps

©2007 CNET Networks, Inc. All rights reserved. 16

Decide the future for scripting in your organization

©2007 CNET Networks, Inc. All rights reserved. 17

Troubleshoot Apache with these tips

Stay current with Apache releases

Know where to find Apache community resources

Know where to look

©2007 CNET Networks, Inc. All rights reserved. 18

Crit Critical Conditions. "socket: Failed to get a socket, exiting child"

Error Error conditions. "Premature end of script headers"

Info Informational. "Server seems busy, (you may need to increase

Debug Debug-level messages "Opening config file ..."

Apache's logging levels

Don't allow an AllowOverride to ruin your day

©2007 CNET Networks, Inc. All rights reserved. 19

None Disallow the use of .htaccess files.

AuthConfig Allow use of the authorization directives (AuthDBMGroupFile, AuthDBMUserFile,

A newly installed module/extension

©2007 CNET Networks, Inc. All rights reserved. 20

the DirectoryIndex directive. Make sure the line reads:

Normally, this line is commented out.

Apache 1.3 also requires a fourth directive:

Don't worry about ‘connection reset by peer’ errors

Make sure Apache is actually running

Check for port conflicts

©2007 CNET Networks, Inc. All rights reserved. 21