We’re using ssh with public keys quite often. One thing I always missed on OS X was the ssh-copy-id script. Its job is to take the public key of the user running the script and helping to copy that over to a server, so that the user doesn’t have to enter the password all the time. It’s a great time saver and allows you to secure the accounts with harder passwords (instead of using the same password for all accounts, like you do).

Github has a nice guide how you can create a public key, in case you don’t have one. Now, grab a copy of the ssh-copy-id script from the openssh package (for example from here). Copy it into /usr/local/bin and chmod it:

sudo cp ssh-copy-id.sh /usr/local/bin/ssh-copy-id
sudo chmod a+x /usr/local/bin/ssh-copy-id

Then you can use the following command (you’ll have to enter the password one last time)

ssh-copy-id user@machine.com

The thing tells you to check which keys you copied, so have a look at .ssh/authorized_keys after the act. Do that, it’s wise. And change your silly password into something more complicated.

By the way – we have a piece of software blocking all IPs which try to log in using passwords more than five times in a row. And it happens dozens of time a day.

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!

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:

So what do you do with virtual hosts?

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

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

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:

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

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.