Multiple hosts layout
During these articles I will be talking about different operating systems, different web servers and different, er, stuff.
To make things easier to understand and reference between articles and systems, I will use a 'standard' layout for hosting multiple sites (virtual hosts). Let me explain the layout I use.
Differences
As you know, there are several differences between distributions and not just in libraries, package management and so on.
The default directory locations for serving domains also differs. Some default to /var/www/ and some to /srv/www/. Some organisations recommend /srv/domain.com/.
Consistency
The way I will use is not the only way, nor is it special or the 'Slicehost' way.
It is, however, one way of organising your domains in one place and will work across different operating systems and web servers.
I will also mention that if you are using a shared hosting environment on your Slice then do stick with the OS defaults. My method places the domain directories in my home directory.
I am the only user of my Slice and this is, as far as I am aware, the case with the vast majority of Slice users, so I do not have to be concerned about other users logging in and accessing my home directory (apart from the usual security measures that is).
Layout
My domains are laid in their own directories in my /home/demo/public_html folder (demo is my main user name).
In each domain, I have a standard set of folders including logs, cgi, private, public, backup and so on but feel free to add/delete directories as you see fit.
One advantage of this layout is consistency between technologies. A standard Ruby on Rails application will have many directories with the main content being served from the 'public' directory.
My layout coincides with this so my plain html and dynamic PHP content are also served from the domain.com/public directory.
I can't incorporate every technology into one layout but I think this covers most eventualities. Specific articles (such as using Capistrano) will note the differences.
Folders
Let's take a look at the folders in use throughout these articles:
So in this example I have three domains - each in their own directory. I always class subdomains as separate from the 'main' domain. After all, they have different content.
Details
Let's look in detail at the domain1.com folder:
The layout is quite simple once you get used to all the connections:
public: where publicly served files, images, etc are placed.
private: used for files you do not want in the public domain such as PHP mysql connection files.
cgi-bin: umm, the cgi-bin
logs: place domain logs here - it keeps them separate and easily accessible.
backup: I place daily database backups here - makes for easier slice backups.
Change
Naturally, add/delete folders as you see fit. However, this is the layout that will be used throughout the articles when it comes to domain configurations.
Also, do use the OS default if you feel more comfortable doing so. Simply adjust the paths used in the demonstrations.
PickledOnion.
CentOS - Apache Virtual Hosts #1
Now we have Apache installed and running, we can configure it to serve multiple domains using Virtual Hosts.
Do note the layout used in these articles is explained here - feel free to use the directories of your choice.
Create the Directory Layout
In this example we'll be creating two domains, domain1.com and domain2.com
As the default permissions only allow us, the 'demo' user, to browse our home folder, let's start off by giving Apache access to this folder as well:
chmod 755 /home/demo
OK, now we need to create the directory structure for our sites.
In your home directory create a 'public_html' folder:
cd ~
mkdir public_html
Now, for each domain we want to host, create a folder with a standard set of sub-folders:
mkdir -p public_html/domain1.com/{public,private,log,cgi-bin,backup}
and
mkdir -p public_html/domain2.com/{public,private,log,cgi-bin,backup}
That will create the folders public, private, log, cgi-bin and backup for each of our domains (domain1.com and domain2.com).
index.html
The content of the public folder is, entirely, up to you but for this example I am going to use a very simple HTML file so we can check that the virtual hosts work correctly:
For each domain let's create the index.html file:
nano public_html/domain1.com/public/index.html
add the following to the file:
domain1.com
domain1.com
Repeat the process so you have a similar file for domain2.com (simply replace all instances of 'domain1.com' with 'domain2.com).
Now that we have a basic structure for our two domains we can look at defining the two virtual hosts.
NameVirtualHosts
With the virtual hosts, one thing to note that often catches people off guard is the NameVirtualHost setting.
For each port that Apache listens to, we need to define a NameVirtualHost. The issue that people sometimes overlook lies in the fact that you can only define it once per port.
Be careful that you do not add the same NameVirtualHost twice as adding another one will cause warnings and errors.
Let's go ahead and uncomment the generic NameVirtualHost in the Apache configuration.
Navigate to the /etc/httpd/conf directory and open the main Apache configuration file (httpd.conf):
sudo nano httpd.conf
Towards the bottom of this file you will want to uncomment out the generic NameVirtualHost as follows:
# Use name-based virtual hosting.
#
NameVirtualHost *:80
#
# NOTE: NameVirtualHost cannot be used without a port specifier
# (e.g. :80) if mod_ssl is being used, due to the nature of the
# SSL protocol.
Now we can restart Apache to initiate the changes:
sudo /etc/init.d/httpd restart
The following warning will be displayed as we still need to add our VirtualHosts
Stopping httpd: [ OK ]
Starting httpd: [Thu Dec 11 02:06:13 2008] [warn] NameVirtualHost *:80 has no VirtualHosts
[ OK ]
Please keep in mind that this is only a warning and will not appear once we complete the following section.
Let's move on.
Custom Virtual Hosts
We've setup the basics and now we're ready to add our own virtual hosts so that we can start to serve our domains.
Let's create the vhost for domain1:
sudo nano /etc/httpd/conf/httpd.conf
At the bottom of the httpd.conf file, we need to add the following:
# Place any notes or comments you have here
# It will make any customization easier to understand in the weeks to come
# domain: domain1.com
# public: /home/demo/public_html/domain1.com/
# Admin email, Server Name (domain name) and any aliases
ServerAdmin webmaster@domain1.com
ServerName domain1.com
ServerAlias www.domain1.com
# Index file and Document Root (where the public files are located)
DirectoryIndex index.html
DocumentRoot /home/demo/public_html/domain1.com/public
# Custom log file locations
LogLevel warn
ErrorLog /home/demo/public_html/domain1.com/log/error.log
CustomLog /home/demo/public_html/domain1.com/log/access.log combined
OK good, now we need to reload Apache:
sudo /etc/init.d/httpd reload
Navigate
Now navigate to your site:
http://domain1.com
You should now see the contents of public/index.html being shown:
ServerAlias
Note that in the vhost file, we set a ServerAlias. Providing you have the DNS set up correctly you can also use that address:
http://www.domain1.com
Repeat as necessary
To create and enable domain2.com simply go through the process again:
sudo nano /etc/httpd/conf/httpd.conf
...
# Enter the details for domain2.com as per the example shown above
Then reload Apache:
sudo /etc/init.d/httpd reload
Finally, navigate to your second domain:
http://domain2.com
or
http://www.domain2.com
All being well, you will see the 'domain2.com' index file.
Log Files
As defined in your vhost in the Apache configuration, each domain has its own log files, lets take a quick look:
ls /home/demo/public_html/domain1.com/log/
The output is exactly as expected:
access.log error.log
This makes for much easier analysis as each set of logs is self contained.
Default Vhost
Remember that although we created a vhost for domain1.com and domain2.com, if someone enters the IP address of the Slice they are served the contents of the domain1.com vhosts.
Why are they served from that vhost?
Apache searches the enabled vhosts from the top down. Therefore, once it finds a matching vhost for the IP address entered, the contents of that domain are displayed. As we setup domain1.com initially in this example, the contents for this domain will be shown if you enter your slice's IP address in a browser.
This is something to keep in mind when planning your websites. Do you want a particular domain to be the default? Do you want the IP address to have completely different content?
If you want the IP address to have separate content than your domains, you will need to create an additional vhost and use the IP of your slice as the ServerName.
Summary
We've gone into some detail here but, overall, setting up a virtual host is relatively easy. Of course, there are many settings and configurations to take into account but you should have your site up and running in no time.
The next virtual host article will look in more detail at some of the settings that are available and what they mean.
Mark
CentOS - Apache Virtual Hosts #2
Following on from the first CentOS - Apache Virtual Hosts article, we can now look in detail at some of the settings available to us in the Virtual Hosts file.
This will enable us to have complete control of the domain we want to serve.
Some of the settings discussed were introduced in the previous article but some are new.
Take the time to read through the explanations and you will soon have an understanding of how powerful vhosts actually are.
ServerAdmin
ServerAdmin webmaster@domain.com
Sets the email address for the server administrator - this will be used if you have setup the server to contact you on errors. It is also shown in the ServerSignature (if set to 'Email' - see below)
Domain Name
ServerName and ServerAlias
ServerName domain.com
ServerAlias www.domain.com
Sets the domain name for the virtual host. You can have as many aliases as required. For example, you can have domain.com and domain.net point to the same content.
Note this is not a rewrite rule (we'll look at those later) but the domains defined here will serve the same content (assuming you have set the DNS to point to your Slice IP).
Index Files
DirectoryIndex
DirectoryIndex index.html
Defines the index file (the 'home' page that is shown on entering the domain address). Useful if you have want the user to be directed to an alternate page or to a non-standard home page.
Do note this is not a good way of redirecting users as they may go directly to a non specified page such as domain.com/index.php whilst the DirectoryIndex will only work for those entering domain.com.
Documents
DocumentRoot
DocumentRoot /home/demo/public_html/domain.com/public
The location of the domain's public files. Use an absolute path name.
Log Files
ErrorLog and CustomLog
LogLevel warn
ErrorLog /home/demo/public_html/domain.com/log/error.log
CustomLog /home/demo/public_html/domain.com/log/access.log combined
Set the Log levels and the location for the Virtual Hosts log files. Very useful for easy analysis of the domain statistics.
Error Documents
ErrorDocument
ErrorDocument 404 /errors/404.html
ErrorDocument 403 /errors/403.html
Used for all the standard error messages.
In these examples I have an 'errors' folder in my public directory. I created each error document and place them in the 'errors' folder. The paths shown are relative to the DocumentRoot folder defined above.
If not defined, Apache will generated its own error pages. Custom error pages are more user friendly and can be customized as much, or as little, as you want.
Apache Footers
ServerSignature
ServerSignature On
Sets whether the server details are displayed in any server generated error pages or index lists. Options are On, Off and Email.
Note the level of detail in the signature is configured via ServerTokens which cannot be set in the Virtual Hosts file - only in the main httpd.conf. See the Apache configuration #2 article for more details.
If set to Email, the ServerAdmin email will be displayed.
cgi-bin
ScriptAlias
ScriptAlias /cgi-bin/ /home/demo/public_html/domain.com/cgi-bin/
Options +ExecCGI
Enables the cgi-bin location as defined by the custom virtual hosts layout. You can, of course, leave the cgi-bin in the DocumentRoot location if you so wish.
Directory
Options FollowSymLinks
Set the Options for the specified directory - the example shown allows the Option FollowSymLinks to be enable for the public directory of domain.com
Listed below are further Options that can be set:
Directory Browsing
Options
Options -Indexes
To turn off directory browsing use '-Indexes' or 'None'. To turn them on, use '+Indexes'.
SSI
Options
Options -Includes
This Option disables Server Side Inlcudes.
Symlinks
Options
Options -FollowSymLinks
Enable or disable the option to follow symlinks. Be careful with this option as it can lead to security risks (inadvertently linking to configuration folders).
Dejay Clayton made a good suggestion in using SymLinksIfOwnerMatch instead of FollowSymLinks.
The SymLinksIfOwnerMatch allows symbolic links to be followed only if the owner of the link is identical to the owner of the target file or directory. Thus preventing many of the security risks than a simple FollowSymlinks can create.
.htaccess
AllowOverride
AllowOverride None
Setting AllowOverride to none disables .htaccess support. Set to All to allow them.
You can also specify which .htaccess features to enable such as:
AllowOverride AuthConfig Indexes
The Apache AllowOverride docs has more information on the different features.
Remember to specifically protect your .htaccess file. This can be done in two ways:
Firstly rename it to something obscure and, secondly, deny access to the file from external sources:
AccessFileName .myobscurefilename
Order allow,deny
Deny from all
Satisfy All
No Options
Options
Options None
This will turn off all the available options.
Hierarchy
Remember that the Options directives can be set per directory like this:
AllowOverride None
Options None
AllowOverride All
This will turn of all Options and disable .htaccess support for all directories.
However, the second Directory setting will override the first and allow .htaccess support for the domain.com/public directory.
Summary
The Virtual Hosts directive is at once an easy tool to use and a very powerful one. My advice is to enter one setting and test it. Then enter the next setting and so on.
Once familiar you will see you have fine control over all of your web folders and files.
REFERENCES
http://articles.slicehost.com/2007/9/13/multiple-hosts-layout
http://articles.slicehost.com/2008/12/12/centos-apache-virtual-hosts-1
http://articles.slicehost.com/2008/12/12/centos-apache-virtual-hosts-2