Web Server

Web Server

Introduction
Apache is probably the most popular Linux-based Web server application in use. Once you have DNS correctly setup and your server has access to the Internet, you'll need to configure Apache to accept surfers wanting to access your Web site.
This chapter explains how to configure Apache in a number of commonly encountered scenarios for small web sites.
Download and Install The Apache Package
Most RedHat and Fedora Linux software products are available in the RPM format. When searching for the file, remember that the Apache RPM's filename usually starts with the word httpd followed by a version number, as in httpd-2.0.48-1.2.rpm. It is best to use the latest version of Apache. (For more on RPMs, see Chapter 6, "Installing Linux Software").
When searching for the file, remember that the Redhat / Fedora Apache RPM package's filename usually starts with the word httpd followed by a version number, as in httpd-2.0.48-1.2.rpm. With Ubuntu / Debian the package name will have the apache prefix instead.
Note: Unless otherwise stated, the sample configurations covered in this chapter will be for Redhat / Fedora distributions. If you use Debian / Ubuntu, don’t worry, there will be annotations to make you aware of the differences.
How To Get Apache Started
Setting up the Apache server is easy to do, but the procedure differs between Linux distributions.


Redhat / Fedora
Use the chkconfig command to configure Apache to start at boot:
[root@bigboy tmp]# chkconfig httpd on
Use the httpd init script in the /etc/init.d directory to start,stop, and restart 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 with
[root@bigboy tmp]# pgrep httpd
you should get a response of plain old process ID numbers.

General Configuration Steps
The configuration file used by Apache is /etc/httpd/conf/httpd.conf in Redhat / Fedora distributions and /etc/apache*/httpd.conf in Debian / Ubuntu distributions. As for most Linux applications, you must restart Apache before changes to this configuration file take effect.
Where To Put Your Web Pages
All the statements that define the features of each web site are grouped together inside their own section, or container, in the httpd.conf file. The most commonly used statements, or directives, inside a container are:
● servername: Defines the name of the website managed by the container. This is needed in named virtual hosting only, as I'll explain soon.
● DocumentRoot: Defines the directory in which the web pages for the site can be found.
By default, Apache searches the DocumentRoot directory for an index, or home, page named index.html. So for example, if you have a servername of www.my-site.com with a DocumentRoot directory of /home/www/site1/, Apache displays the contents of the file /home/www/site1/index.html when you enter http://www.my-site.com in your browser.
Some editors, such as Microsoft FrontPage, create files with an .htm extension, not .html. This isn't usually a problem if all your HTML files have hyperlinks pointing to files ending in .htm as FrontPage does. The problem occurs with Apache not recognizing the topmost index.htm page. The easiest solution is to create a symbolic link (known as a shortcut to Windows users) called index.html pointing to the file index.htm. This then enables you to edit or copy the file index.htm with index.html being updated automatically. You'll almost never have to worry about index.html and Apache again!
This example creates a symbolic link to index.html in 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:43 index.htm
lrwxrwxrwx 1 root root 9 Jun 21 18:05 index.html -> index.htm
[root@bigboy site1]#
The l at the very beginning of the index.html entry signifies a link and the -> the link target.
The Default File Location
By default, Apache expects to find all its web page files in the /var/www/html/ directory with a generic DocumentRoot statement at the beginning of httpd.conf. The examples in this chapter use the /home/www directory to illustrate how you can place them in other locations successfully.
File Permissions And Apache
Apache will display Web page files as long as they are world readable. You have to make sure you make all the files and subdirectories in your DocumentRoot have the correct permissions.
It is a good idea to have the files owned by a nonprivileged user so that Web developers can update the files using FTP or SCP without requiring the root password.
To do this:
1. Create a user with a home directory of /home/www.
2. Recursively change the file ownership permissions of the /home/www directory and all its subdirectories.
3. Change the permissions on the /home/www directory to 755, which allows all users, including the 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:43 index.htm
lrwxrwxrwx 1 www users 9 Jun 25 18:05 index.html -> index.htm
[root@bigboy tmp]#
Note: Be sure to FTP or SCP new files to your web server as this new user. This will make all the transferred files automatically have the correct ownership.
If you browse your Web site after configuring Apache and get a "403 Forbidden" permissions-related error on your screen, then your files or directories under your DocumentRoot most likely have incorrect permissions. Appendix II, "Codes, Scripts, and Configurations," has a short script that you can use to recursively set the file permissions in a directory to match those expected by Apache. You may also have to use the Directory directive to make Apache serve the pages once the file permissions have been correctly set. If you have your files in the default /home/www directory then this second step becomes unnecessary.

user root creates a directory /home/www/site1 in which the pages for a new Web site will be placed. Using the ls -Z command, you can see that the user_home_t security label has been assigned to the directory and the index.html page 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_t site1
[root@bigboy tmp]# touch /home/www/site1/index.html
[root@bigboy tmp]# ls -Z /home/www/site1/index.html
-rw-r--r-- root root root:object_r:user_home_t /home/www/site1/index.html
[root@bigboy tmp]#
Accessing the index.html file via a Web browser gets a "Forbidden 403" error on your screen, even though the permissions are correct. Viewing the /var/log/httpd/error_log gives a "Permission Denied" message and the /var/log/messages file shows kernel audit errors.
[root@bigboy tmp]# tail /var/log/httpd/error_log
[Fri Dec 24 17:59:24 2004] [error] [client 216.10.119.250] (13)Permission denied: access to / denied
[root@bigboy tmp]# tail /var/log/messages
Dec 24 17:59:24 bigboy kernel: audit(1103939964.444:0): avc: denied { getattr } for pid=2188 exe=/usr/sbin/httpd path=/home/www/site1 dev=hda5 ino=73659 scontext=system_u:system_r:httpd_t tcontext=root:object_r:user_home_t tclass=dir
[root@bigboy tmp]#
Security Contexts For CGI Scripts
You can use Apache to trigger the execution of programs called Common Gateway Interface (CGI) scripts. CGI scripts can be written in a variety of languages, including PERL and PHP, and can be used to do such things as generate new Web page output or update data files. A Web page's Submit button usually has a CGI script lurking somewhere beneath. By default, CGI scripts are placed in the /var/www/cgi-bin/ directory as defined by the ScriptAlias directive you'll find in the 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/ will trigger Apache to search for an equivalent executable file in this directory. So, for example, the URL, http://192.168.1.100/cgi-bin/test/test.cgi actually executes the script file /var/www/cgi-bin/test/test.cgi.
SELinux contexts have to be modified according to the values in Table 20.1 for a CGI script to be run in another directory or to access data files. In the example case, the PERL script test.cgi was created to display the word "Success" on the screen of your Web browser.
#!/usr/bin/perl

# CGI Script "test.cgi"

print qq(
#
#
#
#
#
#
#
Success!
#
#”
);
The ScriptAlias directive has been set to point to /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 to httpd_sys_script_exec_t, and then creates the script /home/www/cgi-bin/test/test.cgi mentioned previously with the correct executable file permissions.
[root@bigboy tmp]# mkdir -p /home/www/cgi-bin/test
[root@bigboy tmp]# chcon -h -t 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-bin
drwxr-xr-x root root 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/cgi-bin/test/test.cgi
[root@bigboy tmp]#
Accessing the URL http://192.168.1.100/cgi-bin/test/test.cgi is successful. Problems occur when the same test.cgi file needs to be used by a second Web site housed on the same Web server. The file is copied to a directory /web/cgi-bin/site2/ governed by the ScriptAlias in the second Web site's container (explained later), but the security context label isn't 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/cgi-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_t /web/cgi-bin/site2/test.cgi
[root@bigboy tmp]#
Permission denied and kernel audit errors occur once more; you can fix them only by changing the security context of the test.cgi file.
[root@bigboy tmp]# tail /var/log/httpd/error_log
[Fri Dec 24 18:36:08 2004] [error] [client 216.10.119.250] (13)Permission denied: access to /cgi-bin/texcelon/test.cgi denied
[root@bigboy tmp]# tail /var/log/messages
Dec 24 18:36:08 bigboy kernel: audit(1103942168.549:0): avc: denied { getattr } for pid=2191 exe=/usr/sbin/httpd path=/web/cgi-bin/site2/test.cgi dev=hda5 ino=77491 scontext=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, you can turn them off system wide by editing your /etc/selinux/config file, modifying the SELINUX parameter to disabled. SELinux will be disabled after your next reboot.
Named Virtual Hosting
You can make your Web server host more than one site per IP address by using Apache's named virtual hosting feature. You use the NameVirtualHost directive in the /etc/httpd/conf/httpd.conf file to tell Apache which IP addresses will participate in this feature.
The containers in the file then tell Apache where it should look for the Web pages used on each Web site. You must specify the IP address for which each container applies.
Named Virtual Hosting Example
Consider an example in which the server is configured to provide content on 97.158.253.26. In the code that follows, notice that within each container you specify the primary Web site domain name for that IP address with the ServerName directive. The DocumentRoot directive defines the directory that contains the index page for that site.
You can also list secondary domain names that will serve the same content as the primary ServerName using the ServerAlias directive.
Apache searches for a perfect match of NameVirtualHost, , and ServerName when making a decision as to which content to send to the remote user's Web browser. If there is no match, then Apache uses the first in the list that matches the target IP address of the request.
This is why the first statement contains an asterisk: to indicate it should be used for all other Web queries.
NameVirtualHost 97.158.253.26


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



servername www.my-site.com
Directives for site #1



servername www.another-site.com
Directives for site #2

Be careful with using the asterisk in other containers. A with a specific IP address always gets higher priority than a statement with an * intended to cover the same IP address, even if the ServerName directive doesn't match. To get consistent results, try to limit the use of your statements to the beginning of the list to cover any other IP addresses your server may have.
You can also have multiple NameVirtualHost directives, each with a single IP address, in cases where your Web server has more than one IP address.
IP-Based Virtual Hosting
The other virtual hosting option is to have one IP address per Web site, which is also known as IP-based virtual hosting. In this case, you will not have a NameVirtualHost directive for the IP address, and you must only have a single container per IP address.
Also, because there is only one Web site per IP address, the ServerName directive isn't needed in each container, unlike in named virtual hosting.
IP Virtual Hosting Example: Single Wild Card
In this example, Apache listens on all interfaces, but gives the same content. Apache displays the content in the first directive even if you add another right after it. Apache also seems to enforce the single container per IP address requirement by ignoring any ServerName directives you may use inside it.

DocumentRoot /home/www/site1

IP Virtual Hosting Example: Wild Card and IP addresses
In this example, Apache listens on all interfaces, but gives different content for addresses 97.158.253.26 and 97.158.253.27. Web surfers get the site1 content if they try to access the web server on any of its other IP addresses.

DocumentRoot /home/www/site1



DocumentRoot /home/www/site2



DocumentRoot /home/www/site3

Configuration - Multiple Sites And IP Addresses
To help you better understand the edits needed to configure the /etc/httpd/conf/httpd.conf file, I'll walk you through an example scenario. The parameters are:
● The web site's systems administrator previously created DNS entries for www.my-site.com, my-site.com, www.my-cool-site.com and www.default-site.com to map the IP address 97.158.253.26 on this web server. The domain www.another-site.com is also configured to point to alias IP address 97.158.253.27. The administrator wants to be able to get to www.test-site.com on all the IP addresses.
● Traffic to www.my-site.com, my-site.com, and www.my-cool-site.com must get content from subdirectory site2. Hitting these URLs causes Apache to display the contents of file index.html in this directory.
● Traffic to www.test-site.com must get content from subdirectory site3.
● Named virtual hosting will be required for 97.158.253.26 as in this case we have a single IP address serving different content for a variety of domains. A NameVirtualHost directive for 97.158.253.26 is therefore required.
● Traffic going to www.another-site.com will get content from directory site4.
● All other domains pointing to this server that don't have a matching ServerName directive will get Web pages from the directory defined in the very first container: directory site1. Site www.default-site.com falls in this category.
How do these requirements translate into code? Here is a sample snippet of a working httpd.conf file:

ServerName localhost
NameVirtualHost 97.158.253.26
NameVirtualHost 97.158.253.27

#
# Match a webpage directory with each website
#

DocumentRoot /home/www/site1



DocumentRoot /home/www/site2
ServerName www.my-site.com
ServerAlias my-site.com, www.my-cool-site.com



DocumentRoot /home/www/site3
ServerName www.test-site.com



DocumentRoot /home/www/site4
ServerName www.another-site.com



#
# Make sure the directories specified above
# have restricted access to read-only.
#

Order allow,deny
Allow from all

AllowOverride FileInfo AuthConfig Limit
Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec

Order allow,deny
Allow from all


Order deny,allow
Deny from all



These statements would normally be found at the very bottom of the file where the virtual hosting statements reside. The last section of this configuration snippet has some additional statements to ensure read-only access to your Web pages with the exception of Web-based forms using POSTs (pages with "submit" buttons). Remember to restart Apache every time you update the httpd.conf file for the changes to take effect on the running process.
Note: You will have to configure your DNS server to point to the correct IP address used for each of the Web sites you host. Chapter 18, "Configuring DNS", shows you how to configure multiple domains, such as my-site.com and another-site.com, on your DNS server.





The Apache configuration file is: /etc/httpd/conf/httpd.conf
Web pages are served from the directory as configured by the DocumentRoot directive. The default directory location is:
● Red Hat 7.x-9, Fedora Core, Red Hat Enterprise 4, CentOS 4: /var/www/html/
● Red Hat 6.x and older: /home/httpd/html/
● Suse 9.x: /srv/www/htdocs/
● Ubuntu (dapper 6.06) / Debian: /var/www/html
The default home page for the default configuration is index.html. Note the pages should not be owned by user apache as this is the process owner of the httpd web server daemon. If the web server process is comprimised, it should not be allowed to alter the files. The files should of course be readable by user apache.
Apache may be configured to run as a host for one web site in this fashion or it may be configured to serve for multiple domains. Serving for multiple domains may be achieved in two ways:
● Virtual hosts: One IP address but multiple domains - "Name based" virtual hosting.
● Multiple IP based virtual hosts: One IP address for each domain - "IP based" virtual hosting.
The default configuration will allow one to have multiple user accounts under one domain by using a reference to the user account: http://www.domain.com/~user1/. If no domain is registered or configured, the IP address may also be used: http://XXX.XXX.XXX.XXX/~user1/.
[Potential Pitfall] The default umask for directory creation is correct by default but if not use: chmod 755 /home/user1/public_html
[Potential Pitfall] When creating new "Directory" configuration directives, I found that placing them by the existing "Directory" directives to be a bad idea. It would not use the .htaccess file. This was because the statement defining the use of the .htaccess file was after the "Directory" statement. Previously in RH 6.x the files were separated and the order was defined a little different. I now place new "Directory" statements near the end of the file just before the "VirtualHost" statements.
For users of Red Hat 7.1, the GUI configuration tool apacheconf was introduced for the crowd who like to use pretty point and click tools.
Files used by Apache:
● Start/stop/restart script:
● Red Hat/Fedora/CentOS: /etc/rc.d/init.d/httpd
● SuSE 9.3: /etc/init.d/apache2
● Ubuntu (dapper 6.06) / Debian: /etc/init.d/apache2
● Apache main configuration file:
● Red Hat/Fedora/CentOS: /etc/httpd/conf/httpd.conf
● SuSE: /etc/apache2/httpd.conf
(Need to add directive: ServerName host-name)
● Ubuntu (dapper 6.06) / Debian: /etc/apache2/apache2.conf
● Apache suplementary configuration files:
● Red Hat/Fedora/CentOS: /etc/httpd/conf.d/component.conf
● SuSE: /etc/apache2/conf.d/component.conf
● Ubuntu (dapper 6.06) / Debian:
● Virtual domains: /etc/apache2/sites-enabled/domain
(Create soft link from /etc/apache2/sites-enabled/domain to /etc/apache2/sites-available/domain to turn on)
● Additional configuration directives: /etc/apache2/conf.d/
● Modules to load: /etc/apache2/mods-available/
(Soft link to /etc/apache2/mods-enabled/ to turn on)
● Ports to listen to: /etc/apache2/ports.conf
● /var/log/httpd/access_log and error_log - Red Hat/Fedora Core Apache log files
(Suse: /var/log/apache2/)
Start/Stop/Restart scripts: The script is to be run with the qualifiers start, stop, restart or status.
i.e. /etc/rc.d/init.d/httpd restart. A restart allows the web server to start again and read the configuration files to pick up any changes. To have this script invoked upon system boot issue the command chkconfig --add httpd.
Also Apache control tool: /usr/sbin/apachectl start
Apache Control Command: apachectl:
Red Hat / Fedora Core / CentOS: apachectl directive
Ubuntu dapper 6.06 / Debian: apache2ctl directive
Directive Description
start Start the Apache httpd daemon. Gives an error if it is already running.
stop Stops the Apache httpd daemon.
graceful Gracefully restarts the Apache httpd daemon. If the daemon is not running, it is started. This differs from a normal restart in that currently open connections are not aborted.
restart Restarts the Apache httpd daemon. If the daemon is not running, it is started. This command automatically checks the configuration files as in configtest before initiating the restart to make sure the daemon doesn't die.
status Displays a brief status report.
fullstatus Displays a full status report from mod_status. Requires mod_status enabled on your server and a text-based browser such as lynx available on your system. The URL used to access the status report can be set by editing the STATUSURL variable in the script.
configtest
-t Run a configuration file syntax test.

Apache Configuration Files:
● /etc/httpd/conf/httpd.conf: is used to configure Apache. In the past it was broken down into three files. These may now be all concatenated into one file.
● /etc/httpd/conf.d/application.conf: All configuration files in this directory are included during Apache start-up. Used to store application specific configurations.
● /etc/sysconfig/httpd: Holds environment variables used when starting Apache.
Basic settings: Change the default value for ServerName www.
Giving Apache access to the file system: It is prudent to limit Apache's view of the file system to only those directories necessary. This is done with the directory statement. Start by denying access to everything, then grant access to the necessary directories.
Deny access completely to file system root ("/") as the default:


Options None
AllowOverride None


Grant access to a user's directory:

AllowOverride None
order allow,deny
allow from all
Options Indexes Includes FollowSymLinks


OR
use the statement UserDir public_html which does this by default for every user account at $HOME/public_html. Change to a comment (add "#" at beginning of line) from Fedora Core default UserDir disable.

File permissions: The Apache web server daemon must be able to read your web pages in order to feed thier contents to the network. Use an appropriate umask and file protection. This works: chmod ugo+r -R public_html
One may also use groups to control permisions.
If the Apache web server can not access the file you will get the error "403 Forbidden" "You don't have permission to access file-name on this server." Note the default permissions on a user directory when first created with "useradd" are:
drwx------ 3 userx userx
You must allow the web server running as user "apache" to access the directory if it is to display pages held there.
Fix with command: chmod ugo+rx /home/userx
drwxr-xr-x 3 userx userx
Change Apache Port number:
"cat /path/to/httpd.conf grep 80"

if where is says 80 (default port) seems to be in context of wha you're doing... change it. httpd.conf

Change Apache Document Root:
cat /etc/httpd/conf/httpd.confgrep DocumentRoot
# DocumentRoot: The directory out of which you will serve your
DocumentRoot "/var/www/html"
# This should be changed to whatever you set DocumentRoot to.
# DocumentRoot /www/docs/dummy-host.example.com