Archive for the ‘Linux’ Category

Duplicity, FTPlicity and Python version troubles. Can not restore backup ?

Thursday, December 6th, 2007

Recently I installed duplicity on the viibee.com servers to backup the video files created there.
Since our backup server uses FTP I also grabbed ftplicity (german tutorial) and installed everything.

Duplicity can create incremental backups (and encrypts them if required) and store the backups on a remote or local server. ftplicity is a wrapper around duplicity which simplifies the use of an ftp server as backup destination.

I grabbed version 0.4.2 of duplicity and version 1.1.1 of ftplicity. Configuration is pretty straightforward (generate keys, specify ftp server, passwords, key ids and so on) and should not take too long if you follow the tutorial mentioned above.

And hey: my files were backed up on the first try. Problem started only when restoring them … it did not work. Duplicity would not bring back the files. Damn. What good is a backup if you can not restore the files (thanks Michael).

After a while of troubleshooting (increase log levels, dump ftplicity for now, backup to local disc) I found out that duplicity always created a full backup. Remembered me of Groundhog Day. It was then when I realised that the manifest files were empty and duplicity did not know that there is a existing backup at all (at least this is my interpretation of what happened).
So I tried the procedure on the simplificator.com servers. And there it worked. Backup AND restore. Not just sending files to the nirvana. Kind of annoying since I wasted a lot of time before.
Ok, lets cut a long story short: I got help from Lukas who fixed these problems in a second. These are the versions working fine for us on our Ubuntu boxes.

  • duplicity 0.4.1
  • ftplicity 1.1.1
  • python 2.4

Thanks again to Lukas!

Ubuntu Administration: Hosting multiple Websites with Apache2

Monday, August 20th, 2007

With Apache2, it seems to be generally suggested to have one file per site in the sites-available directory of the apache configuration. The main configuration (in apache2.conf) is then including symbolic links to these files:

PHP:
  1. # Include the virtual host configurations:
  2. Include /etc/apache2/sites-enabled/[^.#]*

So what do you do with virtual hosts?

My first try was starting each of the sites files with the following:

PHP:
  1. NameVirtualHost *:80
  2.  
  3. <virtualhost>
  4. ServerName www.simplificator.com
  5. ServerAdmin info@simplificator.com
  6. ServerAlias simplificator.com</virtualhost>

This does actually work, but complains in the logs, saying

PHP:
  1. [warn] NameVirtualHost *:80 has no VirtualHosts
  2. [warn] NameVirtualHost *:80 has no VirtualHosts

for the second and third domain. What's going on?

Most people on the web say stuff like 'change the *:80 to a _default_:80' or similar - focusing on tricking apache to believe it actually has several different ip addresses an no conflicts. Trial and error until it works! Sometimes this breaks connections from localhost (which is cruical for restful services and the like, so that's no minor issue). The apache documentation was too cryptic for me to help in any practical way. Seems one needs to understand the concept before you can understand the explanation of the concept.

It took me a while to figure it out. There should be one NameVirtualHost *:80 only (and maybe one for port 443 if you use https). Since people normally don't touch apache2.conf but each site file, they normally copy the header of these files and end up with multiple NameVirtualHost directives.

The solution:

Use the /etc/apache2/conf.d directory and put a file in there called NameVirtualHost, for example. Put the following in there:

PHP:
  1. NameVirtualHost *:80
  2. NameVirtualHost *:443

remove all the NameVirtualHost directives from your site configs in sites-available and use something like this:

PHP:
  1. <virtualhost>
  2. ServerName www.simplificator.com
  3. ServerAdmin info@simplificator.com
  4. ServerAlias simplificator.com</virtualhost>
  5. ...

The conf.d-file will be read exactly once. I guess everyone who has a running server which doesn't complain at reboot has this, so it's no magic at all. But you won't easily read about it.

I put this here because I had such a hard time figuring it out. Hope someone else has an easier time.