To configure named-based virtual hoststhe most common typeuncomment the NameVirtualHost directive in the httpd.conf file:
NameVirtualHost *:80
If you're using a port other than 80 , enter it on this line.
Next, create a VirtualHost container for each virtual host. There is an example in the comments near the end of the httpd.conf file:
#<VirtualHost *:80>
# ServerAdmin webmaster@dummy-host.example.com
# DocumentRoot /www/docs/dummy-host.example.com
# ServerName dummy-host.example.com
# ErrorLog logs/dummy-host.example.com-error_log
# CustomLog logs/dummy-host.example.com-access_log common
#</VirtualHost>
Copy and uncomment these lines, substituting the correct values for these directives:
ServerAdmin
Insert the email contact for the administrator for this virtual host.
DocumentRoot
Enter the document root for this virtual host. If you're using SELinux, it is easiest to use subdirectories of /var/www/html for the virtual host document roots.
ServerName , ServerAlias
The main name of the web server and any assigned nicknames, respectively. These names must appear in the DNS entries for this host. It's a good idea to include common misspellings within your domain name, such as ww.fedorabook.com and wwww.fedorabook.com .
Your DNS configuration must include all of the hostnames used for ServerName and ServerAlias or be configured with a wildcard hostname (*).
ErrorLog , CustomLog
Set these to the name of the logfiles you wish to use for errors and for normal access, respectively. At the end of CustomLog , specify the logfile format combined so that referrer information is included in your logfile.
A completed virtual host container will look like this:
<VirtualHost *:80>
ServerAdmin webadministrator@fedorabook.com
DocumentRoot /var/www/html/fedorabook
ServerName fedorabook.com
ServerAlias www.fedorabook.com ww.fedorabook.com wwww.fedorabook.com
ErrorLog logs/fedorabook-error_log
CustomLog logs/fedorabook-access_log combined
</VirtualHost>
7.5.1.7. Enabling CGI scripts in every directory
Fedora's default Apache configuration permits CGI scripts only in the /cgi-bin/ script alias directory, /var/www/cgi-bin/ . This makes it easy to keep an eye on all of the scripts, and many webmasters prefer this.
However, on a complex site with different web applications running, it is often desirable to group files by application, allocating one directory for each application and building a structure within that directory for the scripts, HTML, stylesheets, and multimedia files, rather than mixing the scripts for all of the applications together into a single directory.
To enable CGI scripts in every directory, uncomment the AddHandler directive for the .cgi extension in httpd.conf :
AddHandler cgi-script .cgi
Then add ExecCGI to the Options directive for the DocumentRoot :
<Directory "/var/www/html">
...
Options Indexes FollowSymLinks ExecCGI
...
</Directory>
Apache will then treat any file with a .cgi extension as a script.
If you want individual users to be able to run scripts, do the same for the ~/public_html directories:
<Directory /home/*/public_html>
...
Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec ExecCGI
...
</Directory>
CGI scripts in users' ~/public_html directories will execute with that user's permission and will therefore be able to read and write any files that the user can read and write. This can be a huge security risk because a single web script can expose any file, email, or database on your system which that user can normally access.
In order to reduce the risk of a script that has been maliciously compromised, scripts that are writable by group or other users or contained in directories that are writable by group or others will not be executed by Apache, and an error message will be logged in /var/log/httpd/suexec.
7.5.1.8. Password-protecting content
Apache can be configured to password-protect content using two files: a password file and an .htaccess file.
Note that passwords are sent in unencrypted form over the network unless you use a secure (SSL) connection, so the security provided by this option is minimal.
First, configure Apache to permit the use of .htaccess files for authentication configuration. If you're using the graphical configuration tool, select the checkbox labeled "Let .htaccess files override directory options."
To configure this without using the graphical tool, add the AuthConfig keyword to the AllowOverride line in the appropriate directory container within httpd.conf :
<Directory "/var/httpd">
...
AllowOverride AuthConfig
...
</Directory>
This option is enabled by default for ~/public_html directories.
An .htaccess file is similar to an httpd.conf file, but it is placed in the directory that you wish to protect. Here is an example:
AuthType Basic
AuthName " team scores "
AuthUserFile /etc/httpd/team_scores_password
Require valid-user
The four directives in this file are required for basic password protection:
AuthType
Specifies the authentication type to be used. Basic indicates that a simple user ID/password pair will be used.
AuthName
Describes the type of data being protected by the password. Most browsers will include this text in the password dialog, as shown in Figure 7-19 .
AuthUserFile
The name of the password file.
Require
Normally set to valid-user , permitting any user with a valid password to access the protected content.