Multiple Web Sites Single Apache Instance Using VirtualHost

Published on September 27, 2022 at 6:41 pm by LEW

Introduction

It is possible, and sometimes a necessity, to setup multiple distinct web sites using a single instance of the apache web server. This is done using the VirthualHost directive within the apache configuration file.

To explore the possibilities with this type of configuration, we will be using a Debain based LAMP (Linux Apache Mysql Php) server. Because of the way Debian sets up Apachde2 configuration (in multiple files) we will also need to discuss the IncludeOptional directive.

Apache Configuration File(s) in Debian

There are two ways to setup an apache2 configuration. A monolithic file including everything, or a number of files linked together by the Include/IncludeOptional directive. Debian uses the IncludeOptional method. The difference between include and IncludeOptional is how non existent files are handled. The include directive will throw an error when scanning an empty directory. The IncludeOptional directive will not.

On Debian the main configuration file, apache2.conf, is located in the /etc/apache2 directory. If we look inside this file, we will find the following line towards the bottom.

IncludeOptional sites-enabled/*.conf

When we list the contents of the /etc/apache2 directory we find folders for sites-enabled, and sites available. The actual site configurations we will be creating reside in sites-available. When we activate a configuration, a link to our file will be placed in sites-enabled. When apache2 reads its configuration file, it will scan the sites-enabled directory. Any links will cause the corresponding files in sites-available to be loaded.

Apache Virtual Web Hosts

In the past I have set up separate web applications in separate folders under the same domain. I would access them with domain/folder. Recently I have come across at least one web application (Ampache) that want to be in the main (or root) folder to work properly.

This kind of necessitates multiple web application running in their own subdomains on a single server. So instead of doing domain/folder, we end up doing sub-domain.domain.

I have not looked into advantages/disadvantages of doing either method, other than the second method makes for a more complex apache2 configuration. So unless a web application wants its own subdomain/root folder, I can’t recommend one method over the other.

Domain Names on Local Networks

Note, from here on it is assumed you have root or sudo access.

In this example, I will be setting up separate subdomain on my web server for mediawiki. And nextcloud on the same server. What you call them is up to you. There is a lot of talk going around about how to label local domains. But the fact of the matter is if you are not routing the domains to the Internet, or using a local DNS server, or not planing on any massive expansions to your network, it really does not matter that much. For my example I will be using the following two sub-domains (RFC-8375).

Nextcloud Server     ncs.home.arpa
Media Wiki Server    mws.home.arpa

Note, in this post I am not going through the installs of the various applications, only the setup of the virtual host environment.

Server Setup

Since I am doing this on a test server, I am simplifying some setup items. If this was a production server, I would be using a web application folders outside of the /var/www directory (typicality on production servers I would create separate home folders and user accounts).

Our first step is to create folders, in htis example under the /var/www directory. There should already be a html folder for the default web site (I would remove this and its default configuration on a production server). I also create application folders within the sub domain names, and a lower root folder. Generality this folder is named public_html, but does not have to be. You can then store/stage non public files (like the application zip file while you are working with it) in the main folder and the actual web application in the public_html folder.

mkdir /var/www/ncs.home.arpa/public_html
mkdir /var/www/mws.home.arpa/public_html

We will want to install theweb applications into these folders, via the installation instructions for the applications. Then change user and group to the web server (in a Debian install this is www-data by default). For permissions check your web application documentation, it should have information on what file and folder permissions should be used.

chown -R www-data:www-data var/www/ncs.home.arpa
chown -R www-data:www-data var/www/mws.home.arpa

Apache Setup

We now jump to the /etc/apache2/sites-available directory. We will not be setting up secure access in this post, so we make two copies the 000-default.conf, renaning the copies for  for each instance.

cp 000-default.conf ncs-home-arpa.conf
cp 000-default.conf mws-home-arpa.conf

Now edit each file with your favorite text editor. There are a lot of comments. Since they are available in the original file, feel free to delete them, and add your own as you edit. We will do the nextcloud virtual host. You can extrapolate for the media wiki one.

<VirtualHost *:80>
    
    ServerAdmin youremail@someemailserver.???
    ServerName ncs.home.arpa
    ServerAlias www.ncs.home.arpa
    DocumentRoot /var/www/ncs.home.arpa/public_html

    <Directory /var/www/ncs.home.arpa/public_html>
        Options Indexes FollowSymLinks
        AllowOverride All
        Require all granted
    </Directory>

    ErrorLog ${APACHE_LOG_DIR}/error.log
    CustomLog ${APACHE_LOG_DIR}/access.log combined

</VirtualHost>

Lets examine this file. It is in a format similar to XML, in that most braces must have closing braces.

The first command creates a virtual host that listens for anything on port 80.

Next we setup some basic server data; an email address (mostly for production servers), the server name, an alias with the “www.” added, and our root folder (note it goes down to the public_html folder).

Technically we do not need any of the directory entry. But it allows us to set some options (some of which we could set in an .htaccess file). If you do not want to use them, delete them. I may do a post on some of these options for virtual hosts if there is interest.

Lastly we have a couple of entries that control error logging. Technically you could delete these also. However if you have problems, these are good to have to record what went wrong in a log.

Activating Your Sites

The next step is to activate your sites and restart the web server. On Debian this is easy to do.

a2enstie  ncs.home.arpa
a2enstie  mws.home.arpa
systemctl restart apache2

At this point, assuming we did everything correctly, our sites should be available from the web server. However, there is an additional step that needs to be accomplished to actually access them.

Setting up Local Record Pointers

Depending on your network, you will need to update the hosts file on your client computer. Or if you have a local DNS server, either manually update it or wait for it to update on its own.

In Linux installs the host file is normally found at /etc/hosts. On Windows installs the hosts file is normally found at c:\windows\system32\drivers\etc\hosts.

In your hosts file you will add the IP address, and the virtual server name. Apache2 will y=use the name to distinguish between which virtual host to load form the same IP address. For example;

192.168.100.16      mws.home.arpa
192.168.100.16      ncs.home.arpa

If you are running a local DNS server, you will need to check its documentation.

Conclusion

That should do it. You should now be able to enter your local server subdomain name in your browser, and it will load up your local web application. If it is a small scale deployment, then configuring the hosts file will be the easiest to accomplish. However if there will be lots of clients or the LAN is large, setting up a local DNS severer will be the best option.

Regardless, setting up virtual servers in apache2 is not hard, and it can simplify configuration of quite a few web apps. I mentioned Ampache earlier, however setting up a virtual server also simplifies some of Next Clouds security issues also.

Add New Comment

Your email address will not be published. Required fields are marked *