Chapter 15. Website Configuration

Table of Contents

15.1. Getting started
15.2. CGI scripts
15.3. Statistics
15.4. Testing new websites
15.5. Displaying the same content under two domains
15.6. Redirecting to the preferred website domain
15.7. Custom Apache configuration
15.8. SSL Configuration
15.9. Logging
15.10. Configuration layout

This is a detailed break down of all the configuration options and files available when configuring website hosting for a domain.

Throughout this chapter, as with the rest of this documentation, the domain is used as an example.

All configuration for the domain will be performed inside the /srv/ directory.

The Bytemark Symbiosis project uses the popular Apache2 software for serving your websites, and this comes complete with PHP5 along with many of the most popular PHP extensions.

15.1. Getting started

This is covered in more detail in Chapter 4, Website setup.

All the files required for a website for the domain are kept in /srv/

  • If this directory does not exist, a 404 Not Found error will be returned.
  • If this directory exists, but is empty, then a default page is shown.
  • The index file can be written in HTML or PHP, and should be called index.html or index.php respectively.
  • Once this directory is present, both and will show the same content, i.e. there is no need to name the site with a www prefix.
  • If different content is required for then that should be put in /srv/

15.2. CGI scripts

If you wish to use CGI scripts for your domain, then simply copy them to a directory named cgi-bin/ beneath the public/ directory. They must all be marked as executable. This means setting the permissions to 755. In FileZilla, right click the file and select File Permissions… from the menu. The file should have Execute set for the owner, group, and public permissions.

For example, for the scripts would live in /srv/

Any executable files in that directory will now be treated as CGI scripts for your domain. For example if you created the file /srv/ This would be referred to as:

15.3. Statistics

Each hosted website will have visitor statistics automatically generated and accessible at These statistics will be updated once per day, and the raw access logs will be made available as /srv/

These daily statistics can be disabled by creating the file config/no-stats.

For example, for, creating the file /srv/ will ensure that statistics are no longer generated for that domain. If you wish to remove any existing statistics, remove the directory /srv/

It is also possible to customise the statistics generated by editing the file config/webalizer.conf. This file is documented at the Webalizer project website.

If there are many sites on the same machine, then it is possible to customise all the sites' Webalizer configurations by editing the template that is available at /etc/symbiosis/apache.d/webalizer.conf.erb. Configuration files will be updated when the statistics are next generated, but only for sites whose configurations either do not exist, or have not been edited by hand.

15.4. Testing new websites

You can view new websites before any DNS changes are made.

For example, if the virtual machine is hosting, i.e. the directory /srv/ has been created, then the website can immediately be viewed at

There are some important things to note though: - There is no www part added to the domain name — it is just the directory name prepended to - This testing alias isn’t guaranteed to work in all cases, for complex site setups it might not work entirely as expected. - The testing alias only allows the testing of websites. Therefore FTP logins, email delivery, or checking is explicitly unsupported.

15.5. Displaying the same content under two domains

In this scenario, you have registered two domains for example and, but you want the same content to be served at both addresses. There is no need to create two separate directory structures, you can just set up one directory structure and then create a soft link (aka symbolic link or symlink) to the second.

  1. Once the directory structure has been completed, log on to your machine as admin over SSH.

  2. Run the command ln -s /srv/ /srv/

  3. A soft link of the entire directory is created, the top level directory being named

Browsing to will show the same content that appears at

15.6. Redirecting to the preferred website domain

If a document tree were created in /srv/ then that site would be available under two hostnames:

There are people who prefer to use only a single name, and to automatically redirect visitors using the wrong name to using the preferred name. This can easily be achieved by using Apache’s mod_rewrite facility.

If you prefer all visitors see the www-based site you could create the file /srv/ with the following contents:

RewriteEngine on
RewriteCond %{HTTP_HOST} !^www.*$ [NC]
RewriteRule ^(.*)$ http://www.%{HTTP_HOST}/$1 [R=301,L]

This examines each incoming request, and if the hostname doesn’t begin with "www." then it is prepended to the request and a redirect is issued.

15.7. Custom Apache configuration

It is perfectly possible to alter the way Symbiosis configures Apache, either for an individual domain, or for all domains hosted on the server.

Symbiosis hosts sites on a server in one of two ways, based on the IP address that site has configured. If it uses one of the server’s primary IP addresses, then it is assumed that the site is hosted using the "mass-hosting" configuration. If the site has a secondary IP assigned then Symbiosis generates an individual snippet for that site, and Apache is configured to use that snippet when dealing with HTTP requests for that domain. Both configuration techniques are configured using a template, which allows the server’s administrator to fiddle with, and tweak the configuration.

In /etc/symbiosis/apache.d/ there are a number of templates that are used to generate configuration snippets for both the mass-hosting, as well as individual sites.

15.8. SSL Configuration

Secure Sockets Layer is a technique used to encrypt communication between two machines on a network. It uses a system of public and private keys to encrypt and decrypt the connection — the public key is used by the sender to encrypt, and the private key is used by the receiver to decrypt. This protocol is used not only for transactions involving a web server and browser, but also by the email servers and their clients.

In addition to the public key encryption, there is a system of trust that validates that the certificate presented actually belongs to the server that is presenting it. This system involved having the certificate signed by a trusted authority. Web browsers and email clients tend to come with a selection of certificates from trusted authorities pre-installed, which allows them to verify a previously unseen certificate as valid.

Having a certificate signed by a trusted authority involves having varying degrees of identity checks made, and paying a fee. Vendors that are able to sell you a certificate include Rapid SSL and Comodo.

As standard, a Symbiosis machine will come with an SSL certificate installed. However it will be a “self-signed” certificate, i.e. one that has not been signed by a trusted authority. This means that whenever a program connects to your machine using SSL a warning will be shown saying something along the lines of unable to verify certificate because the issuer is unknown. This does not affect the security of the connection,

Verifying a self-signed certificate as trusted can be done using the certificate’s fingerprint, on the machine using openssl. The default certificate on a Symbiosis machine is kept in /etc/ssl/ssl.crt. First, the fingerprint of the certificate needs to be determined. To do this run the following, as root:

openssl x509 -noout -in /etc/ssl/ssl.crt -fingerprint

That should output something similar to

SHA1 Fingerprint=B8:C7:1B:3F:EC:94:F2:9F:77:BC:09:60:CD:E3:EF:E0:04:F4:23:6A

Now that we have the fingerprint, we can compare it against that presented in a browser or email client. The fingerprint of a certificate should be shown in the application’s certificate viewer, allowing a comparison to be made between the fingerprint on the machine, and the one being presented in the application.

The nature of SSL is such that only one certificate can be used per service per IP address. This typically means that a new IP address is needed for a website that needs a new SSL certificate.

Generating a self-signed certificate

If you do not wish to purchase a new certificate, you can use generate your own certificate as follows. This assumes you’ve completed the instructions for generating a key and certificate request in Section 13.2, “Generating an SSL key and certificate request”.

  1. Log on to your machine as admin over SSH.

  2. Change to the config/ directory of your domain. In our example, we run cd /srv/

  3. Now run openssl x509 -days 365 -req -in ssl.csr -signkey ssl.key -out ssl.crt. This will produce output similar to the following. Note that the information entered in the certificate request is shown.

    Signature ok
    subject=/C=GB/ST=North Yorkshire/L=York/O=Bytemark Hosting/OU=/
    Getting Private key

    This has now generated the certificate, and saved it in ssl.crt. This certificate is valid for a year from the date generated.

15.9. Logging

Requests for sites are logged to one of two places. If a request is received for a site that exists on the machine, then that request is logged to public/logs/access.log. If that request generates an error, then it is logged to public/logs/error.log. These logs are updated as requests are received.

If a request is received for a domain that is not present on the box, then it is logged to zz-mass-hosting.access.log if it received on the primary IP of the machine. If the request comes on any other IP then it is logged to other_vhosts_access.log. Both of these last two files are located in /var/log/apache2.

15.10. Configuration layout

Here is an example configuration layout for the domain, all of which is contained under /srv/

If this file exists, no statistics will be generated for this domain. Existing statistics in /public/htdocs/stats/ will not be removed automatically.
If this file exists, traffic will be redirected to the SSL version of the website.
This is the Webalizer configuration file for this domain.
This is the directory which may be used to hold CGI scripts for your domain.
This is the directory from which content is served for the URLs and If this directory does not exist visitors will be shown an error page.
This directory will be automatically created, if it isn’t already present, and updated with statistics referring to the number of visitors to your website.
This file contains the Apache webserver access log for the domain. It will be archived daily, and removed after 30 days.
This file contains the Apache webserver access log for the domain when accessed over SSL.
This file contains the Apache webserver error log for the domain, if the domain has been configured to run under its own IP address. It will be archived daily, and removed after 30 days. If the site does not have its own IP address, then errors are logged to /var/log/apache2/zz-mass-hosting.error.log.
This file contains the Apache webserver error log for the domain when accessed over SSL, if the domain has been configured with its own IP address.