Apache Web Server

The Apache Web Server is one of the most robust, configurable and widely used web servers across the Internet. Not only does it function great as a basic web server, but it can use a wide variety of scripting languages and modules. It also has the ability to be configured to host multiple sites from the same machine and is the basis of quite a few web applications that you can deploy for your network. Nowadays, deploying a web server within your environment is considered a requirement.

SLES Configuration Layout

Before I get into configuring the Apache Server through Yast, I need to cover how SLES stores the configuration files for Apache. This may not seem important, but this information will allow you to fully understand all aspects of configuring Apache through Yast.

Historically, Apache used a single file to store it's configuration data for the service. This file, "httpd.conf", is still in use today, although most GNU/Linux Distributions now spread the Apache configuration across multiple files for clarity and ease of administration. With Suse Linux Enterprise, these files are located in the "/etc/apache2" directory.

httpd.conf - This file is still the main configuration file for the Apache Web server and any setting you want to apply to everything Apache "Serves" you would set here. However, with modern distributions (including SLES), the main purpose of this file is to simply "include" the content of other files within the httpd.conf file. The result is that the computer thinks all the configuration data is present in the httpd.conf file, but in reality the configuration is spread across multiple files.

Below are the files that you will likely deal with when configuring the Apache Web Server. These files are located within the "/etc/apache2" directory on Suse Linux Enterprise Servers.

uid.conf - This file allows you to specify which user and group the Apache Server is ran under. Some web applications may require you to modify this.

default-server.conf - This file configures the default server that replies to "non-virtual-host" requests. This means that if you do not configure Virtual Hosts, this is the main configuration file for your server. A word of caution: it is relatively easy to over-write this file through yast, with the result of losing the basic configuration of your web-sites. I will cover this in-depth later.

vhosts.d/yast2_vhosts.conf - This file configures the Virtual Hosts for your server. Utilizing virtual hosts you can serve multiple web sites from a single server.

conf.d/ - This directory contains configuration files for various packages that you may have installed. For instance, the configuration to allow you to view the Apache Manual through your server can be found here. Other software packages such as PHP and Perl place their configuration files here.

Stepping Through the Yast Apache Wizard

When you first launch Yast's HTTP Server module you are presented with a Wizard to help you in the initial configuration of the Apache Server. Most of this wizard is pretty straight forward. The first step allows you to select which network interface(s) Apache should "listen" for requests. You can also configure the firewall to allow HTTP traffic through the firewall.

Specifying the Adapters that Apache will Listen On

Enabling Various Scripting Languages

Specifying the Addresses that Apache Listens On and Enabling Various Scripting Languages

The Second step is a little more complex. Here you can enable various scripting languages that the Apache Web Server supports. It is wise to ensure that you enable any scripting language that you may utilize in the future, as it is quite a bit more difficult to enable them later after the wizard is complete (also ensure that you enable any languages that may be required for any web application you are planning to implement).

Apache's Default Host Parameters

Enabling Apache to Start Automatically

Apache's Default Host Parameters and Setting Apache to Start Automatically

The third step in the wizard allows you to adjust the default host configuration. You can easily re-adjust the default host at a later time through the Yast "HTTP Server" module.

The fourth step allows you to define Virtual Hosts that your server will provide. I will cover configuring Virtual Hosts later and they can easily be configured after the wizard has completed. The final step in the wizard simply allows you to specify if you want the Apache Server to start when the computer boots, or if you want to manually enable the server.

Configuring Apache

Once you complete the configuration wizard you now have a basic web server that you can host most basic web sites with. If you need to fine tune your server or add more functionality to it, you can utilize the Yast HTTP Server module to do this.

When you launch the Yast Module you are presented with an interface with various tabs:

  • Listen Ports and Addresses: This tab allows you to change the listen addresses or ports that the Apache Server will listen on. You can also access the log files from this tab and even restart the Apache Server (from within the log file viewer).
  • Server Modules: This tab allows you to enable or disable various Apache Modules. Apache Modules allow you to add additional functionality to the server if needed.
  • Main Host: This tab allows you to configure the "Main Host" of the Apache Server. If you are not utilizing virtual hosts this is how you adjust settings for your site.
  • Hosts: This tab allows you to specify virtual hosts that the server will host. I will cover this in detail in a later section.

Enabling Various Server Modules

Main Host Configuration Screen

Enabling Various Server Modules and Editing the Main Host

Useful Directory Options

To customize your server and to configure it to function how you want it to, you can add various options to either the directories specified within the "Main Host" or directories listed within virtual hosts (which I will cover later). To add these options, simply highlight the "Directory" statement and select Edit. You then simply need to add these to the "Options" option (comma separated). Some useful directory options are listed below:

  • ExecCGI: Allows execution of CGI scripts, useful for some Web Developers.
  • FollowSymLinks: Allows the server to follow symbolic links outside of the stated directory. Useful if you want to host files located within a different directory on the server.
  • Indexes: This tells the server to generate a directory listing of the current directory if no index.html file is present. If this option is not present, the server will return an "Access forbidden" error if a user access a directory directly. This option allows you to easily host various files with your Apache Server.

Creating Virtual Hosts

To alleviate the need to have a web server for every site that you host, the Apache developers implemented a way for a single web server to host multiple web sites through what are called "Virtual Hosts". Virtual Hosts work by figuring out how a user came to the site and providing the correct web site for that session.

There are basically 2 ways that you can deploy Virtual Hosts. The first is simply by having each host use a different I.P. Address. In this instance you can have a web server with 2 I.P. addresses with site located at 10.0.0.1 and another web site at 10.0.0.2. When a user accesses each address, Apache looks at which address the user is accessing the site through and serves the correct page for that address.

The second, more commonly used way to use Virtual Hosts is to have Apache differentiate the web sites by the actual domain name that is used to access the site. For instance, you can configure apache to serve the addresses www.somewhere.com, mail.somewhere.com and www.somewhere-else.com from the same server. When a user goes to these addresses, Apache will look at the HTTP traffic and figure out which site the user wishes to visit and provide the correct page for that user.

With Suse Linux Enterprise Server HTTP Server Yast Module, it seems apparent that creating Virtual Hosts is somewhat straightforward and simple. Unfortunately this is not the case.

There are a few problems with Yast's implementation of virtual hosts. First, you cannot create a virtual host based on a secondary I.P. Address of a network card. This makes implementing I.P. Virtual Hosts nearly impossible as you would require a physical network card for every virtual host you create.

The second problem comes in when you try to create domain name virtual hosts. The Yast module tries to create a new name virtual host for every hostname you want to create a virtual host for. This is not feasible as I will explain later. For now, let me step you through creating a named base virtual host.

Creating a New Virtual Host

Adjusting Settings for the Virtual Host

Creating a New Virtual Host and Adjusting it's Settings

The first step to create a virtual host is to go to the "Hosts" tab within the Yast HTTP Server module and click "Add". This will bring up a wizard that will allow you to fine tune the virtual host.

The wizard begins with the "New Host Information" screen where you specify the server name, the contents root, the administrator email account and the server resolution.

Server Name - Here you enter the fully qualified DNS address that you will use for the virtual host. This is the exact name that must be entered into a web browser to get to this host.

Server Contents Root - Here is where you specify which directory the virtual hosts files are stored in. This is normally "/srv/www/vhostname", but can be located anywhere on the server.

Administrator E-Mail - This is the email address that is shown in any of the error pages that is served to the user.

Server Resolution - This is where Yast kind of messes up the virtual host configuration. For now, just realize that within Yast, you must change the VirtualHost ID for every virtual host you configure. If in doubt, change the ID to *:80, where 80 can be changed to any random number as I will show you how to fix this later.

The next step in the wizard is the "Virtual Host Details" page. Here you specify advanced options that you may or may not want to enable such as CGI and SSL support for the virtual host. You can also specify which file to be used as the directory index file (normally index.html) and whether or not you wish to enable users to access their "public_html" folder through "http://hostname/~username/".

If you have already setup the DNS server on your system you will also have the ability to quickly create a new zone for your DNS server through this page.

Once you are done with the "Virtual Host Wizard", you are brought back to the Hosts tab of the Yast HTTP Server module. This tab should now list the virtual hosts that you have created. Through this tab you can easily adjust any virtual host you have created by highlighting the host and clicking on "Edit". This gives you the ability to fine tune the virtual host similar to how you can fine tune the main host.

Listing All of the Virtual Hosts

Editing a Virtual Host Configuration

Listing all of the Virtual Hosts and Editing a Virtual Host Configuration

Once you are done creating the virtual hosts and exit out of the Yast HTTP Server module", you will probably find that only 1 virtual host comes up for all of your configured virtual hosts.

For instance if you created virtual hosts named site1, site2 and site3, what is probably the case is that site1 or site2 comes up when you enter any of the above sites. This happens because of the way the Yast HTTP Server module handles assigning virtual host IDs. This is a known bug and have been in contact with the developers about this. Thankfully there is an easy fix.

To fix this, a simple understanding of implementing Apache Virtual Hosts is needed. The first thing to understand is that all of the virtual hosts you have just created are listed within the "/etc/apache2/vhosts.d/yast2_vhosts.conf" file. Yast, as of this writing, does not create this file properly. A properly formatted file with 2 virtual hosts is shown below.

<VirtualHost *:80>
 DocumentRoot /srv/www/testing/
 ServerName testing.private.lan
 ServerAdmin webadmin@private.lan
 <Directory /srv/www/testing/>
  AllowOverride None
  Order allow,deny
  Allow from all
 </Directory>
</VirtualHost>
<VirtualHost *:80>
 DocumentRoot /srv/www/test2/
 ServerName test2.private.lan
 ServerAdmin webadmin@private.lan
 <Directory /srv/www/test2/>
  AllowOverride None
  Order allow,deny
  Allow from all
 </Directory>
</VirtualHost>
	

As you may have gathered already, a normal virtual host setup within Apache utilizes the same <VirtualHost *> directive. The * specifies an IP address to listen to requests from and is usually just * or *:80 (since Apache normally listens to port 80). Unfortunately Yast tries to force the Administrator to create a new virtual host ID for every virtual host, thus rendering the virtual hosts useless.

Once you straighten out the "/etc/apache2/vhosts.d/yast2_vhosts.conf" file you must then create a directive within the "Main Host" configuration that will tell Apache to look for these "Virtual Hosts" that you have created. That directive is:

	NameVirtualHost *:80

Adjusting the Main Host to fix Virtual Hosts

Adjusting the Main Host to fix Virtual Hosts

Once these steps are done, your virtual hosts should be working properly. One final note, if you are setting up different virtual hosts for entirely different domain names, a very important directive is the ServerAlias directive. For instance:

	ServerAlias www.private.lan *.private.lan

Also note that the first virtual host listed in the "/etc/apache2/vhost.d/yast2_vhosts.conf" file is going to be the site that is served by default if no other virtual hosts match the incoming HTTP headers. For instance, when you access the server by IP Address.

Apache Authentication Techniques

In some Apache deployments, you may wish to enable authentication for some of your sites. This is usually done to either remove anonymous access to certain sites or to ensure that a Username gets passed to a web application so it will function properly. In either case, here are some examples of how to enable various Authentication Techniques with Suse Linux Enterprise Server.

Authentication Using the .htaccess file

Probably the easiest way to enable authentication is by the use of the ".htaccess" file. Unfortunately this is the most wasteful way (in server resources) to enable authentication because the server must look for this file within every directory for every file that is being served. Added to this performance hit is the fact that Apache must also look at every parent directory for this file. This can become a huge performance hit if the site is categorized into various directories.

Nevertheless, if you do not want to adjust the main configuration files to configure authentication, this is an easy way for you, or your users, to enable authentication.

The first step to configure ".htaccess" authorization is to ensure that you enable it for the sites that you want to. To do this you must allow "AuthConfig" authentication to your site by adding the following directive to the site's configuration or <Directory > section.

	AllowOverride AuthConfig

Once that is done you can now create the actual .htaccess file to protect the site or a directory within the site. This file should contain something similar to:

	AuthName "Something Meaningful"
	Require valid-user
	AuthUserFile /srv/www/passwds/secure1.pwd
	AuthType basic

This configuration will check the password file at /srv/www/passwds/secure1.pwd for the username and password entered by the user to see if they can have access to the site. To create this password file you must enter the following command

	htpasswd2 -c /srv/www/passwds/secure1.pwd username

It will then create the secure1.pwd file and ask for a password for the username that you entered. Once this file is created you will no longer need the "-c" option when running the command to add additional usernames to the password file.

Once all of these steps are taken, when a user tries to access any file within the directory that you put the .htaccess file into, they will be prompted with a "Authentication Required" box to enter their username and password to access the file/directory.

Authentication Within the <Directory > Specification

To avoid using ".htaccess" files, you can also configure authentication directly within the apache configuration files. The most popular way to do this is to configure authentication with a <Directory > specification.

This example I simply add another directory specification to the site's configuration block. For example you can add this directory spec below the main directory spec.

	<Directory /srv/www/site1/secure/>
		AllowOverride AuthConfig
		Order deny,allow
		Require valid-user
		AuthType basic
		AuthUserFile /srv/www/passwds/secure.pwd
		AuthName "Something Meaningful"
	</Directory>
	

You would then create the secure.pwd file and add any users to it with the htpasswd2 command as shown in the previous section.

Authentication Using the LDAP Server

Now that you know how to setup basic authentication for your web server, I will now cover how you can utilize an LDAP Server for Authentication to avoid having to manually create a password file for your server. This will allow you to utilize an existing "database" of username/passwords to utilize to grant access to your site(s).

The first step that must be done to authenticate against an LDAP directory is to enable the "ldap" and "authnz_ldap" apache modules. You can do this by finding them within the "Server Modules" tab of the Yast HTTP Server module and enabling it. Alternatively you can add the following lines to the "/etc/apache2/sysconfig.d/loadmodule.conf" file:

	LoadModule ldap_module	/usr/lib/apache2-prefork/mod_ldap.so
	LoadModule authnz_ldap_module	/usr/lib/apache2-prefork/mod_authnz_ldap.so
	

Once that is done, you can start authenticating against your LDAP directory through either the .htaccess file or directly within a Directory statement. For example, a Directory statement that will allow access to any user that is listed within the LDAP tree would look something like this:

	<Directory /srv/www/site1/secure/>
		AllowOverride AuthConfig
		Order deny,allow
		Require valid-user
		AuthType basic
		AuthName "Something Meaningful"
		AuthBasicProvider ldap
		AuthzLDAPAuthoritative off
		AuthLDAPUrl ldap://127.0.0.1/ou=people,dc=private,dc=lan?uid
	</Directory>
	

As you can see, this is very similar to all the above examples, with the main exception being the AuthLDAPUrl statement (as well as the other LDAP statements). Adjusting both the AuthLDAPUrl and the Require statements you can adjust what apache will look for in your LDAP database to allow access. For further information on LDAP authentication with Apache you should take a look at the mod_auth_ldap information within the Apache Documentation.

Using MySQL with Apache

One of the most popular ways to create applications using Apache is to utilize what is called "LAMP". This acronym stands for Linux, Apache, MySQL and PHP and represents the integration of all of these entities to form the basis of a web platform.

Installing the Required Software

The basic software components that are needed to integrate MySQL into your existing Apache/PHP configuration can be installed by selecting the "Web and LAMP Server" pattern within the Yast Software Management Module, with the exception of "php5-mysql" package. To install this package, simply run "yast -i php5-mysql" as root.

There are also quite a few additional packages available within the Suse Linux Enterprise installation media that may be beneficial to your site (most of these are in the form of PHP Plugins) and different web applications may require additional software to be installed.

Configuring MySQL & Creating a Database

Once the software is installed, ensure that MySQL is running (and will start upon boot-up) and that you change the "root" password. To do this run the following:

rcmysql start
chkconfig mysql on
mysqladmin -u root password your_p@ssword
	

Now to create a database within MySQL, run the following:

mysql -u root -p

This will prompt you for your password, then log you into the MySQL monitor. Create a database with (the second and third lines should be entered as one command:

create database dbname;
grant create, select, insert, update, delete, alter, lock tables on 
	dbname.* to 'mysqluser'@'localhost' identified by 'users_p@ssword';
flush privileges;
\q

You can now install any web application onto your server utilizing the database you just created with the above steps.

Backing up and Restoring a MySQL Database

Once you have your MySQL Database initialized and all of the data your application requires added to it, you now need to look at backing up the database. Fortunately, MySQL includes a very easy to use command line utility, mysqldump, that will pretty much automatically backup the database to a file. To use it, simply run something similar to:

mysqldump -u username --password=p@ssword dbname > /srv/backup/backup.sql

It is highly recommended that you include this command within a daily cron job so that your databases are backed up regularly.

If you ever need to restore your database, make sure you recreate the database using the steps from the previous section, then simply utilize something similar to:

mysql -u username --password=p@ssword dbname < /srv/backup/backup.sql

Google Ad

© 2017 Mike Petersen - All Rights Reserved