Advertisement
Other

Apache 2 Basic Configuration on Unix-Like Systems

by

In a previous post, we had a look at the Apache HTTP server, what it is, and how it works. Today, we'll handle some of the most important Apache configuration directives, look at what they are for, and learn how to edit them, in order to mold the way our server works to our liking.

The Apache server is a service that runs in the background, waiting for requests from clients connecting to the ports it listens to, in order to take action. Apache either responds to those requests, or leaves related notes in its log files. Its behavior is controlled through its configuration, using what is known as directives (among other things). We'll discuss the most basic directives in this article.


ServerName

The ServerName directive is used to set the host name of the server; this is how the server identifies itself. It uses this name when responding to HTTP requests. You can set this directive either in the server's configuration or virtual hosts. The location of your configuration files depend on both the Apache version and Linux distribution.

<VirtualHost *:80>
	ServerAdmin  webmaster@localhost
	DocumentRoot  /var/www
	ServerName  www.example-site.com
	.
	.
	.
</VirtualHost>

Apache has a great number of directives which you can set and manipulate in order to set your server’s behavior.

If the ServerName directive is not specified, the server tries to obtain it by performing a reverse DNS look-up on its IP address. You should always set a ServerName for the server explicitly; it is the only value you need to set to get your server running after installation.

You will have to use the IP address of your machine if you don't yet have a registered domain name. Otherwise, you would need to add the domain name and IP address to the server's hosts file--the same as you do with your PC's hosts file. By doing this, the server checks its hosts file before consulting with the DNS server. I personally add my IP address/domain name entry to the Apache hosts file to minimize server response time by saving a call to the DNS server.

Assuming our domain name is www.example-site.com and our server's IP address is 50.57.77.153, you need to add the following line to the server's hosts file (/etc/hosts):

50.57.77.153 	www.example-site.com  	example-site.com

After editing the hosts file, you need to restart (or stop and start) Apache. I'll show you how to do this later.


Listen

The Listen directive tells Apache what IP addresses and/or ports it should listen to for incoming requests. If nothing is specified, Apache listens to all addresses and ports on the machine. The default configuration sets the server to listen to port 80, the default port for HTTP communication.

If you only specify an IP address, the server will respond to requests coming to all ports of that address (also called an interface). If only a port number is specified, then Apache responds to requests on the specified port arriving at all interfaces on the machine. If an address and port combination is supplied, then Apache only responds to those specific interface/port combinations.

If your server installation has separate configuration files, you should be able to find or set this directive in the ports.conf file.

You can find this file in the same location as your Apache configuration files (mine is /etc/apache2/ports.conf, but that might be different for other Apache versions and/or Linux distributions).

Let's assume our example site is at IP address 50.57.77.153. To set Apache to listen to ports 80 and 443, the respective default ports for HTTP and HTTPS, you need to enter the following directives in your ports.conf file:

Listen 50.57.77.153:80
Listen 50.57.77.153:443

Alternatively, if you want Apache to listen to ports 80 and 443 on all interfaces regardless of the IP address, you can enter the following:

Listen 80
Listen 443

Web User and Group

On Unix operating systems, it's a good idea to configure Apache to run under a specific user and group instead of root. Doing so makes the server more secure and less vulnerable to attacks. Ideally, the user and group you set should not be able to login to the server (ie: have no login credentials) and no login shell; they will just be used for handling web client requests. Set the Apache user's home directory to the web server's document directory, usually located at /var/www or /usr/local/apache2/htdocs.

groupadd anyUserName
useradd -d /var/www  -g anyUserName -s /bin/false

The example above uses anyUserName as our web user and group; just use a name not reserved for other processes. -d /var/www sets the home directory of the new account to /var/www, and -s /bin/false ensures the new account has no shell access. Next, you need to modify your config file to use the new Apache user and group. If yours says:

User ${APACHE_RUN_USER}
Group ${APACHE_RUN_GROUP}

Then you need to find where these variables are defined and change their values. Usually, the above directive is preceded by a comment letting you know exactly where to set the new values. Otherwise, you will just insert the new user and group name in place of the old. So your final config lines could look like this:

User anyUserName
Group anyUserName

ServerRoot

Apache’s behavior is controlled through its configuration.

Apache's important files, like the server's configuration, error, and log files are kept at the top of the directory tree. This location is the ServerRoot, and you can set a different value in Apache's main config file. Depending on your installation, the default can be something like /usr/local/apache2 or /etc/apache2. Any Apache directives using a relative path will, by default, append to the root path specified in ServerRoot.

When you first install your server, the configuration and log files are placed in the ServerRoot. You can change its value to a new directory, but make sure to copy the configuration files to the new location. Also, make sure you do not to add a trailing slash to the path when you modify the value.


ErrorLog

When an error occurs, Apache logs the error to a log file. The location of the error log is determined by the value specified using the ErrorLog directive. This file is critical because you will refer to it in order to debug errors, solve server configuration problems, and optimize the server.

If the server hosts multiple sites and you want to have separate error logs for each site, you can specify a different file and location for each site in the virtual hosts file.

If you don't, then all sites' errors are logged in the default error log, typically located at /usr/local/apache2/logs/error_log or /var/log/apache2/error.log (once again, depending on your installation).

Please note that the above log paths are absolute. For example, consider the following directive:

ErrorLog logs/error_log

This is a relative path. Therefore, the actual error log location is $ServerRoot/logs/error_log.

The LogLevel directive controls the level of the messages logged in the error logs. By default, it is set to warn, meaning that all messages with the value of warning and higher (as in more critical) will be logged. You can change the value of this directive to adjust the logging level to your preference.


DocumentRoot

The DocumentRoot directive sets the location of the server's public files, aka htdocs. This is the default Apache web server document directory, and its contents are readily and publicly available to clients connecting through the web. It contains the static and dynamic content to be served once the server receives an HTTP request for them. Since files and sub-directories under htdocs are available for the public, it is very important to handle permissions correctly in order to minimize the ability to compromise the server's safety and security.

Depending on your installation, the default DocumentRoot location could be something like /var/www or /usr/local/apache2/htdocs.

If you are hosting multiple websites on the same server, you need to set a different DocumentRoot for each site. This can be done within the respective VirtualHost directive that corresponds to each site. Let's say you have three websites on the same server (eg: www.example-site1.com, www.example-site2.com, www.example-site3.com), your virtual hosts file might look something like the following:

<VirtualHost www.example-site1.com>
    DocumentRoot  /usr/local/apache2/htdocs/example_site1
    ServerName  www.example-site1.com
    .
    .
    .
</VirtualHost>

<VirtualHost www.example-site2.com>
    DocumentRoot  /usr/local/apache2/htdocs/example_site2
    ServerName  www.example-site2.com
    .
    .
    .
</VirtualHost>

<VirtualHost www.example-site3.com>
    DocumentRoot  /usr/local/apache2/htdocs/example_site3
    ServerName  www.example-site3.com
    .
    .
    .
</VirtualHost>

To set a separate error log for each of these domains, which is a good idea, then your virtual hosts file might look something like this:

<VirtualHost www.example-site1.com>
	DocumentRoot  /usr/local/apache2/htdocs/example_site1
	ServerName  www.example-site1.com
	ErrorLog  /usr/local/apache2/logs/site1_error_log 
	.
	.
	.
</VirtualHost>

<VirtualHost www.example-site2.com>
	DocumentRoot  /usr/local/apache2/htdocs/example_site2
	ServerName  www.example-site2.com
	ErrorLog  /usr/local/apache2/logs/site2_error_log 
	.
	.
	.
</VirtualHost>

<VirtualHost www.example-site3.com>
	DocumentRoot  /usr/local/apache2/htdocs/example_site3
	ServerName  www.example-site3.com
	ErrorLog  /usr/local/apache2/logs/site3_error_log 
	.
	.
	.
</VirtualHost>

PidFile

The ServerName directive is used to set the host name of the server; this is how the server identifies itself.

The Apache service first starts as root in order to bind to the privileged port 80 for HTTP (or 443 if using SSL) because port numbers less than 1024 are only reserved to the root user. After the initial execution, children processes spawn to handle client requests which are owned by the Apache user specified in the configuration file. For this reason, you will find one root process and multiple processes belonging to the web user; this root process is the first one initiated when Apache starts. It has a process ID, and this ID is stored in the Pid file on the server. You can control the location of the Pid file by using the PidFile directive in the configuration file.

If you open the file specified in the PidFile directive, you will find a number that corresponds to the parent process ID. You can stop the Apache server by killing the process using its ID number. However, kill the process only as a last resort. We'll discuss the preferred way to stop Apache in a moment.


File Inclusion

It is possible to separate server configuration and settings into multiple files; in fact, some Apache installations actually do so. These multiple files can then be included in the original server config file. This approach is ideal in order to keep your config file light and clear, but it also forces you to look inside multiple files residing in different locations to completely understand how Apache is configured. In any case, below is the syntax for including external config files. Whether or not you want to use file inclusion is up to you:

# Include ports listing:
Include /etc/apache2/ports.conf

# Include generic snippets of statements
Include /etc/apache2/conf.d/

# Include module configuration:
Include /etc/apache2/mods-enabled/*.load
Include /etc/apache2/mods-enabled/*.conf

As you can see from the examples above, you can include a specific file by name, a directory (and thus all files therein), or multiple files by using wildcards.


Start, Stop, and Restart Apache

Every time you edit one of Apache's configuration files, you need to restart (or stop and start) the service so that Apache can load the new configuration. Otherwise, your changes will just remain on file for the next restart or server start. If your changes cause syntax errors in the configuration files, restarting will show you error messages concerning those mistakes. Additionally, the Apache web server will not start until you fix those errors.

To stop the Apache server, type in the following command in the console:

/etc/init.d/apache2 stop

To start the Apache server, type in the following command:

/etc/init.d/apache2 start

To restart the Apache server, type in the following command:

/etc/init.d/apache2 restart

Naturally, you must be logged in with a privileged user in order to execute these commands. You could, however, still run the above commands by adding sudo before each line. This basically tells the system that you are executing the command as a super user (hence the naming, sudo), in which case the system asks you to enter a password before it executes your command. If you don't know that password, ask your server admin. Preceding the above commands with sudo:

sudo /etc/init.d/apache2 stop
sudo /etc/init.d/apache2 start
sudo /etc/init.d/apache2 restart

Conclusion

Apache has a great number of directives, which you can set and manipulate in order to set your server's behavior. This is responsible for Apache's flexibility and power.

Every server administrator will often tweak certain directives, while leaving others completely alone; it all depends on their particular needs. In general, however, the directives discussed in this article are among the most important. Every person working with the Apache server is likely to encounter these directives. Understanding what they are, and what purpose they serve, is paramount to having a working and stable web server.

Related Posts
  • Code
    Web Development
    How to Use New Relic With PHP & WordPressRelic retina preview
    Today we will look at how to monitor a PHP application using New Relic. More specifically we will set up a basic WordPress installation and get some performance data about it, in the New Relic dashboards.Read More…
  • Code
    Web Development
    Easily Deploy Redis Backed Web Apps With DockerDocker wide retina preview
    Learn how to setup and deploy a Redis powered Python web app using Docker.Read More…
  • Computer Skills
    Electronics
    How to Use a Raspberry Pi as a Local Web ServerThumb
    In this tutorial I will show you how to set up a Raspberry Pi to be used as a Local Web Server with SSH and FTP functionality.Read More…
  • Computer Skills
    Electronics
    Run the Ghost Blogging Software on a Raspberry PiGhostpi400
    In this tutorial I will show you how to host a blog on your Raspberry Pi using the Ghost blogging platform. Ghost is a brand new piece of blog software, currently under development which was recently funded by a Kickstarter campaign. Similar to the way Wordpress is distributed, you can opt to purchase a hosted blog or download the software to try out yourself. As Ghost is very new it is still quite simplistic, and this simplicity makes it ideal to run on a Raspberry Pi. You'll be able to write and edit posts and upload images to your blog. I'll also show you how to install google analytics so you can see how many people are reading your website.Read More…
  • Code
    Other
    Setting Up A Staging Environment Staging
    It's common practice to work locally on a project and push revisions to a production server, but the step that people often skip is the staging server. A staging server is a mix between production and development; you get to test your app as if it were in production. Let's review some of the issues that you'll have to consider, as well as the steps needed to replicate a production Platform as a Service (PAAS).Read More…
  • Code
    Other
    Apache 2 Advanced Configuration on Unix-Like SystemsPreview
    In a previous tutorial, we took a look at some of the most basic, but important, Apache configuration directives - what they are for, and how to edit them to fit our needs. For a very basic website (perhaps one with just a few static HTML pages), those simple directives might be all you need to know. Chances are, however, you need a more complex website; today we will look at some advanced directives and configuration settings.Read More…