No. All typical day-to-day jobs, such as adding new web sites, or email addresses, or uploading content, can be done using SFTP, i.e. FTP over SSH, by creating files and directories. FileZilla is the recommended program for this.

This should not be viewed as a disadvantage; any confident computer user should be able to manage a Symbiosis system. Effort has been put into making the layout of the various systems as obvious as possible, and making systems just work.

Symbiosis has been written by an experienced team of developers and system administrators with the goal of having an easy-to-use hosting system that met their exacting standards.

Unlike other control panel systems, one of the aims of the Symbiosis system is to keep the "magic" as transparent as possible. As far as possible standard tools and techniques have been used to configure the various services on a Symbiosis system. This allows users to tailor these configurations as they need, as well as working through standard distribution updates and upgrades.

Yes! Symbiosis is both Free Software and Open Source software. All the parts Bytemark have written have been released under the GNU General Public Licence, version 2 or later, or the Apache licence, version 2.0. All the source code is available for scrutiny on the Symbiosis project site. There is also a issue tracker to report any problems encountered, or to request improvements.

This documentation is released under the GNU Free Documentation Licence or later. It also has a project site, and issue tracker.

Symbiosis uses the following software, all of which is open-source:

What follows is step by step instructions to get up and running with controlling your server and setting up core services. The screen shots are taken from a Windows system, but all the programs used are also available for Mac OS X and GNU/Linux desktop systems.

Throughout the documentation, the example server used is example.vm.bytemark.co.uk. The example domain used is my-brilliant-site.com. These should be substituted as appropriate.

A server installed with Symbiosis will be running SSH, and will have had the admin user account created. This allows you to connect via SFTP to administer the machine.

The admin account should be used when administering a Symbiosis system to ensure that files and directories have the correct permissions.

Usage of SFTP is mandated for administrating the machine, such that all data are passed encrypted over the network.

Throughout the documentation the example server name example.vm.bytemark.co.uk should be substituted for your own server name.

The following figure shows FileZilla’s layout after successfully logging in. The display is divided into four main sections, the top left pane shows a directory tree, with the directories on your local computer, labelled a. Beneath that is a listing showing the contents of the currently selected local directory, labelled b. Then the top right pane shows the directory tree of the remote machine. When logging in as admin this will show /srv/ (c). Finally beneath that is the contents of that directory. Initially this will only contain one directory named after the machine. In this case example.vm.bytemark.co.uk/ is shown (d).

Once you’ve been able to successfully connect to your server, via FileZilla, you may proceed to configure email, or setup your website.

This section demonstrates how to carry out some common tasks with the FileZilla client:

The previous section dealt with setting up a web page using the default domain associated with the machine. A Symbiosis system can host many domains without any extra configuration. This section deals with configuring a second domain.

It has been assumed that both your server is hosted at Bytemark, and that this second domain is using the Bytemark name servers. If this is not the case, then Section 17.1, “Example DNS records” sets out the DNS records needed for the following procedure to work.

For the purposes of this tutorial, the domain my-brilliant-site.com is being hosted on the machine example.vm.bytemark.co.uk.

Within a hour, the DNS records for my-brilliant-site.com will be generated and uploaded to the Bytemark domain name servers. Navigating to that site will then show our new index page.

At this point, the site will also be visible at both http://my-brilliant-site.com and http://www.my-brilliant-site.com. This is part of the Symbiosis setup; if different pages were required at www.my-brilliant-site.com, a separate directory tree should be created for www.my-brilliant-site.com, with a different content as needed.

As previously noted if there is a directory present upon the machine with the name /srv/my-brilliant-site.com/public/htdocs/ the contents of that directory will be served for both:

This assumes that the appropriate DNS entries have been set up for the domain, pointing both my-brilliant-site.com and www.my-brilliant-site.com at the primary IP address of the machine. If a wildcard DNS entry for the domain were pointed at the primary IP, then any prefix, including www. would be served from the same directory, for example web.my-brilliant-site.com and wonder.web.my-brilliant-site.com. The only additional step you’ll need to perform is to create the appropriate DNS entry, which is discussed in Section 17.2, “Adding a wild-card hostname record”.

If you wish to mandate a particular hostname for your sites that can be arranged via mod_rewrite as discussed in Section 14.6, “Redirecting to the preferred website domain”.

It is possible to test the content associated with a new domain before it has been registered or had any DNS configuration done. This is done using the testing prefix.

If your machine is not hosted at Bytemark, or your machine name does not end in bytemark.co.uk then a wild-card DNS record is needed for this to work. This is discussed in Section 17.2, “Adding a wild-card hostname record”.

For example, to view the site my-brilliant-site.com which is hosted on the machine example.vm.bytemark.co.uk, simply head to http://my-brilliant-site.com.testing.example.vm.bytemark.co.uk/.

This testing URL is immediately available following the upload of the index.html or index.php files.

Note that there is no www at the start of the testing URL.

It has been assumed that the first few steps in Section 4.1, “Hosting a web page using your own domain” have been followed, i.e. that a directory has been created under /srv/ for the domain my-brilliant-site.com.

That is all that is needed to set up a new mailbox. To test we can immediately use the webmail application, SquirrelMail, supplied with Symbiosis.

X-Spam-Score: 1.2
X-Spam-Bar: +
X-Spam-Status: innocent

Although most users will prefer to receive and write their emails using a dedicated client (such as ThunderBird, or Microsoft Outlook) the Symbiosis system includes a mail client you can access with nothing more than a web-browser.

This section briefly documents using the Squirrelmail webmail system.

The following details might be needed when setting up a mail client to use an email account. The user of bob@my-brilliant-site.com on the machine example.vm.bytemark.co.uk has been chosen for these worked examples.

It is recommended that all communication with the mail server is conducted over encrypted connections, either using SSL, or TLS.

Incoming email can be collected using either the IMAP or POP3 protocols. IMAP is generally recommended over POP3 as it can handle folders, push notification, can selectively download message parts, and the email remains on the server enabling back-ups to be made.

Outgoing email is sent using SMTP. It is good practice to send any outgoing email via the Symbiosis server, rather than any relay service provided by your ISP.

Managing sieve filters is done using the ManageSieve protocol.

For both sending and receiving email, and managing sieve filters, the following login information would be used.

The default ports are used for all protocols. For further details see Section 15.1, “Port Configuration”.

It is common for Internet service providers to block the standard outgoing email port, i.e. port 25. If your email client complains that it cannot connect to your server on this port, then port 587 is provided as an alternative.

It is possible to limit the amout of data that can be kept in a domain’s public/ directory using an FTP quota. This is done by creating a file inside the domain’s config/ directory called ftp-quota. Inside this file should be a number of bytes at which the quota is set.

The number can have a suffix of k, M, G, or T representing kilo-, mega-, giga-, or terabytes respectively.

For example, to prevent the author of my-brilliant-site.com from putting more than 150MB inside their public/ directory, create a file called /srv/my-brilliant-site.com/config/ftp-quota with the contents 150M. This will limit their space usage to 150,000,000 bytes.

The file is a list of jobs, one per line. Each line specifies first the times and days at which a job should run, followed by the command to run.

The first five fields, which are separated by spaces, specify the time and date at which the job should run. The rest of the line is interpreted as the command.

In addition an asterisk can be used to indicate for every allowed value. For example, to execute the command echo Hello Dave. at 18:40 every day, the crontab line would read as follows.

40 18 * * * echo Hello Dave.

Three-letter names can also be specified for use in instead of numbers for days of the week and months.

Any output generated by a command will be sent to the root account, unless specified otherwise. If no output is generated, no email will be sent.

The fields can be specified in the following ways:

Ranges can also be specified across "boundaries". For example 22-2 in the hour field will be interpreted as 22, 23, 0, 1, 2; Nov-Feb in the month field will mean 11, 12, 1, 2.

There is also a selection of shortcuts available:

The full crontab format is explained in more detail in the crontab (5) manual page.

The output can be emailed to any recipient by specifying the MAILTO parameter at the top of the file.

For example, we would like to mail any output from our commands to bob@my-brilliant-site.com.

#
# send any output to Bob
#
MAILTO=bob@my-brilliant-site.com
#
# run at 9am every Monday - Friday
#
0 9 * * 1-5 wget http://www.my-brilliant-site.com/cron.php

If MAILTO is not set, or no recpient is specified, then they output will be sent to the domain directory’s owner, e.g. if /srv/my-brilliant-site.com/ were owned by admin, the output would get sent to admin@example.vm.bytemark.co.uk.

As mentioned above, the backup script will attempt to ensure that your local backups are uploaded to a remote server, to protect against data loss if your system fails catastrophically.

For Bytemark customers this location should be determined automatically.

If this process fails, or you are not a Bytemark customer, you can specify the correct location in /etc/symbiosis/dns.d/backup.name. This should be a fully-specified rsync path.

Every day, when runs it generates output saying what has been backed up, and if there were any errors during the backup process. This email will get sent to the root account of the local hostname.

The Symbiosis system is comprised of many components, each working together to deliver a complete solution to your hosting needs. Different systems and components of your server will generate email notifications to alert you of important events and warnings. It is important that such emails are read.

By default all system-generated emails will be delivered to the root user of your primary domain. (This is the first domain which is configured when your machine is setup, and will probably be a name such as example.vm.bytemark.co.uk.)

Rather than make it mandatory that you read the root mailbox it is suggested that you configure email forwarding such that mail sent to root@example.vm.bytemark.co.uk is delivered to your personal email address.

A common means of compromising machines what is called a "dictionary attack", this involves a remote user (or computer) trying to connect to a server with a collection of thousands of usernames and passwords.

This dictionary of usernames and passwords will include common choices such as a username of "test" and a password of "test", along with many other less-likely looking candidates. The Symbiosis Firewall has a blacklisting program that detects attacks via various protocols, including SSH, and configures the firewall to block further connections. This is documented in Section 16.6, “Blocking abusive remote hosts”.

The best defence is to ensure that when you add users, or change system passwords, that you never ever choose simple passwords which might be liable to be guessed, or included in an attackers' dictionary.

There is a regular test on all the passwords used to access email and FTP under Symbiosis, the output of which will get sent to the root email account. Please see the note in earlier in this chapter regarding email notifications.

Over time security bugs can be found in software packages, and if such a problem is discovered in a package you’re using then your machine is at risk until it has been updated.

The Symbiosis system is configured to automatically download and install appropriate security updates to the packages in the base operating system and from the Symbiosis repository itself.

However if you’ve chosen to install additional applications such as Wordpress you must ensure that you look for updates regularly. Often this can be done by subscribing to the application’s announcements mailing list.

When granting FTP access to your machine, it is important to bear in mind that the person who uses that login can trivially access other files on the system. Various methods could be used, including uploading PHP or CGI scripts.

There are ways to mitigate the effect of this access, including setting permissions such that sensitive files are not world-readable, and hashing passwords. However the safest way to manage this problem is to ensure that only trusted users are given FTP access.

So far connecting using SFTP has been documented. This is used to manage files on the machine. From time to time it can be necessary to have to run commands on the machine itself. This is where SSH comes in.

SSH allows shell access to a machine, which provides the ability to run commands directly on that machine. Shell access is the equivalent of the MS-DOS or cmd prompt on Windows PCs, or the terminal on machines running Mac OS X or Linux. SSH is an encrypted protocol, like SFTP, ensuring that all commands and passwords pass between your computer and the server are protected against eavesdroppers.

For Bytemark customers, SSH is also used to access the Console Shell of the machine.

PuTTY is a free and open-source SSH application, and available for download from its homepage. It is available for both Windows and Linux desktop machines.

Both Linux and Mac OS X desktop machines tend to come with the ssh command available.

First you must have an additional IP address routed to your machine. Your ISP should be able to do this. The IP address can either be IPv4 or IPv6.

Once your machine has been allocated an additional IP Address, you must tell your machine to accept traffic addressed to both your original and new IP addresses.

It has been assumed that the site requiring the new IP address is already configured as described in Section 4.1, “Hosting a web page using your own domain”.

Within an hour Symbiosis will have added this new address to your machine’s network interface, updated the domain’s DNS data and uploaded them to the name servers, as well as reconfigured the Apache web server to use the new IP for that domain.

In order to purchase an SSL certificate, you need to generate an SSL key and a certificate request on the Symbiosis machine.

With that request, you can buy a new certificate. To view the request, run cat ssl.csr. It will look like

-----BEGIN CERTIFICATE REQUEST-----
AIIB4zCCAUwCAQAwgaIxCzAJBgNVBAYTAkdCMRMwEQYDVQQIEwpNYW5jaGVzdGVy
MRMwEQYDVQQHEwpNYW5jaGVzdGVyMQ0wCwYDVQQKEwRCbGFoMQ8wDQYDVQQLEwZU
aGluZ3kxHjAcBgNVBAMTFW15LWJyaWxsaWFudC1zaXRlLmNvbTEpMCcGCSqGSIb3
DQEJARYacm9vdEBteS1icmlsbGlhbnQtc2l0ZS5jb20wgZ8wDQYJKoZIhvcNAQEB
BQADgY0AMIGJAoGBAMrTIaLKyvsxDz9WHhY5xJvHVKD+dmAuzpv2HichYejJQTTl
gXdfrrZjVWm45ZJy9TEcB5DM0qsQBSqseMner7YvAJJ3PlTd7o3Rkjztt1orP1e7
hAkpKLW2dQAvnr3RtK2w8mK+OdJYPSJfzoChCKlG64Un2VmgDfAiNMS4GCi1AgMB
AAGgADANBgkqhkiG9w0BAQUFAAOBgQBx1I52EXnKRL1YfPYIA8CXUeFRZzDbuVKQ
+fwP5Ig5BANBldMnRePY29RH7yJ2YRXTWHfo6erWT4DZVkJhLpWwBTqB/kGcjEjv
zN7D78VSSQzEb2fOcRcxd9fWmiIcIWINisjBv9gBbGH7L3UosOtdzEWyzpEjb+Or
nL4UrZV3JA==
-----END CERTIFICATE REQUEST-----

The entire output (including the BEGIN and END lines) should be copied and pasted into the appropriate part of the form when purchasing.

There are generally two types of SSL certificate: those that are self-signed, and those that are signed by a third-party. Self-signed certificates are free, but cause warnings to be produced in people’s browsers. Third-party certificates are purchased, and hopefully generate no warnings.

For an example of what a warning might look like in your browser, go to https://example.vm.bytemark.co.uk.

Purchasing a certificate is straightforward. The first part is the hardest: picking a supplier. There are many available, for example RapidSSL, Verisign, or Comodo.

During the purchase process, you will be asked for the certificate request. Instructions on how to do this are shown in Section 12.2, “Generating an SSL key and certificate request”.

Once purchased, you should end up with a new certificate, and possibly a "bundle". These should be downloaded onto your local computer. Installation of these is described in Section 12.4, “Uploading your new certificate, and optional bundle”.

Now we have our certificate, we need to upload it on to our machine. If you’ve generated the certificate on the machine, you can safely skip this procedure.

Once this procedure has been completed we can move on to the next section.

Once you’ve configured the SSL certificate, as described in the previous sections, you’ll find that your site is accessible to users over HTTP and HTTPS.

If you prefer to ensure that each visitor to your website uses the SSL-protected site you can make it mandatory by creating an empty file called config/ssl-only. This should cause the site to be reconfigured to redirect all traffic to the SSL-secured site.

Installing Symbiosis on Debian Squeeze is relatively straightforward. Before beginning it is advisable to have complete, tested backups of your system. That said, the Symbiosis packages have been designed to install, and be removed cleanly.

In order to install Bytemark Symbiosis on Debian 6.0 (Squeeze) add the following lines to /etc/apt/sources.list.d/symbiosis.list.

#
# Bytemark Symbiosis Packages
#
deb     http://symbiosis.bytemark.co.uk/squeeze/  ./
deb-src http://symbiosis.bytemark.co.uk/squeeze/  ./

Then run the following commands to install a complete Symbiosis system. This will pull in all the packages and software needed to run a system as described by this manual.

apt-get update
apt-get install --install-recommends bytemark-symbiosis

Upgrading from lenny should be straightforward, but it does involve touching nearly every part of system. Debian provide comprehensive release notes, of which chapter 4 covers the recommended upgrade procedure. It is worth reading, although for convenience we have produced a shorter version in this section.

The first thing to do is make sure that you have backups. These should be kept in /ver/backups/localhost, and they should be up to date.

Now we can proceed with the upgrade. Next we can alter /etc/apt/sources.list. Essentially change all instances of the word lenny to squeeze. Also comment out the debian-volatile repositories, as these have been removed in the Squeeze release. Then change the Symbiosis repository lines to match those shown in the previous section.

An minimal /etc/apt/sources.list. 

deb http://mirror.bytemark.co.uk/debian/  squeeze main contrib non-free
deb http://mirror.bytemark.co.uk/debian/  squeeze-updates main contrib non-free
deb http://security.debian.org/           squeeze/updates main contrib non-free
deb http://symbiosis.bytemark.co.uk/squeeze  ./

Having done that, the Apt lists can be updated, and the upgrade started.

apt-get update
apt-get dist-upgrade

During the upgrade, various questions will be asked. Here are the questions along with the answers that should be given. Note that these are the questions that are caused by having lenny Symbiosis installed. There may be others asked depending on the precise state of the system.

Following the completion of the dist-upgrade, it is recommended that symbiosis-mysql is specifically installed, as this will upgrade the MySQL server to version 5.1.

sudo apt-get install symbiosis-mysql

Finally we can fully enable phpmyadmin by setting up a MySQL database for it. To do this run:

sudo dpkg-reconfigure phpmyadmin

And that should be it!

Following the release of this software, several small issues came to light. Here is a summary of those issues and the fixes that can be put in place if needed.

sudo backup2l -b 0

sudo /etc/init.d/apache2 restart

sudo apt-get remove --purge php5-suhosin

sudo apt-get remove --purge php5-mhash

Each component that makes up Symbiosis is separately packaged as follows. Each pacakge can be installed individually if needed.

Symbiosis is an attempt to encourage best practice at all times in systems administration, whilst keeping things as simple as possible, and free of surprises. As a result there are a few general rules to bear in mind when tinkering with your system.

# DO NOT EDIT THIS FILE - CHANGES WILL BE OVERWRITTEN

# Checksum MD5 586732ff59e60115d0ec1c4905c72773

# ------------------------------------------------------------------------------
# /etc/exim4/symbiosis.d/10-acl/40-acl-check-mail/00-header
# ------------------------------------------------------------------------------

# ACL that is used after the MAIL command
acl_check_mail:

# ------------------------------------------------------------------------------
# /etc/exim4/symbiosis.d/10-acl/40-acl-check-mail/90-default
# ------------------------------------------------------------------------------

# Allow anything not already denied to connect
  accept

This is covered in more detail in Chapter 4, 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/.

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 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 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.

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.

Browsing to my-domain.co.uk will show the same content that appears at my-domain.com.

If a document tree were created in /srv/my-brilliant-site.com/public/ 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/my-brilliant-site.com/public/htdocs/.htaccess 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.

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.

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.

Here is an example configuration layout for the domain my-brilliant-site.com, all of which is contained under /srv/my-brilliant-site.com/.

The mail servers have been set up with standard port assignments as follows. These are all the standard ports for the protocols.

In order for a domain to be configured to accept email, one of two things must be present. Either the domain must have a mailboxes/ directory present, or one of the files config/default_forward or config/aliases must be present.

For example, if the domain my-brilliant-site.com would like to host mail normally, i.e. one mailbox per user hosted on the same machine, then the directory /srv/my-brilliant-site.com/mailboxes/ should be created. Then in there, one directory per user should be created. If bob@my-brilliant-site.com would like to receive mail, then /srv/my-brilliant-site.com/mailboxes/bob/ should be created.

Assuming that this is the only directory inside /srv/my-brilliant-site.com/mailboxes/ then only mail addressed to bob@my-brilliant-site.com will be accepted. Any other mail addressed to my-brilliant-site.com will be rejected.

If you would like to accept all mail for my-brilliant-site.com, regardless of who it is addressed to, then create the file /srv/my-brilliant-site.com/config/default_forward. The contents of this file should be a single email address, or a comma-separated list of email addresses. For example, to forward all mail to bob@my-brilliant-site.com, regardless of who it is addressed to, then /srv/my-brilliant-site.com/config/default_forward should contain bob@my-brilliant-site.com.

If you would like the domain nomail.my-brilliant-site.com not to receive any mail at all, then remove the directory /srv/nomail.my-brilliant-site.com/mailboxes/ and ensure that the file /srv/nomail.my-brilliant-site.com/config/default_forward does not exist.

The password for a mailbox should be set by the contents of a file named password inside a user’s mailbox directory. The contents of this file may be in plain text, or encrypted.

To encrypt a password on the command line, you can run the following command, substituting "my password" for your password. This encrypts the password using the SHA-512 algorithm.

echo "my password" | symbiosis-encrypt-password  > password

This just uses the standard crypt function available under most Linux platforms, as well as perl and PHP.

All email addresses can be used with a suffix. This allows people to filter their email by the To: address. The separator between the local part and suffix is the + sign.

For example, Bob signs up to a shopping site at http://example.com. He might use bob+example@my-brilliant-site.com his email address when signing up, such that he can filter all email from that shop.

Symbiosis can enforce users' mailbox size with quotas. This will prevent mail from being delivered to a user if their mailbox grows too large. The user will receive a warning when they have filled up their mailbox to 75% of its size.

A default quota for each individual mailboxes in a domain can be specified in config/mailbox-quota. A per-mailbox quota can be defined in a file named quota which resides in a user’s mailbox directory.

These files both have the same format, which is just a number of bytes over which mail should not be delivered. This number can have a suffix of k, M, or, G which represent kilobytes, megabytes, and gigabytes, or ki, Mi, or Gi to represent kibibytes, mebibytes, and gibibytes, respectively.

For example, to limit the mailbox size for all mailboxes in my-brilliant-site.com to 200MB, i.e. 200,000,000 bytes, put 200M in /srv/my-brilliant-site.com/config/mailbox-quota.

To grant bob@my-brilliant-site.com a 1GiB quota, i.e. 1,073,741,824 bytes, put 1Gi in /srv/my-brilliant-site.com/mailboxes/bob/quota.

Quotas in a user’s mailbox directory take precedence over the default quota.

Sieve is a standard language that users can employ to filter their email on the server. Additionally using any one of a number of clients, users can edit their filtering rules without needing shell access to the server.

Each user can create a number of scripts in a directory called sieve.d/, with the current script being kept in a file called sieve.

There are two methods of forwarding email. The first is a per-mailbox forwarding service, and the second is a per-domain service. For the per-user service, a file named forward should be put in a user’s mailbox directory. The per-domain service uses the same file format as the per-user service, but the file should be uploaded to config/default_forward instead.

For example, bob@my-brilliant-site.com would set up a file called /srv/my-brilliant-site.com/mailboxes/bob/forward.

If all the mail for my-brilliant-site.com needed to be forwarded elsewhere, then the file would be called /srv/my-brilliant-site.com/config/default_forward.

Both of these files can be interpreted in two ways. Firstly they can be a comma separated list of email addresses. For example, if Bob wanted to forward his email onto Charlie and Dave, his forward file might read

charlie@example.com, dave@example.com

The second way these files are interpreted is as an Exim filter file. The full specification is documented at the Exim project site.

Here are some examples of what is possible.

To forward mail on, but keep a copy

# Exim filter
unseen deliver charlie@example.org, dave@example.com

To rewrite all mail for a domain to example.com. This is probably best used in config/default_forward.

# Exim filter
deliver $local_part@example.com

The Exim documentation has further examples of what is possible.

It is possible to set a vacation message for a user by putting a message in file called vacation in the user’s mailbox directory.

For example, for bob@my-brilliant-site.com, the message would go in /srv/my-brilliant-site.com/mailboxes/bob/vacation. On Bob’s return, the people who received vacation messages are logged to /srv/my-brilliant-site.com/mailboxes/bob/vacation.log. Once he’s read it, that file, along with /srv/my-brilliant-site.com/mailboxes/bob/vacation and /srv/my-brilliant-site.com/mailboxes/bob/vacation.db should all be removed.

Each domain can have a list of aliases. This is just a file that contains a list of local parts, and a list of places they should be sent on to. This file should be in the config/ directory and is named aliases.

For example, my-brilliant-site.com has a list of dummy addresses that should be sent on to Bob. So the aliases file would be kept at /srv/my-brilliant-site.com/config/aliases and contains the following.

webmaster   bob@my-brilliant-site.com
chairman    charlie@example.com
staff       bob@my-brilliant-site.com, charlie@example.com, dave@example.com

This ensures that webmaster@my-brilliant-site.com is sent to bob@my-brilliant-site.com; chairman@my-brilliant-site.com is sent to charlie@example.com; staff@my-brilliant-site.com is sent to bob@my-brilliant-site.com, charlie@example.com, and dave@example.com.

The configuration for SpamAssassin for the admin user is kept in /srv/.spamassassin/user_prefs. Here you can adjust what score is needed to reject spam, and which tests are used during scanning. This file will only appear after a mail has been received with spam detection turned on, but one can be created and configured before this occurs.

The file contains comments and instructions, and further tips can be found on the SpamAssassin wiki.

In brief, to cause more mail to be rejected, you need to reduce the threshold score. Therefore change the line reading # required_score 5 should be changed to required_score 4. Notice that the # has been removed at the start of the line to un-comment it.

Similarly if mail is being rejected, you can increase the score.

Further instructions can be found on the SpamAssassin wiki.

There is no facility to train the SpamAssassin Bayesian learner yet.

Headers are added to messages when spam or virus scanning is enabled. These can be used by email clients to filter email, for example in to spam or quarantine folders.

With spam scanning enabled, any email that is accepted has the following headers added

The score is determined by SpamAssassin, and is the basis for acceptance or rejection. The higher the score, the more certain SpamAssassin is that the message is unwanted. The default threshold for rejection is 5.

The bar is a length of pluses or minuses that provide an easy-to-parse representation of the score. A positive score is given pluses, a negative score minuses. For example a score of 5.6 would be represented as ++++++; a score of -2.2 would be represented as --.

The status is always either innocent or spam, depending on the score.

When virus scanning is enabled, the header X-Anti-Virus is added to messages that have been scanned. This is set to either infected or clean.

There are three lists from Spamhaus that can be used to reject email based on the sender’s IP address, namely

These lists are combined to form the Zen list.

The following instructions will enable use of these lists on our example domain my-brilliant-site.com.

That is all that is needed to start using the Spamhaus Zen blacklist. If you’d rather use a combination of lists create one or more of the following files:

Here is an example configuration layout for the domain my-brilliant-site.com. All the following files are kept in /srv/my-brilliant-site.com/.

All usual firewall configuration can be carried out by creating and deleting files in /etc/symbiosis/firewall/. In this directory there are a number of subdirectories. Permissions for inbound connections are stored in /etc/symbiosis/firewall/incoming.d/, and outbound connections in /etc/symbiosis/firewall/outgoing.d/.

These files are all of the format number-name. The number determines the position of the rule in the firewall, the name is the name of the service that we wish to permit. These names are stored in /etc/services. There are also names that do not correspond to services, which are documented in the next section.

Additionally if the name is not known then the file format can be number-number where the first number specifies the position of the rule in the firewall, and the second number is the port that should be opened. For example, the files 10-http and 10-80 achieve the same effect.

Finally, each file can contain a list of hostnames or IP addresses to which that rule will apply, one per line. For example, if addresses were added to an incoming rule, named incoming.d/10-accept, all connections from those addresses would be accepted. If a file were added named outgoing.d/20-reject and address added to that file, then outgoing connections to those addresses would be rejected.

For example, to allow an incoming connection to arrive at your machine, and be accepted, on port 22, you would create the file /etc/symbiosis/firewall/incoming.d/10-ssh. The firewall will update as soon as the file has been created, so no commands are needed to be run.

If you were wishing to ensure that your host would only accept incoming SSH requests from your office you might create the same file with the contents office.my-brilliant-site.com.

This would ensure that when the firewall was generated incoming connections on the SSH port would be accepted from the host office.my-brilliant-site.com but not from anywhere else.

There are a number of rules that don’t naturally fit the convention described above. This list describes rules that have been written specially for Symbiosis to cope with these situations. Each rule described below can be used in both incoming.d/ and outgoing.d/, and for both IPv4 and IPv6 addresses, unless otherwise specified.

These rules are used in the same way as those described in the previous chapter. Files are added in the incoming.d/ or outgoing.d/ directory with the name prefixed by a number giving the position of the rule. The files can contain addresses or hostnames, one per line, against which the rule should be applied.

These rules are all contained in /usr/share/symbiosis/firewall/rule.d/. It is perfectly possible to write your own rules based on those in this directory, but they should be kept in /usr/local/share/symbiosis/firewall/rule.d/.

This example should be read in conjunction with the previous sections. A machine has the following firewall rules defined for its incoming connections.

This would set up a firewall that would do the following tests, in order:

These rules would be installed for IPv4 and IPv6 connections using iptables and ip6tables respectively. To inspect the firewall rules at any given time, you can run sudo iptables -L -v -n which will return the current firewall status. In this example, the rules would look like this.

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target    prot opt in out source          destination
    0     0 ACCEPT    all  --  lo *   0.0.0.0/0       0.0.0.0/0
   13  1012 whitelist all  --  *  *   0.0.0.0/0       0.0.0.0/0
    0     0 blacklist all  --  *  *   0.0.0.0/0       0.0.0.0/0
    0     0 ACCEPT    all  --  *  *   0.0.0.0/0       0.0.0.0/0 state ESTABLISHED
    0     0 ACCEPT    all  --  *  *   0.0.0.0/0       0.0.0.0/0 state RELATED
    0     0 ACCEPT    icmp --  *  *   0.0.0.0/0       0.0.0.0/0 icmp type 8
    0     0 ACCEPT    icmp --  *  *   0.0.0.0/0       0.0.0.0/0 icmp type 0
    0     0 ACCEPT    icmp --  *  *   0.0.0.0/0       0.0.0.0/0 icmp type 11
    0     0 ACCEPT    tcp  --  *  *   1.2.3.4         0.0.0.0/0 tcp dpt:22
    0     0 ACCEPT    udp  --  *  *   1.2.3.4         0.0.0.0/0 udp dpt:22
    0     0 ACCEPT    tcp  --  *  *   0.0.0.0/0       0.0.0.0/0 tcp dpt:80
    0     0 ACCEPT    udp  --  *  *   0.0.0.0/0       0.0.0.0/0 udp dpt:80
    0     0 ACCEPT    tcp  --  *  *   0.0.0.0/0       0.0.0.0/0 tcp dpt:666
    0     0 ACCEPT    udp  --  *  *   0.0.0.0/0       0.0.0.0/0 udp dpt:666
    0     0 ACCEPT    tcp  --  *  *   0.0.0.0/0       0.0.0.0/0 tcp dpt:25
    0     0 ACCEPT    udp  --  *  *   0.0.0.0/0       0.0.0.0/0 udp dpt:25
    0     0 REJECT    all  --  *  *   0.0.0.0/0       0.0.0.0/0 reject-with icmp-port-unreachable

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target    prot opt in out source          destination

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target    prot opt in out source          destination
    0     0 ACCEPT    all  --  *  lo  0.0.0.0/0       0.0.0.0/0
    7  1388 ACCEPT    all  --  *  *   0.0.0.0/0       0.0.0.0/0 state ESTABLISHED
    0     0 ACCEPT    all  --  *  *   0.0.0.0/0       0.0.0.0/0 state RELATED
    0     0 REJECT    all  --  *  *   0.0.0.0/0       0.0.0.0/0 owner UID match 33 reject-with icmp-port-unreachable

Chain blacklist (1 references)
 pkts bytes target    prot opt in out source          destination
    0     0 REJECT    all  --  *  *   71.63.72.4      0.0.0.0/0 reject-with icmp-port-unreachable
    0     0 REJECT    all  --  *  *   61.145.118.190  0.0.0.0/0 reject-with icmp-port-unreachable

Chain whitelist (1 references)
 pkts bytes target    prot opt in out source           destination
   13  1012 ACCEPT    all  --  *  *   212.110.163.132 0.0.0.0/0

This listing shows how the rules in the files under /etc/symbiosis/firewall/ are translated into iptables rules. It also shows that by default all connections on the loopback interface lo are permitted, and that the whitelist and blacklist tables have references in the INPUT, i.e. incoming, table before the rules defined in /etc/symbiosis/firewall/incoming.d/ are applied.

IPv6 rules follow the same format, and can be checked by running sudo ip6tables -L -v -n.

By default the firewall contains the rule outgoing.d/50-reject-www-data, which is designed to reject outgoing connections made by the web server. This prevents many ways of infecting a machine with malicious software following a compromise in a web application.

Following establishing that a web application has security flaws, hackers will attempt to trick the application into downloading their software onto the machine. Once downloaded the software is used in various ways, for example to participate in denial of service attacks, or to access confidential data on the machine. Thus this rule is a basic defence against vulnerable web applications being exploited, and is a good thing to have in place.

However there are legitimate cases when a web application might need to make such a connection. For example, if you have an application which needs to make outgoing HTTP connections to update RSS or Twitter feeds, you will need to either add permitted addresses to the file, or remove it completely.

For example, to permit access to search.twitter.com, add that address to the file outgoing.d/50-reject-www-data to permit it.

Adding addresses to this file will permit outgoing connections to those addresses.

The Symbiosis firewall package should allow you to carry out the most common tasks, simply by creating files named after the services you wish to permit or deny.

However there are times when you might wish to make your own custom additions, and for this purpose the firewall package allows you to run an unlimited number of custom scripts/programs once it has loaded the rules - these scripts may perform arbitrary actions, but will be most typically used to update the firewall rules, via the iptables or ip6tables commands.

The program run-parts is used to execute scripts in /etc/symbiosis/firewall/local.d/, after the firewall has finished loading. This means that the scripts have to have to fulfil the naming conditions described in the run-parts(8) manual page. Essentially the script should be marked executable, and only contain alphanumeric characters in its name.

The symbiosis-firewall-blacklist tool runs four times an hour, and is designed to scan your server’s logfiles for abusive behaviour from malicious remote hosts. Malicious activity which is detected will result in the remote host being denied further access to your server.

Currently we regard malicious activity as:

Every 15 minutes various logfiles are scanned for certain patterns to search for new malicious IPs, and the firewall is updated.

These patterns are defined in /etc/symbiosis/firewall/patterns.d/. For example, for SSH the following pattern definition is used:

#
#  The logfile we look for matches within.
#
file = /var/log/auth.log 

#
#  Any matches will be denied access to these ports.
#
#  Comma-separated values are expected.
#
ports = 22 


#
#  Patterns we'll match upon.
#
Failed password for invalid user [^ ]+ from __IP__ port [^ ]+ ssh2 
Failed password for [^ ]+ from __IP__ port [^ ]+ ssh2

If an IP matches one of those patterns in the period since the last check was made, it is added to the blacklist.

Disabling the firewall completely will disable the blacklisting behaviour, but you might also wish to disable that seperately.

To do this, login over SFTP as admin and create the file /etc/symbiosis/firewall/blacklist/disabled. This will immediately disable and clear the blacklist.

The symbiosis-firewall-whitelist tool runs once per hour, and is designed to perform the opposite task to the symbiosis-firewall-blacklist script - in short it is designed to ensure that any remote host which has successfully connected to your server in the past isn’t (accidentally) blacklisted in the future.

Every hour the script will examine the successful logins which have been observed recently. Each IP address which has successfully been the source of a login attempt will be permitted access to the system on a global basis, and will thus not be locked out.

As with the automatic blacklist, IPv6 addresses are masked to a /64, which is the smallest recommended assignment for an end site.

To disable the automatic whitelist, login over SFTP as admin and create the file /etc/symbiosis/firewall/whitelist/disabled. This will immediately clear the whitelist, and prevent further updates.

If you wish you may disable the firewall completely, allowing remote users to connect to any service you have running upon your machine.

We’d not recommend that you disable the firewall, because it does provide a increase in system security, but if you wish it is possible by executing the following two commands:

touch /etc/symbiosis/firewall/disabled
sudo symbiosis-firewall flush

The presence of the disabled rule will not itself clear the firewall, merely prevent further updates to it, which is why the flush command is needed.

All configuration of the firewall is conducted via the presence or absence of files in a number of directories beneath /etc/symbiosis/firewall/. Actions and rules are all kept under /usr/share/symbiosis/firewall/.

This is an example of the records Symbiosis generates for my-brilliant-site.com. They are created automatically and stored in config/dns/my-brilliant-site.com.txt.

DNS records example. 

#
#  Nameserver records. 
#
.my-brilliant-site.com::a.ns.bytemark.co.uk:300
.my-brilliant-site.com::b.ns.bytemark.co.uk:300
.my-brilliant-site.com::c.ns.bytemark.co.uk:300

#
#  The domain name itself 
#
=my-brilliant-site.com:89.16.174.65:300

#
#  Useful aliases. 
#
+ftp.my-brilliant-site.com:89.16.174.65:300
+www.my-brilliant-site.com:89.16.174.65:300
+mail.my-brilliant-site.com:89.16.174.65:300

#
# A record for MX 
#
+mx.my-brilliant-site.com:89.16.174.65:300

#
# The domain name itself -- AAAA record and reverse. 
#
6my-brilliant-site.com:200141c80001596d0000000000000065:300

#
# Useful aliases -- AAAA records only
#
3ftp.my-brilliant-site.com:200141c80001596d0000000000000065:300
3www.my-brilliant-site.com:200141c80001596d0000000000000065:300
3mail.my-brilliant-site.com:200141c80001596d0000000000000065:300

#
# AAAA record for MX
#
3mx.my-brilliant-site.com:200141c80001596d0000000000000065:300

#
#  MX record -- no IP defined, as this is done separately above. 
#
@my-brilliant-site.com::mx.my-brilliant-site.com:15:300

In addition to these records for each domain, a wild-card A record is needed for the hostname such that the .testing. prefix works. If your machine is at Bytemark, this has already been setup for your machine’s Bytemark alias, for example example.vm.bytemark.co.uk.

If your machine is not hosted at Bytemark, or your hostname does not end in bytemark.co.uk then you will need to set this alias up. Adding the following line to your DNS file will work, assuming the domain is hosted at Bytemark. This assumes that your machine is called host.example.com and that your machine’s IP address is 1.2.3.4.

+*.host.example.com:1.2.3.4

Bytemark Hosting offer wholesale spam protection for their hosting customers. To enable this service simply create the file /srv/my-brilliant-site.com/config/bytemark-antispam. This will update the DNS records as required as well as causing mail sent directly to your machine to be temporarily rejected, ensuring spammers cannot circumvent the anti-spam protection.

If you wish to move your domains between two machines running Symbiosis and using the Bytemark content DNS service, you must contact Bytemark Support to arrange the domain to be moved between content DNS accounts.

This results from the necessity for ensuring that only people with the proper authorisation can change live DNS data. Once a domain has been hosted on our network, a content DNS account will have sole authority for it.

If you purchase a second server and move some of your domains onto it, or purchase a domain from another Bytemark customer you must contact us to move authority for the domain into the correct account.

Until this is done, although the Symbiosis system will be creating and uploading data it will not be to the account with the authority to make the data live.

The crontab can also be tested. To do this you have to SSH to the machine, usually as admin to run the command.

For example, to test the my-brilliant-site.com crontab navigate to /srv/my-brilliant-site.com/config/ and run symbiosis-crontab --test crontab.

The my-brilliant-site.com crontab reads

# Send any output to Bob
#
MAILTO=bob@my-brilliant-site.com

#
# run at 18:40 every day
#
40 18 * * *       echo Hello Dave.

#
# run at 9am every Monday - Friday
#
0 9 * * mon-fri wget http://www.my-brilliant-site.com/cron.php

#
# Run once a month
#
@monthly          /usr/local/bin/monthly-job.sh

Therefore the output generated is

 Environment
 ------------------------------------------------------------------------
 HOME = /srv
 LOGNAME = admin
 PATH = /usr/local/bin:/usr/bin:/bin
 MAILTO = bob@my-brilliant-site.com
 ========================================================================

 Jobs next due -- Local time 2010-06-17T17:57:37+01:00
 ------------------------------------------------------------------------
 Date                       Command
 ------------------------------------------------------------------------
 2010-06-17T18:40:00+01:00  echo Hello Dave.
 2010-06-18T09:00:00+01:00  wget http://www.my-brilliant-site.com/cron.php
 2010-07-01T00:00:00+01:00  /usr/local/bin/monthly-job.sh
 ========================================================================

There are various automated tasks which are executed upon a Symbiosis system. These scheduled tasks are responsible for automating things such as:

The following section document precisely which jobs are installed by default, along with their purpose.

These are the system tasks which are installed by default:

As a security measure, your MySQL server is not opened to the world. However you might wish to access it remotely for performing queries, or allowing other hosts to otherwise communicate with it.

Your MySQL server should be configured already to listen upon your external IP addresses. Therefore only two steps are needed to configure remote access: opening the firewall, and adding a user with remote privileges to the database.

In Symbiosis the Backup2l configuration is generated from the snippets in /etc/symbiosis/backup.d/conf.d/.

Additionally we’ve configured the backup software to easily execute a number of scripts before and after the backup is performed:

To list the contents of your backup area you need to run backup2l with the "-l" flag:

all.1: /etc/.pwd.lock
all.1: /etc/GeoIP.conf.default
all.1: /etc/X11/Xresources/x11-common
all.1: /etc/X11/Xsession
all.1: /etc/X11/Xsession.d/20x11-common_process-args
all.1: /etc/X11/Xsession.d/30x11-common_xresources
all.1: /etc/X11/Xsession.d/40x11-common_xsessionrc
all.1: /etc/X11/Xsession.d/50x11-common_determine-startup
...

Here you will see the contents of the /etc/ directory which have been archived.

If you’d like to restrict this view you can apply a regular expression to filter the results. For example we can list the files which match the pattern passwd with this command:

~# backup2l -l passwd
Listing locations...
all.1: /etc/exim4/passwd.client
all.1: /etc/passwd
all.1: /etc/passwd-
all.1: /etc/phpmyadmin/htpasswd.setup
all.1: /etc/pure-ftpd/pureftpd.passwd
...

To illustrate how this works, an example is used. We’re looking for a backup of the file /etc/passwd.

That has restored the file to etc/passwd in the current directory. It is not recommended to run this program in the / directory, as any existing files will get overwritten.

It is also possible to pick which version of a file you wish to restore.

We have now successfully restored the file to etc/passwd in the current directory. We can check by running ls -la etc/

total 16
drwxr-xr-x  2 root  root  4096 2008-09-09 09:56 .
drwxr-xr-x 14 root  root  4096 2008-09-09 09:51 ..
-rw-r--r--  1 root  root  1118 2008-06-19 11:29 passwd

The Symbiosis system assumes that it has access to an associated external storage area. It will try and use rsync to upload the backups to this area, via a script named /etc/symbiosis/backup.d/post-backup.d/99-upload-backup.

If the host is on Bytemark’s network, this script can establish the backup space name automatically. Otherwise you can specify it manually by setting the full rsync path in /etc/symbiosis/dns.d/backup.name.

Before each backup a second script will synchronise the remote backup space locally, ensuring that a complete set of backups are held in both places. This means that if disaster strikes your machine, it is straightforward to recover your backups. This is done by running /etc/symbiosis/backup.d/pre-backup.d/00-download-backup.

This also helps to maintain the integrity of the differential backups provided by backup2l by replacing any files accidentally removed from the local backup directory before the backup starts.

It is possible to reduce the size of the backups stored locally. The first thing to do is check the current status of the backups by running sudo backup2l -s. This will present a summary of the current backups. For example:

backup2l v1.5 by Gundolf Kiefer

Summary
=======

Backup       Date       Time  |  Size   | Skipped  Files+D |  New  Obs. | Err.
- ----------------------------------------------------------------------------
all.1        2010-08-10 02:52 |   41.7M |       0     3836 | 3836     0 |    0
all.11       2010-11-01 04:45 |   38.1M |       0     3935 | 1517  1418 |    0
all.12       2011-01-21 04:27 |   39.7M |       0     3985 |  561   511 |    0
all.121      2011-01-30 04:38 |   10.5M |       0     4001 |  137   121 |    0
all.122      2011-02-08 03:54 |    1.5M |       0     4029 |  129   101 |    0
all.123      2011-09-07 05:08 |   33.8M |       0     3892 | 1437  1574 |    0
all.124      2011-09-16 05:07 |    1.3M |       0     4791 |  956    57 |    0
all.125      2011-09-25 04:45 |    868K |       0     5676 |  928    43 |    0
all.126      2011-10-04 05:15 |   11.3M |       0     6559 |  990   107 |    0
all.127      2011-10-13 04:29 |    894K |       0     7444 |  928    43 |    0
all.128      2011-10-22 04:59 |    345K |       0     8329 |  935    50 |    0
all.13       2011-10-31 05:03 |   45.7M |       0     9218 | 6833  1600 |    0

Filesystem            Size  Used Avail Use% Mounted on
/dev/vda               10G  1.9G  7.6G  20% /

From here it is possible to see which levels of backups that can be pruned. In the above example the third-level backups all.121 to all.128 can be pruned, as there has been a subsequent second level backup, all.13. The downside of this is that any changes contained in those backups will be lost, and only changes from the all.12 will be available.

To prune these backups run sudo backup2l -p 121. This will then show Backup2l removing all.121 and all its dependent backups.

backup2l v1.5 by Gundolf Kiefer

Purging ...
  removing <all.121>
  removing <all.122>
  removing <all.123>
  removing <all.124>
  removing <all.125>
  removing <all.126>
  removing <all.127>
  removing <all.128>

Finally we need to make sure these deletions are synchronised to the remote backup space, to ensure that our deleted files do not mysteriously return again prior to the next backup run.

sudo /etc/symbiosis/backup.d/post-backup.d/99-upload-backup

Which will provide output similar to that shown below.

Sending backups to example.backup.bytemark.co.uk::example/example.vm.bytemark.co.uk...
building file list ... done
deleting localhost/all.lock
deleting localhost/all.128.tar.gz
....
deleting localhost/all.121.error.gz
deleting localhost/all.121.check
localhost/

sent 2.95K bytes  received 22 bytes  1.98K bytes/sec
total size is 400.59M  speedup is 134742.36

Those level three backups will no longer exist.

If you already had a password configured for the MySQL database prior to installing our packages it will be unchanged. The password for the root user is only changed if it is unset when the packages are installed or updated for the first time.

The Debian MySQL packages create a local user for automated use, so if you’re unsure of your MySQL password you may this login to reset it. You may find details of the Debian login contained in the file /etc/mysql/debian.cnf.

You, or a customer with FTP or SFTP/SSH access, may become locked out of the machine if repeated attempts are made to access the machine incorrectly

If you believe you’ve become locked out, via the firewall, it is possible to fix this if you have another means of connecting to your server.

Every evening your system will be configured to update itself. This ensures that you’ll have any Debian-provided security updates applied to your system. It will also update your system to the latest available collection of the Bytemark Symbiosis packages.

If your system fails to update you may correct this by running, as root:

apt-get update
apt-get dist-upgrade
apt-get -f install

The mail-server and FTP-server we’re running will refuse to work with directories which are owned by the root user.

If you find that you’ve added a new site/mailbox to your system and it doesn’t work but existing ones do then this is most likely the source of the problem.

Unless you’re handling ownership in a special way you may reset the permissions to avoid this problem by running the following command:

chown -R admin.admin /srv/

If you run into problems with the configuration of SSL-based sites please get in touch, this support is still very new and there might be a couple of kinks to work out of the process.

The most common problem is that you need to install a "bundle" or keychain file.

If the missing keychain/bundle is the problem you’ll see this logged in the Apache SSL error file beneath /var/log/apache2. Each generated SSL-site will use its own logfile - rather than the global access.log and error.log file. So taking a look at that could be useful with the shell command:

tail /var/log/apache2/*ssl*.log

You should be able to validate the combined SSL private key and certificate via the use of the openssl tool; run the shell command:

openssl verify /srv/my-brilliant-site.com/config/ssl.key
..
error 18 at 0 depth lookup:self signed certificate
OK

You’re looking for the "OK" at the end, rather than the error message which is harmless.