Though it is generally thought to be scary to edit a configuration file for anything, for Apache, it doesn't have to be. The configuration can be found in the
apache_1.3.9/conf/ directory, and, though there are a bunch of files available, you only really need three of them.
Firstly, there is
httpd.conf, which contains directives and configurations relating to the operation of the server as a whole. For example, server logs and server management. Next on the list, there is
srm.conf. This file contains the configurations for the management of resources in the filesystem, such as aliases, directory indexes, etc. Lastly,
access.conf. This file contains information on access control in whatever directories you please. All the other files, well you can just leave them be.
When you first install Apache though, the files are not named exactly like this, they seem to be named
name.conf-dist. This means it is the distribution copy of the file. Since we like to have backup copies of anything and everything, just use a command similar to this (from unix)
cp httpd.conf-dist httpd.conf
Or, for windows, just copy the file, and rename it.
Another note, before we begin, you must restart Apache before any changes to the configuration files take effect. This is because the files are loaded upon initiation, so these changes would not be loaded otherwise.
The Apache documentation can be extremely helpful for users just starting to configure their server. At http://www.apache.org/docs-1.2/mod/directives.html, you can find a listing of available directives (configurations) for your server, with explanations as well. It just be noted though that the directives listed are for version 1.2, not the new 1.3 version. Most of them should be the same though, but some may be gone, and new ones may exist.
Doesn't sound like a tip? Well, it's hard to configure something exactly for your needs without knowing exactly what it can do. So, with that said, this is definitely an important tip.
There is also a book available containing the directives. It is a handy desktop companion, and includes a printed version of the installation and general administration portion of the Apache documentation, Apache Web Server Installation and Administration Guide, which details the process of installing and administering the Apache Web Server.
Knowing your directives can also make your life more convenient. If you don't like where Apache has set your DocumentRoot (where you put your HTML and other files), you can easily change it in httpd.conf with this directive
Or if you want to set where e-mails are to be sent if there are server problems, just use this directive;
Now that should be an excuse to get out and learn more.... it will make your life easier.
When you don't just want to serve your users plain old HTML, but don't have the expertise yet to write up some CGI scripts (or are just lazy), try out Apache's Server Side Includes (SSI).
So what is SSI? Basically, it is an HTML document containing special commands within. If it is named appropriately, Apache will pre-parse the document upon its request, and send you the resulting document. SSI is controlled by the module named
mod_include. With SSI, you may do a variety of things, such as displaying some environmental variables, displaying the date, or even including external files within your document.
Before you can use SSI, you must make sure the
mod_include module was compiled with the rest of Apache. It is included by default, but you may have commented it out when editing
Configuration.tmpl earlier. If that is the case, uncomment the line, and re-compile Apache.
Once that is finished, open up your httpd.conf file. Look for the section found below:
To use server-parsed HTML files
AddType text/html .shtml
AddHandler server-parsed .shtml
Make sure you get rid of the comments in front of the lines (the #'s), as they are commented by default. Notice how they use
.shtml? You can change this to any extension you want really, you just have to remember to name your SSI files later with these extensions.
After you change these directives in the configuration files, restart Apache, and let's make a test SSI file.
Since we are using
.shtml as our SSI extension, we will name our file
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HEAD><TITLE> Test Server Side Includes </TITLE></HEAD>
Current Date: <!--#echo var="DATE_LOCAL" -->
<P>Document Name: <!--#echo var="DOCUMENT_NAME" -->
If it looks right, and all your blanks are filled in, SSI is properly enabled on your server. Congratulations!
For more information on SSI, check out TheScripts.com's SSI section at http://ssi.thescripts.com/.
After you graduated from SSI, it's time to setup your server to use CGI's. CGI stands for Common Gateway Interface, but for some reason people always confuse it with Perl, the most popular language used for CGI. In fact, CGI can be any language really, such as C/C++, Java, TCL, or Perl, plus many others.
The module controlling CGI in Apache is called
mod_cgi and is compiled by default. If you removed it from
Configuration.tmpl though, you must add it back in, and re-compile Apache before you can proceed.
The first method of enabling CGI is by creating certain directory that contains the scripts.
A ScriptAlias is just like a normal Alias, except the documents are treated as applications, and not treated as documents when requested by the client.
A typical ScriptAlias setup looks like so
ScriptAlias /cgi-bin/ "@@ServerRoot@@/cgi-bin/"
/cgi-bin/ an alias to your Server Root/cgi-bin/ directory.
@@ServerRoot@@ reflects the ServerRoot variable you set near the top of the configuration file. You can write it any way really, such as
ScriptAlias /cgi-bin/ "/usr/local/apache/cgi-bin/"
or wherever you desire to put the cgi-bin directory. You would follow the above configuration with the following
AddHandler cgi-script .cgi .pl
The AddHandler part allows you to have CGI scripts with
.pl extensions in this case.
Here is the other method. This method allows you to use CGI outsite of ScriptAliased directories. You would use the following configuration;
AddHandler cgi-script .cgi .pl
Notice it isn't found inside a Directory container? This way, the directive AddHandler applies to all of the documents, not just the documents found within a certain directory. Here, we allow
.pl extensions once again for our CGI scripts. You can use whatever.
CGI applications, when executed, are run under the same name as the user that owns the Apache server process. By default, the user is called
'nobody', as specified by the User and Group Directive. These directives can only work if the Apache server is started by the user root.
In most cases, you won't have to change a thing here. This is not always suitable though, as, if you have multiple users on your system, you might want CGI's to run under the name of the user. This is excellent for virtual hosting systems, as you could have the CGI run under the customer's name and access their files.
To counter this problem, Apache created the suEXEC program, included with the Apache server. To learn more about how to use it for your system, check out http://www.apache.org/docs-1.2/suexec.html.
Ever notice how some sites have their own error documents? For instance, try going here (http://www.thescripts.com/nopage.html). You get a 404 error, but not just any 404 error, we have a customized 404 error page.You can do this for any other error you can get as well (we also have a 403 error page).
FYI, 404 errors mean the page was not found, and 403 means you do not have access to a particular document.
So how do we do it? It's actually quite simple. Instead of using Apache's default/kinda ugly error pages, you can specify certain files to be returned for certain errors.
The directive being used here is called ErrorDocument, and below we find an example
ErrorDocument 404 /fourohfour.html
This is, as you might have figured out, the 404 error page. It is located in this case in the htdocs directory, and called
fourohfour.html. If you accessed it from the browser, it would be at
To add another type of error document, for instance, 403, you would just do the following;
ErrorDocument 403 /fourohthree.html
So as you can see, the first argument in the directive ErrorDocument is the error number. The second is the location of the page.
Just a note, it would be best to use full image and link paths in an error document. This is because using relative links/image paths would be inaccurate. For instance, if you went to http://www.thescripts.com/nothere/nothere.html, the fourohfour.html page would be served as if it was located in the nothere directory, yet it is really in the root directory of your html documents. For more information on the ErrorDocument directive, visit http://www.apache.org/docs/mod/core.html#errordocument