97798065 appache introduction

7/31/2019 97798065 Appache Introduction

http://slidepdf.com/reader/full/97798065-appache-introduction 1/50

Introduction

Apache is probably the most popular Linux-based We

server application in use. Once you have DNS correctl

setup and your server has access to the Internet, you'

need to configure Apache to accept surfers wanting t

access your Web site.

This chapter explains how to configure Apache in

number of commonly encountered scenarios for sma

web sites.Download and Install The Apache Package

Most RedHat and Fedora Linux software products ar

available in the RPM format. When searching for the file

remember that the Apache RPM's filename usually start

with the word httpd followed by a version number, as i

httpd-2.0.48-1.2.rpm. It is best to use the latest versioof Apache. (For more on RPMs, see Chapter 6, "Installin

Linux Software").

When searching for the file, remember that the Redhat

Fedora Apache RPM package's filename usually start

with the word httpd followed by a version number, a

in httpd-2.0.48-1.2.rpm. With Ubuntu / Debian thpackage name will have the apacheprefix instead.

Note: Unless otherwise stated, the sampl

configurations covered in this chapter will be fo

http://www.linuxhomenetworking.com/wiki/index.php/Quick_HOWTO_:_Ch06_:_Installing_Linux_Software






Redhat / Fedora distributions. If you use Debian

Ubuntu, don’t worry, there will be annotations to mak

you aware of the differences.

How To Get Apache Started

Setting up the Apache server is easy to do, but th

procedure differs between Linux distributions.

Redhat / Fedora

Use the chkconfig command to configure Apache to sta

at boot:

[root@bigboy tmp]# chkconfig httpd on

Use the httpd<code> init script in th

<code>/etc/init.d directory to start,stop, and resta

Apache after booting:

[root@bigboy tmp]# /etc/init.d/httpd start

[root@bigboy tmp]# /etc/init.d/httpd stop

[root@bigboy tmp]# /etc/init.d/httpd restart

You can test whether the Apache process is running wit

[root@bigboy tmp]# pgrep httpdyou should get a response of plain old process I

numbers.

Debian / Ubuntu



Use the sysv-rc-conf command to configure Apache t

start at boot:

[root@u-bigboy tmp]# sysv-rc-conf apache on

Use the apache init script in the /etc/init.d directory t

start,stop, and restart Apache after booting:

[root@u-bigboy tmp]# /etc/init.d/apache start

[root@u-bigboy tmp]# /etc/init.d/apache stop

[root@u-bigboy tmp]# /etc/init.d/apache restart

You can test whether the Apache process is running wit

[root@u-bigboy tmp]# pgrep apache

you should get a response of plain old process I

numbers.

Configuring DNS For Apache

Remember that you will never receive the correct traff

unless you configure DNS for your domain to make you

new Linux box Web server the target of the DN

domain's www entry. To do this, refer to Chapter 18

"Configuring DNS", or Chapter 19, "Dynamic DNS".

DHCP and Apache

As you remember, if your Internet connection uses DHC

to get its IP address, then you need to use dynamic DN

http://www.linuxhomenetworking.com/wiki/index.php/Quick_HOWTO_:_Ch18_:_Configuring_DNS

http://www.linuxhomenetworking.com/wiki/index.php/Quick_HOWTO_:_Ch19_:_Dynamic_DNS





to get the correct Internet DNS entry for your We

server. If your Web server and firewall are differen

machines, then you probably also need to set up po

forwarding for your Web traffic to reach the Web servecorrectly. (Chapter 19, "Dynamic DNS", explains po

forwarding, as well.).

DHCP on your protected home network is different. I

the book's sample topology, the web server lives on th

192.168.1.0 home network protected by a firewall. Th

firewall uses NAT and port forwarding to pass Internetraffic on to the web server. Remember that the I

address of your web server can change if it gets its I

address using DHCP. This could cause your firewall por

forwarding, not Dynamic DNS, to break.

In this case I recommend that your web server on th

192.168.1.0 network uses a fixed, or static IP addres

that is outside of the range of the DHCP server t

prevent you from having this problem.

General Configuration Steps

The configuration file used by Apach

is /etc/httpd/conf/httpd.conf in Redhat / Fedordistributions and/etc/apache*/httpd.conf in Debian

Ubuntu distributions. As for most Linux applications, yo

must restart Apache before changes to th





configuration file take effect.

Where To Put Your Web Pages

All the statements that define the features of each wesite are grouped together inside their ow

<VirtualHost> section, or container, in the httpd.con

file. The most commonly used statements, or directives

inside a <VirtualHost> container are:

servername: Defines the name of the websit

managed by the <VirtualHost> container. This needed in named virtual hosting only, as I'll explai

soon.

DocumentRoot: Defines the directory in which th

web pages for the site can be found.

By default, Apache searches the DocumentRoo

directory for an index, or home, page named index.htm

So for example, if you have a servername of www.my

site.com with a DocumentRoot directory o

/home/www/site1/, Apache displays the contents of th

file /home/www/site1/index.html when yo

enterhttp://www.my-site.com in your browser.

Some editors, such as Microsoft FrontPage, create file

with an .htm extension, not .html. This isn't usually

problem if all your HTML files have hyperlinks pointing t

files ending in .htm as FrontPage does. The problem

http://www.my-site.com/

http://www.my-site.com/



occurs with Apache not recognizing the topmos

index.htm page. The easiest solution is to create

symbolic link (known as a shortcut to Windows users

called index.html pointing to the file index.htm. Ththen enables you to edit or copy the file index.htm wit

index.html being updated automatically. You'll almos

never have to worry about index.html and Apach

again!

This example creates a symbolic link to index.html i

the /home/www/site1 directory.

[root@bigboy tmp]# cd /home/www/site1

[root@bigboy site1]# ln -s index.htm index.html

[root@bigboy site1]# ll index.*

-rw-rw-r-- 1 root root 48590 Jun 18 23:4

index.htm

lrwxrwxrwx 1 root root 9 Jun 21 18:0

index.html -> index.htm

[root@bigboy site1]#

The l at the very beginning of the index.html entr

signifies a link and the -> the link target.

The Default File Location

By default, Apache expects to find all its web page file



in the /var/www/html/ directory with a gener

DocumentRoot statement at the beginning of httpd.con

The examples in this chapter use the /home/ww

directory to illustrate how you can place them in othelocations successfully.

File Permissions And Apache

Apache will display Web page files as long as they ar

world readable. You have to make sure you make all th

files and subdirectories in your DocumentRoot have thcorrect permissions.

It is a good idea to have the files owned by

nonprivileged user so that Web developers can updat

the files using FTP or SCP without requiring the roo

password.

To do this:

1.Create a user with a home directory of /home/www.

2.Recursively change the file ownership permissions o

the /home/www directory and all its subdirectories.

3.Change the permissions on the /home/www

directory to 755, which allows all users, includinthe Apache's httpd daemon, to read the files inside.

[root@bigboy tmp]# useradd -g users www



[root@bigboy tmp]# chown -R www:users /home/www

[root@bigboy tmp]# chmod 755 /home/www

Now we test for the new ownership with the ll command

[root@bigboy tmp]# ll /home/www/site1/index.*

-rw-rw-r-- 1 www users 48590 Jun 25 23:4

index.htm

lrwxrwxrwx 1 www users 9 Jun 25 18:0

index.html -> index.htm

[root@bigboy tmp]#

Note: Be sure to FTP or SCP new files to your we

server as this new user. This will make all th

transferred files automatically have the correc

ownership.

If you browse your Web site after configuring Apach

and get a "403 Forbidden" permissions-related error o

your screen, then your files or directories under you

DocumentRoot most likely have incorrect permissions

Appendix II, "Codes, Scripts, and Configurations," has

short script that you can use to recursively set the fil

permissions in a directory to match those expected b

Apache. You may also have to use the Director

directive to make Apache serve the pages once the fil

permissions have been correctly set. If you have you



files in the default /home/www directory then th

second step becomes unnecessary.

Security Contexts For Web Pages

Fedora Core 3 introduced the concept of securit

contexts as part of the Security Enhanced Linu

(SELinux) definition. (See Appendix I, "Miscellaneou

Linux Topics," for details.) A Web page may have th

right permissions, but the Apache httpd daemon won

be able to read it unless you assign it the correcsecurity context or daemon access permissions

Context-related configuration errors will give "40

Forbidden" browser messages, and in some cases, yo

will get the default Fedora Apache page where you

expected Web page should be.

When a file is created, it inherits the security context oits parent directory. If you decide to place your We

pages in the default /var/www/ directory, then they wi

inherit the context of that directory and you should hav

very few problems.

The context of a file depends on the SELinux label it

given. The most important types of security label arlisted in Table 20-1.

Table 20-1 SELinux Security Context File Labels



Context Code Description

httpd_sys_content_

t

The type used by regular static

web pages with .html and .htmextensions.

httpd_sys_script_ro

_t

Required for CGI scripts to read

files and directories.

httpd_sys_script_ra

_t

Same as the

httpd_sys_script_ro_t type butalso allows appending data to

files by the CGI script.

httpd_sys_script_rw

_t

Files with this type may be

changed by a CGI script in any

way, including deletion.

httpd_sys_script_ex

ec_t

The type required for the

execution of CGI scripts

As expected, security contexts become important whe

Web pages need to be placed in directories that are no

the Apache defaults. In this example, user root creates

directory /home/www/site1 in which the pages for a new

Web site will be placed. Using the ls -Z command, yo

can see that the user_home_t security label has bee

assigned to the directory and the index.html pag



created in it. This label is not accessible by Apache.

[root@bigboy tmp]# mkdir /home/www/site1

[root@bigboy tmp]# ls -Z /home/www/

drwxr-xr-x root root root:object_r:user_home_

site1

[root@bigboy tmp]# touch /home/www/site1/index.htm

[root@bigboy tmp]# ls -Z /home/www/site1/index.html

-rw-r--r-- root roo

root:object_r:user_home_t

/home/www/site1/index.html

[root@bigboy tmp]#

Accessing the index.html file via a Web browser gets

"Forbidden 403" error on your screen, even though thpermissions are correct. Viewing th

/var/log/httpd/error_log gives a "Permission Denied

message and the /var/log/messages file shows kerne

audit errors.

[root@bigboy tmp]# tail /var/log/httpd/error_log

[Fri Dec 24 17:59:24 2004] [error] [clien216.10.119.250] (13)Permission denied: access to

denied



[root@bigboy tmp]# tail /var/log/messages

Dec 24 17:59:24 bigboy kerne

audit(1103939964.444:0): avc: denied { getattr } fo

pid=2188 exe=/usr/sbin/httpd path=/home/www/site

dev=hda5 ino=7365

scontext=system_u:system_r:httpd_t

tcontext=root:object_r:user_home_t tclass=dir

[root@bigboy tmp]#

SELinux security context labels can be modified usinthe chcon command. Recognizing the error, user roo

uses chcon with the -R (recursive) and -h (modif

symbolic links) qualifiers to modify the label of th

directory to httpd_sys_content_t with the -t qualifier.

[root@bigboy tmp]# chcon -R -h

httpd_sys_content_t /home/www/site1

[root@bigboy tmp]# ls -Z /home/www/site1/

-rw-r--r-- root roo

root:object_r:httpd_sys_content_t index.html

[root@bigboy tmp]#

Browsing now works without errors. User root won

have to run the chcon command again for the directory

because new files created in the directory will inherit th

SELinux security label of the parent directory. You ca



see this when the file /home/www/site1/test.txt

created.

[root@bigboy tmp]# touch /home/www/site1/test.txt

[root@bigboy tmp]# ls -Z /home/www/site1/

-rw-r--r-- root roo

root:object_r:httpd_sys_content_t index.html

-rw-r--r-- root roo

root:object_r:httpd_sys_content_t test.txt

[root@bigboy tmp]#

Security Contexts For CGI Scripts

You can use Apache to trigger the execution o

programs called Common Gateway Interface (CG

scripts. CGI scripts can be written in a variety o

languages, including PERL and PHP, and can be used t

do such things as generate new Web page output o

update data files. A Web page's Submit button usuall

has a CGI script lurking somewhere beneath. By defaul

CGI scripts are placed in the /var/www/cgi-bin/ director

as defined by the ScriptAlias directive you'll find in th

httpd.conf file, which I'll discuss in more detail later.

ScriptAlias /cgi-bin/ "/var/www/cgi-bin/"

In the default case, any URL with the string /cgi-bin/ wi

trigger Apache to search for an equivalent executabl



file in this directory. So, for example, th

URL, http://192.168.1.100/cgi-bin/test/test.cgiactually

executes the script file /var/www/cgi-bin/test/test.cgi.

SELinux contexts have to be modified according to th

values in Table 20.1 for a CGI script to be run in anothe

directory or to access data files. In the example case

the PERL script test.cgi was created to display the wor

"Success" on the screen of your Web browser.

#!/usr/bin/perl

# CGI Script "test.cgi"

print qq(

<html>

<head>

<meta http-equiv="Content-Language" content="en

us">

<meta http-equiv="Content-Type

content="text/html">

<title>Linux Home Networking</title>

</head>

http://192.168.1.100/cgi-bin/test/test.cgi




<body>

Success!

</body>

</html>

);

The ScriptAlias directive has been set to point t

/home/www/cgi-bin/ instead of /var/www/cgi-bin/.

ScriptAlias /cgi-bin/ "/home/www/cgi-bin/"

User root creates the /home/www/cgi-bin/ directory

changes the directory's security context label t

httpd_sys_script_exec_t, and then creates the scrip

/home/www/cgi-bin/test/test.cgi mentioned previous

with the correct executable file permissions.

[root@bigboy tmp]# mkdir -p /home/www/cgi-bin/test

[root@bigboy tmp]# chcon -h

httpd_sys_script_exec_t /home/www/cgi-bin/

[root@bigboy tmp]# mkdir /home/www/cgi-bin/test

[root@bigboy tmp]# ls -Z /home/www/cgi-bindrwxr-xr-x root roo

root:object_r:httpd_sys_script_exec_t test

[root@bigboy tmp]# vi /home/www/cgi-bin/test/test.cgi



[root@bigboy tmp]# chmod o+x /home/www/cg

bin/test/test.cgi

[root@bigboy tmp]#

Accessing the URL http://192.168.1.100/cg

bin/test/test.cgi is successful. Problems occur when th

same test.cgi file needs to be used by a second Web sit

housed on the same Web server. The file is copied to

directory /web/cgi-bin/site2/ governed by the ScriptAlia

in the second Web site's <VirtualHost> containe(explained later), but the security context label isn

copied along with it.

ScriptAlias /cgi-bin/ "/web/cgi-bin/site2/"

The file inherits the context of its new parent.

[root@bigboy tmp]# cp /home/www/cg

bin/test/test.cgi /web/cgi-bin/site2/test.cgi

[root@bigboy tmp]# ls -Z /web/cgi-bin/site2/test.cgi

-rw-r--r-x root root root:object_r:tmp_

/web/cgi-bin/site2/test.cgi

[root@bigboy tmp]#

Permission denied and kernel audit errors occur onc

more; you can fix them only by changing the securit

context of the test.cgi file.







[root@bigboy tmp]# tail /var/log/httpd/error_log

[Fri Dec 24 18:36:08 2004] [error] [clien

216.10.119.250] (13)Permission denied: access to /cg

bin/texcelon/test.cgi denied

[root@bigboy tmp]# tail /var/log/messages

Dec 24 18:36:08 bigboy kerne


pid=2191 exe=/usr/sbin/httpd path=/web/cg

bin/site2/test.cgi dev=hda5 ino=7749scontext=system_u:system_r:httpd_t

tcontext=root:object_r:tmp_t tclass=file

[root@bigboy tmp]#

Note: If you find security contexts too restrictive, yo

can turn them off system wide by editing you

/etc/selinux/config file, modifying the SELINU

parameter to disabled. SELinux will be disabled afte

your next reboot.

Named Virtual Hosting

You can make your Web server host more than one sit

per IP address by using Apache's named virtual hostinfeature. You use the NameVirtualHost directive in th

/etc/httpd/conf/httpd.conf file to tell Apache which I

addresses will participate in this feature.



The <VirtualHost> containers in the file then tell Apach

where it should look for the Web pages used on eac

Web site. You must specify the IP address for which eac

<VirtualHost> container applies.

Named Virtual Hosting Example

Consider an example in which the server is configured t

provide content on 97.158.253.26. In the code tha

follows, notice that within each <VirtualHost> containe

you specify the primary Web site domain name for thaIP address with the ServerName directive. Th

DocumentRoot directive defines the directory tha

contains the index page for that site.

You can also list secondary domain names that w

serve the same content as the primary ServerNam

using the ServerAlias directive.Apache searches for a perfect match o

NameVirtualHost, <VirtualHost>, and ServerName whe

making a decision as to which content to send to th

remote user's Web browser. If there is no match, the

Apache uses the first <VirtualHost> in the list tha

matches the target IP address of the request. This is why the first <VirtualHost> statement contain

an asterisk: to indicate it should be used for all othe

Web queries.



NameVirtualHost 97.158.253.26

<VirtualHost *>

Default Directives. (In other words, not site #1 or sit

#2)

</VirtualHost>

<VirtualHost 97.158.253.26>

servername www.my-site.com

Directives for site #1

</VirtualHost>


servername www.another-site.com

Directives for site #2

</VirtualHost>

Be careful with using the asterisk in other containers.

<VirtualHost> with a specific IP address always get

higher priority than a <VirtualHost> statement with an

intended to cover the same IP address, even if th



ServerName directive doesn't match. To get consisten

results, try to limit the use of your <VirtualHost *

statements to the beginning of the list to cover an

other IP addresses your server may have.

You can also have multiple NameVirtualHost directive

each with a single IP address, in cases where your We

server has more than one IP address.

IP-Based Virtual Hosting

The other virtual hosting option is to have one Iaddress per Web site, which is also known as IP-base

virtual hosting. In this case, you will not have

NameVirtualHost directive for the IP address, and yo

must only have a single <VirtualHost> container per I

address.

Also, because there is only one Web site per IP addressthe ServerName directive isn't needed in eac

<VirtualHost> container, unlike in named virtua

hosting.

IP Virtual Hosting Example: Single Wild Card

In this example, Apache listens on all interfaces, bugives the same content. Apache displays the content i

the first <VirtualHost *> directive even if you ad

another right after it. Apache also seems to enforce th

single <VirtualHost> container per IP addres



requirement by ignoring any ServerName directives yo

may use inside it.

<VirtualHost *>

DocumentRoot /home/www/site1

</VirtualHost>

IP Virtual Hosting Example: Wild Card and I

addresses

In this example, Apache listens on all interfaces, bugives different content for addresses 97.158.253.26 an

97.158.253.27. Web surfers get the site1 content if the

try to access the web server on any of its other I

addresses.

<VirtualHost *>


</VirtualHost>


DocumentRoot /home/www/site2</VirtualHost>





</VirtualHost>

A Note On Virtual Hosting And SSL

Because it makes configuration easier, system

administrators commonly replace the IP address in th

<VirtualHost> and NameVirtualHost directives with th

* wildcard character to indicate all IP addresses.

If you installed Apache with support for secur

HTTPS/SSL, which is used frequently in credit card an

shopping cart Web pages, then wild cards won't work

The Apache SSL module demands at least one explic

<VirtualHost> directive for IP-based virtual hosting

When you use wild cards, Apache interprets it as a

overlap of name-based and IP-based <VirtualHost

directives and gives error messages because it can

make up its mind about which method to use:

Starting httpd: [Sat Oct 12 21:21:49 2002] [erro

VirtualHost _default_:443 -- mixing * ports and non-

ports with a NameVirtualHost address is not supportedproceeding with undefined results

If you try to load any Web page on your web serve

you'll see the error:



Bad request!

Your browser (or proxy) sent a request that this servecould not understand.

If you think this is a server error, please contact th

webmaster

The best solution to this problem is to use wild card

more sparingly. Don't use virtual hosting statement

with wild cards except for the very first <VirtualHost>

directive that defines the web pages to be displaye

when matches to the other <VirtualHost> directive

cannot be found. Here is an example.

NameVirtualHost *

<VirtualHost *>

Directives for other sites

</VirtualHost>


Directives for site that also run on SSL

</VirtualHost>



Configuration - Multiple Sites And IP Addresses

To help you better understand the edits needed t

configure the /etc/httpd/conf/httpd.conf file, I'll walk yo

through an example scenario. The parameters are:

The web site's systems administrator previous

created DNS entries for www.my-site.com, my

site.com, www.my-cool-site.com and www.defaul

site.com to map the IP address 97.158.253.26 o

this web server. The domain www.another-site.comis also configured to point to alias IP addres

97.158.253.27. The administrator wants to be abl

to get to www.test-site.com on all the IP addresses.

Traffic to www.my-site.com, my-site.com, an

www.my-cool-site.com must get content from

subdirectory site2. Hitting these URLs causeApache to display the contents of file index.html i

this directory.

Traffic to www.test-site.com must get content from

subdirectory site3.

Named virtual hosting will be required fo

97.158.253.26 as in this case we have a single Iaddress serving different content for a variety o

domains. A NameVirtualHost directive fo

97.158.253.26 is therefore required.



Traffic going to www.another-site.com will ge

content from directory site4.

All other domains pointing to this server that don

have a matching ServerName directive will get We

pages from the directory defined in the very firs

<VirtualHost> container: directory site1. Sit

www.default-site.com falls in this category.

Table 20-2 summarizes these requirements.

Table 20-2 Web Hosting Scenario Summary

DomainIP

Address

Direct

ory

Type of

Virtual

Hosting

www.my-

site.com

my-site.com

www.my-cool-

site.com

97.158.253

.26

Site2 Name Based

www.test-

site.com

97.158.253

.27

Site3 Name Based

(Wild card)

www.another-

site.com

97.158.253

.27

Site4 Name Based



www.default-

site.com

All otherdomains

97.158.253

.26

Site1 Name Based

How do these requirements translate into code? Here

a sample snippet of a working httpd.conf file:

ServerName localhost



#

# Match a webpage directory with each website

#

<VirtualHost *>


</VirtualHost>





ServerName www.my-site.com

ServerAlias my-site.com, www.my-cool-site.com

</VirtualHost>



ServerName www.test-site.com

</VirtualHost>



ServerName www.another-site.com

</VirtualHost>

#

# Make sure the directories specified above



# have restricted access to read-only.

#

<Directory "/home/www/*">

Order allow,deny

Allow from all

AllowOverride FileInfo AuthConfig Limit

Options MultiViews Indexes SymLinksIfOwnerMatc

IncludesNoExec

<Limit GET POST OPTIONS>

Order allow,deny

Allow from all</Limit>

<LimitExcept GET POST OPTIONS>

Order deny,allow

Deny from all

</LimitExcept>

</Directory>



These statements would normally be found at the ver

bottom of the file where the virtual hosting statement

reside. The last section of this configuration snippet ha

some additional statements to ensure read-only accesto your Web pages with the exception of Web-base

forms using POSTs (pages with "submit" buttons

Remember to restart Apache every time you update th

httpd.conf file for the changes to take effect on th

running process.

Note: You will have to configure your DNS server tpoint to the correct IP address used for each of the We

sites you host. Chapter 18, "Configuring DNS", show

you how to configure multiple domains, such as my

site.com and another-site.com, on your DNS server.

Testing Your Website Before DNS Is Fixed

You may not be able to wait for DNS to be configure

correctly before starting your project. The easiest way t

temporarily bypass this is to modify the hosts file on th

Web developer's client PC or workstation (not th

Apache server). By default, PCs and Linux workstation

query the hosts file first before checking DNS, so if

value for www.my-site.com is listed in the file, that

what the client will use.

The Windows equivalent of the Linux /etc/hosts file

named C:\WINDOWS\system32\drivers\etc\hosts. Yo





need to open and edit it with a text editor, such a

Notepad. Here you could add an entry similar to:

97.158.253.26 www.my-site.com

Do not remove the localhost entry in this file

Disabling Directory Listings

Be careful to include an index.html pages in eac

subdirectories under your DocumentRoot directory, as

one isn't found, Apache will default to giving a listing o

all the files in that subdirectory.

Say, for example, you create a subdirectory name

/home/www/site1/example under www.my-site.com

DocumentRoot of /home/www/site1/. Now you'll be abl

to view the contents of the file my-example.html in th

subdirectory if you point your browser to:

http://www.my-site.com/example/my-example.html

If curious surfers decide to see what the index page i

for www.my-site.com/example, they would type the link

http://www.my-site.com/example

Apache lists all the contents of the files in the exampldirectory if it can't find the index.html file. You ca

disable the directory listing by using a -Indexes option i

the <Directory> directive for the DocumentRoot lik







this:

<Directory "/home/www/*">

...

...

...

Options MultiViews -Indexes SymLinksIfOwnerMatc

IncludesNoExec

Remember to restart Apache after the changes. User

attempting to access the nonexistent index page w

now get a "403 Access denied" message.

Note: When setting up a yum server it's best to enabl

directory listings for the RPM subdirectories. This allow

web surfers to double check the locations of file

through their browsers.

Handling Missing Pages

You can tell Apache to display a predefined HTML fil

whenever a surfer attempts to access a non-index pag

that doesn't exist. You can place this statement in th

httpd.conf file, which will make Apache display thcontents of missing.htm instead of a generic "404 fil

Not Found" message:

ErrorDocument 404 /missing.htm



Remember to put a file with this name in eac

DocumentRoot directory. You can see the missing.htm

file I use by trying the nonexistent link.

http://www.linuxhomenetworking.com/bogus-file.htm

Notice that this gives the same output as

http://www.linuxhomenetworking.com/missing.htm.

Using Data Compression On Web Pages

Apache also has the ability to dynamically compresstatic Web pages into gzip format and then send th

result to the remote Web surfers' Web browser. Mos

current Web browsers support this format, transparentl

uncompressing the data and presenting it on the screen

This can significantly reduce bandwidth charges if yo

are paying for Internet access by the megabyte.

First you need to load Apache version 2's deflate modul

in your httpd.conf file and then use Location directive

to specify which type of files to compress. After makin

these modifications and restarting Apache, you will b

able to verify from your /var/log/httpd/access_log fil

that the sizes of the transmitted HTML pages havshrunk.

Compare the file sizes in this Apache log.

[root@ bigboy tmp]# grep dns-stat


http://www.linuxhomenetworking.com/missing.htm


http://www.linuxhomenetworking.com/missing.htm



/var/log/httpd/access_log

...

...

67.119.25.115 - - [15/Feb/2003:23:06:51 -0800] "GE

/dns-static.htm HTTP/1.1" 200 1519

"http://www.linuxhomenetworking.com/sendmail.htm"

"Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 4.0

AT&T CSM6.0; YComp 5.0.2.6)"

...

...

[root@ bigboy tmp]#

and the corresponding directory listing

[root@ bigboy tmp]# ll /web-dir/dns-static.htm-rw-r--r-- 1 user group 78350 Feb 15 00:5

/home/www/ccie/dns-static.htm

[root@bigboy tmp]#

As you can see, 78,350 bytes shrunk to 15,190 bytes

that's almost 80% compression.Compression Configuration Example

You can insert these statements just before your virtua

hosting section of your httpd.conf file to activate th

http://www.linuxhomenetworking.com/sendmail.htm




compression of static pages. Remember to resta

Apache when you do.

Note: Fedora's version of httpd.conf loads th

compression module mod_deflate by default. Th

means that the LoadModule line (the first line of th

example snippet) is not required for Fedora. The locatio

statements are required, however.

LoadModule deflate_module modules/mod_deflate.so

<Location />

# Insert filter

SetOutputFilter DEFLATE

# Netscape 4.x has some problems...

BrowserMatch ^Mozilla/4 gzip-only-text/html

# Netscape 4.06-4.08 have some more problems

BrowserMatch ^Mozilla/4\.0[678] no-gzip



# MSIE masquerades as Netscape, but it is fine

BrowserMatch \bMSIE !no-gzip !gzip-only-text/html

# Don't compress images

SetEnvIfNoCase Request_URI \

\.(?:gif|jpe?g|png)$ no-gzip dont-vary

# Make sure proxies don't deliver the wrong content

Header append Vary User-Agent env=!dont-vary

</Location>

Apache Running On A Server Behind A NAT Firewall

If your Web server is behind a NAT firewall and you ar

logged on a machine behind the firewall as well, the

you may encounter problems when trying to acces

www.mysite.com of www.another-site.com. Because o

NAT (network address translation), firewalls frequentl

don't allow access from their protected network to I

addresses that they masquerade on the outside.

For example, Linux Web server bigboy has an internal I



address of 192.168.1.100, but the firewall presents it t

the world with an external IP address of 97.158.253.2

via NAT/masquerading. If you are on the inside

192.168.1.X network, you may find it impossible to hURLs that resolve in DNS to 97.158.253.26.

There is a two part solution to this problem:

Step 1: Configure Virtual Hosting on Multiple IPs

You can configure Apache to serve the correct conten

when accessing www.mysite.com or www.anothesite.com from the outside, and also when accessing th

specific IP address 192.168.1.100 from the inside

Fortunately Apache allows you to specify multiple I

addresses in the <VirtualHost> statements to help yo

overcome this problem.

Here is an example:



<VirtualHost 192.168.1.100 97.158.253.26>

DocumentRoot /www/server1

ServerName www.my-site.com



ServerAlias bigboy, www.my-site-192-168-1-100.com

</VirtualHost>

Step 2: Configure DNS "Views"

You now need to fix the DNS problem that NAT create

Users on the Internet need to access IP addres

97.158.253.26 when visiting www.my-site.com an

users on your home network need to access IP addres

192.168.1.100 when visiting the same site.

You can configure your DNS server to use views whic

makes your DNS server give different results dependin

on the source IP address of the Web surfer's PC doin

the query. Chapter 18, "Configuring DNS", explains how

to do this in detail.

Note: If you have to rely on someone else to do the DN

change, then you can edit your PC's hosts file as a quic

and dirty temporary solution to the problem. Remembe

that this will fix the problem on your PC alone.

How To Protect Web Page Directories With Passwords

You can password protect content in both the main an

subdirectories of your DocumentRoot fairly easily. know people who allow normal access to their regula

Web pages, but require passwords for directories o

pages that show MRTG or Webalizer data. This exampl

shows how to password protect the /home/www





directory.

1) Use Apache's htpasswd password utility to creat

username/password combinations independent of you

system login password for Web page access. You hav

to specify the location of the password file, and if

doesn't yet exist, you have to include a -c, or create

switch on the command line. I recommend placing th

file in your /etc/httpd/conf directory, away from th

DocumentRoot tree where Web users could possibl

view it. Here is an example for a first user named peteand a second named paul:

[root@bigboy tmp]# htpasswd -

/etc/httpd/conf/.htpasswd peter

New password:

Re-type new password:

Adding password for user peter

[root@bigboy tmp]#

[root@bigboy tmp]# htpasswd /etc/httpd/conf/.htpassw

paul

New password:

Re-type new password:



Adding password for user paul

[root@bigboy tmp]#

2) Make the .htpasswd file readable by all users.

[root@bigboy tmp]# chmod 64

/etc/httpd/conf/.htpasswd

3) Create a .htaccess file in the directory to which yo

want password control with these entries.

AuthUserFile /etc/httpd/conf/.htpasswd

AuthGroupFile /dev/null

AuthName EnterPassword

AuthType Basic

require user peter

Remember this password protects the directory and a

its subdirectories. The AuthUserFile tells Apache to us

the .htpasswd file. The require user statement tel

Apache that only user peter in the .htpasswd file shoul

have access. If you want all .htpasswd users to hav

access, replace this line with require valid-use

AuthType Basic instructs Apache to accept basunencrypted passwords from the remote users' We

browser.

4) Set the correct file protections on your new .htacces



file in the directory /home/www.

[root@bigboy tmp]# chmod 644 /home/www/.htaccess

5) Make sure your /etc/httpd/conf/http.conf file has aAllowOverride statement in a <Directory> directive fo

any directory in the tree above /home/www. In th

example below, all directories below /var/www/ requir

password authorization.

<Directory /home/www/*>

AllowOverride AuthConfig

</Directory>

6) Make sure that you have a <VirtualHost> directiv

that defines access to /home/www or another director

higher up in the tree.

<VirtualHost *>

ServerName 97.158.253.26

DocumentRoot /home/www

</VirtualHost>

7) Restart Apache. Try accessing the web site and you'll be prompted for

password.

The conf.d Directory



Files in the /etc/httpd/conf.d (Redhat / Fedora) o

the /etc/apache*/conf.d (Debian / Ubuntu) directory ar

read and automatically appended to the configuration i

the httpd.conf file every time Apache is restarted. Icomplicated configurations, in which a Web server ha

to host many Web sites, you can create on

configuration file per Web site each with its own set o

<VirtualHost> and <Directory> containers. This ca

make Web site management much simpler. To do th

correctly:1.Backup your httpd.conf file, in case you make

mistake.

2.Create the files located in this directory that contai

the Apache required <VirtualHost> and <Directory

containers and directives.

3.If each site has a dedicated IP address, then plac

the NameVirtualHost statements in th

corresponding conf.d directory file. If it is shared, it

need to remain in the main httpd.conf file.

4.Remove the corresponding directives from

the httpd.conf file.5.Restart Apache, and test.

The files located in the conf.d directory don't have t

have any special names, and you don't have to refer t



them in the httpd.conf file.

Troubleshooting Apache

Troubleshooting a basic Apache configuration is fairlstraightforward; you'll find errors in th

/var/log/httpd/error_log file during normal operation o

displayed on the screen when Apache starts up. Most o

the errors you'll encounter will probably be related t

incompatible syntax in the <VirtualHosts> statemen

caused by typing errors. Testing Basic HTTP Connectivity

The very first step is to determine whether your we

server is accessible on TCP port 80 (HTTP).

Lack of connectivity could be caused by a firewall wit

incorrect permit, NAT, or port forwarding rules to you

Web server. Other sources of failure include Apache no

being started at all, the server being down, or network

related failures.

If you can connect on port 80 but no pages are bein

served, then the problem is usually due to a bad We

application, not the Web server software itself.It is best to test this from both inside your network an

from the Internet. Troubleshooting with TELNET

covered in Chapter 4, "Simple Networ

http://www.linuxhomenetworking.com/wiki/index.php/Quick_HOWTO_:_Ch04_:_Simple_Network_Troubleshooting




Troubleshooting".

Browser 403 Forbidden Messages

Browser 403 Forbidden messages are usually caused bfile permissions and security context issues. Please refe

to the "General Configuration Steps" section for furthe

details.

A sure sign of problems related to security context ar

"avc: denied" messages in your /var/log/messages lo

file.

Nov 21 20:41:23 bigboy kerne


pid=1377 exe=/usr/sbin/http

path=/home/www/index.html dev=hda5 ino=1

scontext=root:system_r:httpd_t

tcontext=root:object_r:home_root_t tclass=file

Only The Default Apache Page Appears

When only the default Apache page appears, there ar

two main causes. The first is the lack of an index.htm

file in your Web site's DocumentRoot directory. Th

second cause is usually related to an incorrect securitcontext for the Web page's file. Please refer to th

"General Configuration Steps" section for further details

Incompatible httpd.conf Files When Upgrading





Your old configuration files will be incompatible whe

upgrading from Apache version 1.3 to Apache 2.X. I

Redhat / Fedora, the new version 2.X defau

configuration file is storein /etc/httpd/conf/httpd.conf.rpmnew. For the simpl

virtual hosting example above, it would be easiest to:

1.Save the old httpd.conf file with anothe

name, httpd.conf-version-1.x for example. Copy th

ServerName, NameVirtualHost, and VirtualHos

containers from the old file and place them in thand place them in the new httpd.conf.rpmnew file.

2.Copy the httpd.conf.rpmnew file an nam

it httpd.conf

3.Restart Apache

With other distributions, the procedure is similar; jusplace your containers in the new default configuratio

file and restart Apache.

Server Name Errors

All ServerName directives must list a domain that

resolvable in DNS, or else you'll get an error similar tthese when starting httpd.

Starting httpd: httpd: Could not determine the server

fully qualified domain name, using 127.0.0.1 fo



ServerName

Starting httpd: [Wed Feb 04 21:18:16 2004] [error] (EA2)Name or service not known: Failed to resolve serve

name for 192.16.1.100 (check DNS) -- or specify a

explicit ServerName

You can avoid this by adding a default gener

ServerName directive at the top of the httpd.conf fil

that references localhost instead of the defaunew.host.name:80.

#ServerName new.host.name:80

ServerName localhost

The Apache Status Log Files

The /var/log/httpd/access_log file is updated after ever

HTTP query and is a good source of general purpos

information about your website. There is a fixe

formatting style with each entry being separated b

spaces or quotation marks. Table 20-3 lists the layout.

Table 20-3 Apache Log File Format

Field

NumberDescription Separator



1 IP Address of the remote web

surfer

Spaces

2 Time Stamp SquareBrackets []

3 HTTP query including the web

page served

Quotes ""

4 HTTP result code Spaces

5 The amount of data in bytes

sent to the remote web

browser

Spaces

6 The web page that contained

the link to the page served.

Quotes ""

7 The version of the web

browser used to get the page

Quotes ""

Upon examining the entry, you can determine tha

someone at IP address 67.119.25.115 on February 15

looked at the web page /dns-static.htm returning

successful 200 status code. The amount of data senwas 15190 bytes and the surfer got to the site b

clicking on th

linkhttp://www.linuxhomenetworking.com/sendmail.htm





using Microsoft Internet Explorer version 5.5.

67.119.25.115 - - [15/Feb/2003:23:06:51 -0800] "GE

/dns-static.htm HTTP/1.1" 200 15190

"http://www.linuxhomenetworking.com/sendmail.htm"

"Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 4.0

AT&T CSM6.0; YComp 5.0.2.6)"

The HTTP status code can provide some insight into th

types of operations surfers are trying to attempt an

may help to isolate problems with your pages, not th

operation of the Apache. For example 404 errors ar

generated when someone tries to access a web pag

that doesn't exist anymore. This could be caused b

incorrect URL links in other pages on you site. Table 20

4 has some of the more common examples.

Table 20-4 HTTP Status Codes

HTT

P

Cod

e

Description

200 Successful request

304 Successful request, but the web page

requested hasn't been modified since the





current version in the remote web browser's

cache. This means the web page will not be

sent to the remote browser, it will just use its

cached version instead. Frequently occurs

when a surfer is browsing back and forth on a

site.

401 Unauthorized access. Someone entered an

incorrect username / password on a password

protected page.

403 Forbidden. File permissions or contexts

prevents Apache from reading the file. Often

occurs when the web page file is owned by

user "root" even though it has universal read

access.

404 Not found. Page requested doesn't exist.

500 Internal server error. Frequently generated by

CGI scripts that fail due to bad syntax. Check

your error_log file for further details on the

script's error message.

The Apache Error Log Files

The /var/log/httpd/error_log file is a good source fo

error information. Unlike the /var/log/httpd/access_lo



file, there is no standardized formatting.

Typical errors that you'll find here are HTTP queries fo

files that don't exist or forbidden requests for director

listings. The file will also include Apache startup error

which can be very useful.

The /var/log/httpd/error_log file also is the locatio

where CGI script errors are written. Many times CG

scripts fail with a blank screen on your browser; th

/var/log/httpd/error_log file most likely lists the cause othe problem.

Conclusion

Web sites both personal and commercial can be ver

rewarding exercises as they share your interests wit

the world and allow you to meet new people with whom

to develop friendships or transact business.

Unfortunately, even the best Web sites can b

impersonal as they frequently only provide informatio

that the designer expects the visitor to need. E-mai

although ancient in comparison to newer personalize

interactive Internet technologies, such as IP telephon

and instant messaging, has the advantage of being ablto relay documents and other information withou

interrupting the addressee. This allows them to schedul

a response when they are better prepared to answer,



valuable quality when replies need to be complex.

Chapter 21, "Configuring Linux Mail Servers", explain

how to configure a Linux e-smail server to reduce spam

and provide personalized addresses across multipl

domains. No Web site should be without one.

This page was last modified on 17 November 2010

at 06:30.

Content is available under Attribution

NonCommercial-NoDerivs 2.5 .

Privacy policy

About Linux Home Networking

Disclaimers

http://www.linuxhomenetworking.com/wiki/index.php/Quick_HOWTO_:_Ch21_:_Configuring_Linux_Mail_Servers

http://creativecommons.org/licenses/by-nc-nd/2.5/


http://www.linuxhomenetworking.com/wiki/index.php/Linux_Home_Networking:Privacy_policy

http://www.linuxhomenetworking.com/wiki/index.php/Linux_Home_Networking:About

http://www.linuxhomenetworking.com/wiki/index.php/Linux_Home_Networking:General_disclaimer


http://www.linuxhomenetworking.com/wiki/index.php/Quick_HOWTO_:_Ch21_:_Configuring_Linux_Mail_Servers



http://www.linuxhomenetworking.com/wiki/index.php/Linux_Home_Networking:Privacy_policy

http://www.linuxhomenetworking.com/wiki/index.php/Linux_Home_Networking:About

http://www.linuxhomenetworking.com/wiki/index.php/Linux_Home_Networking:General_disclaimer

97798065 appache introduction

Documents