The Quick Road to an Intranet Web Server

Apache and Linux make the task simple.
How to Configure

Apache has many wonderful configuration options available. To someone who has never managed a web server, the list of options might seem quite daunting. However, it is possible to employ a simple cookbook method to get your web server up and running in short order. The following values will produce a working Intranet server which should perform marvelously in most organizations. Of course, if you have special security requirements, a review of the Apache documentation is quite helpful.

Any Linux distribution with an easy installation of Apache will likely have a reasonable set of parameters already enabled. Even if your web server is live seconds after installation, you may want to review the configuration files just to find out what features have been enabled and disabled by default.

The Apache configuration generally has four files of note. In Red Hat, these are found in /etc/httpd/conf/. In Debian, they are located in /etc/apache/. If you built Apache from the sources as described above, they should be in /usr/local/etc/apache/conf/. The four files are access.conf, httpd.conf, srm.conf and mime.types.

If the files are not found in your kit, you should be able to locate the same group of files with names ending in .conf-dist. Simply copy each of these files to the appropriate location (e.g., /etc/httpd/conf/ if you are using Red Hat) using the .conf file type, and edit the files so that they contain the parameters described below. Note that the Apache-supplied configuration files contain useful hints not shown here for the sake of space, as well as many additional parameters not discussed here. So, it is best to edit the files to contain the following parameters, rather than attempting to construct new configuration files from scratch.

Of the four files, mime.types is the least likely to require modifications. It is a table which associates MIME headers with file types. For example, the table will say that a file ending with .gz should generate a MIME header of application/x-gzip.

The most likely candidate for parameter adjustment is the access configuration definition. In access.conf, try using the following values:

<Directory /home/httpd/html>
Options Indexes Includes ExecCGI FollowSymLinks
AllowOverride None
order allow,deny
allow from all
</Directory>

In this example taken from a modified Red Hat file, this entry says that the main HTML files for this server will be stored in /home/httpd/html. The options include:

  • Indexes: if the user specifies a URL that points to a directory name rather than a file name and that directory does not contain an index file (such as index.html), Apache will display a list of the files contained in the specified directory. If you don't want this behavior, simply omit the “Indexes” keyword from the “Options” line.

  • Includes: this allows the server to include files as directed.

  • ExecCGI: if the URL specified is actually a CGI script, this will allow that script to execute. If you are not interested in CGI scripts, don't include the keyword.

  • FollowSymLinks: Let's say that I've created a symbolic link to my CD drive in this directory. This keyword will instruct Apache to allow access to that CD as if it were a subdirectory of this directory. This facility can be quite handy if you wish to serve up the contents of a CD or allow access to the HOWTOs which normally reside in a tree such as /usr/doc. One quick symbolic link, and you can allow Apache to serve those files without moving them or creating individual symbolic links. But remember to create symbolic links with care, or else you might find that your web site is serving up documents you never intended to be universally available.

In the above example, the remaining directives translate (roughly) to “don't override the normal access rules”, “evaluate rules to allow access before the rules to deny access” and “allow access from all hosts”. Together, these rules add up to “if it's there and they ask nicely, give it to them”.

The CGI directory entry will generally look more minimal, like:

<Directory /home/httpd/cgi-bin>
AllowOverride None
Options None
</Directory>

The parameters that define the operational parameters for the Apache daemon in httpd.conf are as follows:

HostnameLookups on
If HostnameLookups is “on”, the server will use DNS to try to determine the user's host name for logging purposes.
User nobody
Group nobody
User and Group determine the access privileges of the remote user. The server will act as if it were a job created by the specified user and group (in this case, “nobody”).
ServerAdmin root@localhost
ServerAdmin sets the user name and host to receive mail messages that might be generated by the daemon.
ServerRoot /etc/httpd
ServerRoot sets the base directory for configuration and log files.
ErrorLog logs/error_log
TransferLog logs/access_log
RefererLog logs/referer_log
AgentLog logs/agent_log
These parameters specify the name and location of various log files. The directories specified are relative to the ServerRoot directory. Once you've run Apache for awhile, examine these log files. In them, you'll find information about which pages were accessed when and by whom. You'll even find information about the page that called your page and the type of browser the user was employing to look at your site.
MinSpareServers 5
MaxSpareServers 10
StartServers 5
MaxClients 150
These parameters deal with the fact that Apache generates child processes before they are needed in order to deal with any sudden increase in incoming traffic. These parameters specify the minimum and maximum number of unused children which should exist at any point in time. They also specify the absolute minimum and maximum number of children which should be available. Using the command ps ax will reveal the multiple children which the Apache daemon is currently using.

The file srm.conf contains many different items. It deals largely with the name space of the server as well as how the server responds to requests. Of special interest are the following lines:

DocumentRoot /home/httpd/html
Alias /icons/ /home/httpd/icons/
ScriptAlias /cgi-bin/ /home/httpd/cgi-bin/
UserDir public_html

DocumentRoot specifies the top of the directory tree that contains the pages to be served. Alias allows the specified directory to be accessed by a pseudonym, even though it is not under the DocumentRoot tree. ScriptAlias is like Alias except that the directory will contain CGI scripts. UserDir specifies the user's subdirectory to look in for any URL that uses a /~username/ specification. For example, if the user's default directory is normally /home/username/, then the user's default HTML directory will be /home/username/public_html/.

______________________

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

The Quick Road to an Intranet Web Server

Anonymous's picture

Thanks Russell. The help is appreciated.

White Paper
Linux Management with Red Hat Satellite: Measuring Business Impact and ROI

Linux has become a key foundation for supporting today's rapidly growing IT environments. Linux is being used to deploy business applications and databases, trading on its reputation as a low-cost operating environment. For many IT organizations, Linux is a mainstay for deploying Web servers and has evolved from handling basic file, print, and utility workloads to running mission-critical applications and databases, physically, virtually, and in the cloud. As Linux grows in importance in terms of value to the business, managing Linux environments to high standards of service quality — availability, security, and performance — becomes an essential requirement for business success.

Learn More

Sponsored by Red Hat

White Paper
Private PaaS for the Agile Enterprise

If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.

Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.

Learn More

Sponsored by ActiveState