Table of Contents
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
my-brilliant-site.com is used as an example.
All configuration for the domain my-brilliant-site.com will be performed
inside the /srv/my-brilliant-site.com 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.
This is covered in more detail in Chapter 3, Website setup.
All the files required for a website for the domain
my-brilliant-site.com are kept in
/srv/my-brilliant-site.com/public/htdocs.
index.html or
index.php respectively.
/srv/www.my-brilliant-site.com/public/htdocs.
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 from the menu. The file should have Execute
set for the owner, group, and public permissions.
For example, for my-brilliant-site.com the scripts would live in
/srv/my-brilliant-site.com/public/cgi-bin.
Any executable files in that directory will now be treated as CGI
scripts for your domain. For example if you created the file
/srv/my-brilliant-site.com/public/cgi-bin/test.cgi This would be
referred to as: http://my-brilliant-site.com/cgi-bin/test.cgi
Each hosted website will have visitor statistics automatically
generated and accessible at http://my-brilliant-site.com/stats/. These
statistics will be updated once per day, and the raw access logs will
be made available as
/srv/my-brilliant-site.com/public/logs/.
These daily statistics can be disabled by creating the file
config/no-stats.
For example, for my-brilliant-site.com, creating the file
/srv/my-brilliant-site.com/config/no-stats will ensure that
statistics are no longer generated for that domain. If you wish to
remove any existing statistics, remove the directory
/srv/my-brilliant-site.com/public/htdocs/stats/.
It is also possible to customise the statistics generated by editing
the file public/htdocs/stats/webalizer.conf. This file is
documented at the Webalizer project
website.
You can view new websites before any DNS changes are made.
For example, if the virtual machine example.vm.bytemark.co.uk is hosting
www.my-brilliant-site.com, i.e. the directory
/srv/my-brilliant-site.com/public/htdocs has been
created, then the website can immediately be viewed at
http://my-brilliant-site.com.testing.example.vm.bytemark.co.uk.
There are some important things to note though: - There is no www part added to the domain name — it is just the directory name prepeneded to .testing.example.vm.bytemark.co.uk. - 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.
In this scenario, you have registered two domains for example my-domain.com and my-domain.co.uk, 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.
Once the my-domain.com directory structure has been completed, log on to your machine as admin over SSH.
Run the command ln -s /srv/my-domain.com /srv/my-domain.co.uk
A soft link of the entire my-domain.com directory is created, the top level directory being named my-domain.co.uk.
Browsing to my-domain.co.uk will show the same content that appears at my-domain.com.
Here is an example configuration layout for the domain
my-brilliant-site.com.
/srv/my-brilliant-site.com/public/htdocs
/srv/my-brilliant-site.com/public/cgi-bin
/srv/my-brilliant-site.com/public/htdocs/stats
/srv/my-brilliant-site.com/public/logs
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.combined.
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.combined -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.
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 11.3, “Generating an SSL certificate key and request”.
Log on to your machine as admin over SSH.
Change to the config/ directory of your domain. In our
example, we run cd /srv/my-brilliant-site.com/config.
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=/CN=www.my-brilliant-site.com/emailAddress=bob@my-brilliant-site.com 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.
Since we’ve run this on the machine, there is no need to upload anything. You can skip Section 11.5, “Uploading your new certificate, and optional bundle” and move on to Section 11.6, “Combining the certificate and key”.