Caps Lock must be the second most useless key on my keyboard (what does Scroll Lock even do?) and one of the first things I usually do after installing a new Linux system is to rebind it to something useful, such as backspace. This is very easy to do (in X11 at least). Just call this script on login.

It is sometimes the case that an application will not allow you to paste in text, forcing you to write it out by hand (either because it is poorly written or because of perceived security risks). These instructions are the results of having to manually enter long and complex passwords for virtual Windows machines one time too many, and will show you how to bypass such restrictions using a simple script.

Dependencies

typeclipboard

#!/bin/sh#This script will type out the content of the Klipper clipboard as if the user had typed it themself.#Copy the content of the KDE clipboardto_write=$(qdbus org.kde.klipper /klipper getClipboardContents)
#Clear the clipboard. Uncomment this line if you will be copying anything sensitive.
#qdbus org.kde.klipper /klipper clearClipboardHistory
#Wait for one second to give the user time to release any keys that may have been pressed.
sleep 1
#Type out the content of the clipboard
xdotool type--clearmodifiers"$to_write"

Common problems

If the output does not match the content of the clipboard it is possible that xdotool is using the wrong keyboard layout. This can be fixed by adding ‘setxkbmap -layout LAYOUT’ to your shell profile, where LAYOUT is the keyboard layout you want (e.g. ‘se’ for Swedish).

Try not to press down any modifier keys (Ctrl, Shift, Alt, etc.) when running the script. With ‘–clearmodifiers’ xdotool will attempt to unset all modifiers, but this will not always work. The script will type out anything you give it as if you had typed it out yourself. This includes things like keyboard shortcuts. Strange and dangerous things can happen if you are not careful. The script will wait for one second before doing anything to give you time to take your hands of the keyboard.

Create a shortcut

To create a keyboard shortcut for the script in KDE4, go to ‘System Settings -> Shortcuts and Gestures -> Custom Shortcuts’, then ‘Edit -> New -> Command/URL’. Under ‘Trigger’, select the keyboard shortcut you want, and under ‘Action’, give it the path to the script.

Pasting passwords to Windows machines running in VirtualBox

This was the reason why I wrote the script in the first place. To paste a password, simply copy it and click on the Windows password field, then press the host key (right Ctrl) so that VirtualBox does not capture the keyboard, followed by the keyboard shortcut you chose. The script will then type out the password as if you had typed it out yourself, bypassing the disabled copy/paste functionality.

This guide will show how to set up a simple backup system using Duply, that creates encrypted incremental backups of client data and stores them both on a central backup server and on a secondary offsite server. All backups are encrypted by the clients using GPG so that no data could be compromised if someone gain access to the backup servers. The guide assume that Debian is used, but the instructions should work on any Linux distribution with only minor changes.

Duply backup archtecture

The guide provide step-by-step instructions for setting up a backup server, a secondary server, and a single client. The following names are used to identify them.

Client: client.example.com

Backup server: server.example.com

Offsite server: offsite.example.com

Duply/Duplicity

Duply is a front end to the Duplicity backup application that give you a more user friendly interface and simplifies common tasks. Duplicity isn’t the most powerful backup application available, but it is a very good choice when you don’t need the functionality of, for example, Amanda or Bacula. The strength of Duplicity is its simplicity and ease of use, particularly when combined with Duply. You can, with a few commands and two simple configuration files, create a complete backup schedule with client side encryption.

Another advantage of using Duplicity is that everything is handled by the client. All you need from the server is the ability to store files on it. Other, more advanced, backup solutions typically use some form of backup and scheduling daemon on the server. With Duplicity it is enough if you have remote SSH access to an account on the server; everything else is handled client side. This is particularly useful when backing up desktops and laptops that are not always online.

There are of course disadvantages to using Duplicity. Since Duplicity doesn’t use a central server for managing backups it will not scale well. Each client is responsible for what to back up and when to back it up, and must be configured and managed separately. This makes Duplicity an excellent choice for small networks where there are only a handful of machines to back up, but for larger networks you may want to use something else.

Step 1: Install Duply (client.example.com)

First install Duply and Duplicity on the client.

# apt-get install duply

It is possible to do everything in this guide with only Duplicity. Duply simply provides an interface for Duplicity that is easier to work with. If, for some reason, you don’t want to use Duply you could instead use Duplicity directly.

Step 2: Add a backup folder on the server (server.example.com)

You need an account on the server to store backups on. You could use a single account for backing up several client machines, but I would recommend that you create separate accounts for each client and only give them a restricted shell. This will limit the potential damage that could be done by compromised or misbehaving clients.

Step 2.1: Install RSSH

If you have not done so already, first install RSSH. RSSH provides a restricted shell that only allow a user to perform actions needed for SFTP, SCP and rsync.

# apt-get install rssh

By default RSSH will not allow rsync to be used. We will need this later, so edit ‘/etc/rssh’ and enable rsync access.

Step 2.2: Create a client user account

Next you need to create a user account and backup folder for the client. How you do this is up to you and your particular needs (and paranoia). I will give two examples of how you could set this up. By simply storing backups in the home directory of the user, and a slightly more complex method that should work better if you are backing up several clients.

Simple solution

A simple solution is to give each client a user account on the server and let each client store their backups in their home directories. This is easy to set up, but if you wish to copy all backups to a secondary offsite server your will have to either do this as root, or give the offsite server access to each client account separately.

When creating client user accounts on the server I recommend disabling password based login so that only key based SSH authentication is allowed, and to only give clients restricted shell access to the server.

A warning should be made here. If you have more than one user on the server and you are using the default umask, then other users will (probably) have read access to your backups. This should not be a problem if the backups are encrypted, otherwise you may want to at the very least change the umask, or use the advanced solution.

Advanced solution

A somewhat more advanced solution is to give each client a separate user account on the server, but store all backups in a central backup folder and use ACLs to give a single user (in this case backup-duply) read access to all backups. This requires a few more steps, but makes it possible to copy all backups to a secondary server using only the one backup account.

First create the backup account.

# adduser backup-duply --disabled-password --shell /usr/bin/rssh

Create a backup folder.

# mkdir /var/backup

Use ACLs to give backup-duply read access to the backup folder and all subfolders. This will be inherited by new folders and backups when they are created.

Step 3: Set up SSH access

You will need to give the client SSH access to the new user account on the server.

If the client does not already have an SSH key, you must first create one.

$ ssh-keygen

Save it in the default location (~/.ssh/id_rsa). You could also create a separate set of keys for Duply, but that will not be covered by this guide. Since the key will be used non-interactively, you should give it an empty passphrase. This will create two keys. The private key id_rsa, and the public key id_rsa.pub. You must always keep the private key secret!

The next step is to add the public key to the list of authorized keys on the client’s user account on the server.

On the server, create the file ‘/home/backup-client/.ssh/authorized_keys’ if it does not already exist.

Next, copy the content of the client’s public key (id_rsa.pub) to the authorized_keys file on the server.

Finally, you must add the server’s public key (/etc/ssh/ssh_host_rsa_key.pub) to the client’s list of known hosts (~/.ssh/known_hosts). You can do this manually or, alternatively, if you try to connect to the server it will offer to do this for you. Adding the key manually is more secure and is the recommended way to do this if you do not trust the network in-between the client and the server. Until the keys are in place and the server and client can authenticate each other it is possible to perform a man-in-the-middle attack.

Step 4: Create GPG keys (client.example.com)

If you want to encrypt or sign your backups you will need a GPG key. If you do not already have a key the next step will be to create one.

To create a GPG key use the command:

$ gpg --gen-key

Then choose:

(1) RSA and RSA (default)

You can use the defaults for the rest if you wish, but choose a strong passphrase. I recommend you use some form of password generator to create it. Make a copy of the passphrase and store it somewhere safe. You should also create a backup of ‘~/.gnupg/’. You will not be able to decrypt your backups if you lose them.

Here, C8B4OI9S is the name of the main signing key, and we have one subkey JF5PWSHP for encryption. These keys are enough to create encrypted and signed backups.

Step 5: Create a backup profile (client.example.com)

It is now time to set up a Duply backup profile. The following command will create a new profile named “backup_all”.

$ duply backup_all create

This will create a folder ‘~/.duply/backup_all/’, where all relevant configuration files are stored. The backup schedule and other options are listed in ‘~/.duply/backup_all/conf’. The following is a sample configuration file using the GPG keys created earlier.

#GPG encryption keyGPG_KEYS_ENC='JF5PWSHP'#GPG signing keyGPG_KEY_SIGN='C8B4OI9S'#GPG passpraseGPG_PW='YOUR_PASSPHRASE'GPG_PW_SIGN='YOUR_PASSPHRASE'#Compress backups using bzipGPG_OPTS="--compress-algo=bzip2 --bzip2-compress-level=9"#Send backups to server.example.com using sftp over SSH. Uncomment the one matching your setup.#Simple solution. Store backups in ~/backup#TARGET='sftp://[email protected]/backup/'#Advanced solution. Store backups in /var/backup/#TARGET='sftp://[email protected]//var/backup/backup-client/'# base directory to back upSOURCE='/'# Time frame for old backups to keep, Used for the "purge" command.# see duplicity man page, chapter TIME_FORMATS)# defaults to 1M, if not setMAX_AGE=6M
# Number of full backups to keep. Used for the "purge-full" command.# See duplicity man page, action "remove-all-but-n-full".# defaults to 1, if not setMAX_FULL_BACKUPS=3# activates duplicity --full-if-older-than option (since duplicity v0.4.4.RC3)# forces a full backup if last full backup reaches a specified age, for the# format of MAX_FULLBKP_AGE see duplicity man page, chapter TIME_FORMATS# Uncomment the following two lines to enable this setting.MAX_FULLBKP_AGE=1M
DUPL_PARAMS="$DUPL_PARAMS --full-if-older-than $MAX_FULLBKP_AGE "# verbosity of output (error 0, warning 1-2, notice 3-4, info 5-8, debug 9)# default is 4, if not setVERBOSITY=5# temporary file space. at least the size of the biggest file in backup# for a successful restoration process. (default is '/tmp', if not set)TEMP_DIR=/tmp
# more duplicity command line options can be added in the following way# don't forget to leave a separating space char at the endDUPL_PARAMS="$DUPL_PARAMS --extra-clean --num-retries 1"

Next, you will have to create an exclude file ‘~/.duply/backup_all/exclude’. This file tells Duplicity which files to back up, and which to ignore.

The following is a sample exclude file that will back up all files in ‘/etc’, ‘/home’ and ‘/var/www’, except for temporary files.

- **/*~
+ /etc
+ /home
+ /var/www
- **

The format is very simple. Duplicity will check each file against the rules in this file, starting from the top, until it finds a rule that matches. If the rule is preceded by a ‘+’ the file will be backed up, and if it is preceded by a ‘-‘ it will be ignored. For example, the file ‘/etc/resolv.conf’ will match the rule ‘+ /etc’ and be backed up, while ‘/etc/resolv.conf~’ will match the rule ‘- **/*~’ and be ignored. The last rule ‘- **’ tells duplicity to ignore all files that didn’t match an earlier rule.

To test that everything is working, run:

$ duply backup_all backup

If this finishes without errors then all that is left to do is to create a cron job. You should also make a backup of ‘~/.duply/’. You will need these configurations files when restoring backups.

Step 6: Copy backups to an offsite server (offsite.example.com)

You should always have at least one additional copy of all backups stored offsite. A simple way to this is to use rsync to copy all backup data to a secondary server. This can be done in several ways depending on which solution you chose in step 2, and on your own requirements. I will give two examples where the offsite server connects to and pulls the backup data from the primary server. You can also do the opposite and let the primary server connect to the offsite server and push data to it.

Simple solution

If you followed the earlier steps for the simple solution you need to give the offsite server SSH access to each client account on the primary server. Assuming that the previous steps have been taken to give the client SSH access to the server, all you need do is copy the contents of ‘~/.ssh/id_rsa.pub’ from the offsite server to the authorized_keys files in each client account on the primary server.

Next, add the following cron job to the offsite server for each client account.

Before adding this line to crontab you should try the command with ‘–dry-run -v’ enabled to see that it does what you intended. You may also want to leave out ‘–delete’ if you don’t want old backups to be removed from the offsite server once they have been deleted from the primary server.

This solution is quite simple to implement when you only have one or two machines backed up to separate user accounts on the server, but it quickly becomes impractical since you will have to remember to update crontab each time you add or remove a client. This could also create a potential security risk since the offsite server will have write permissions for the backups on the primary server. If the offsite server were to be compromised it could potentially delete backups from the primary server.

Advanced solution

If you followed the earlier steps for the advanced solution you need to give the offsite server SSH access to the backup-duply account. This is done in the same way as in the simple solution described above.

Before adding this line to crontab you should try the command with ‘–dry-run -v’ enabled to see that it does what you intended. You may also want to leave out ‘–delete’ if you don’t want old backups to be removed from the offsite server once they have been deleted from the primary server.

This solution will create a copy of all backups for all clients with a single command. It also only gives the offsite server read permission for the backups on the primary server. Even if the offsite server were to be compromised the backups on the primary server would be safe.

With this post I suppose that my new website/blog has been officially started. I have not yet decided if I’m actually going to use it as a blog or not. This thing is running WordPress after all, and blogging is what it was made for, but for now I will use it as a convenient place to put any interesting code or projects I make.

I have already uploaded the latest version of the P2P/reputation simulator I wrote for my master’s thesis. I may upload other things as well as soon as I take the time to go through my old projects and clean them up a bit.