I have not blogged about until now, but I'm in Cáceres since last Thursday, where jordi and I came by car from Valencia to attend the DebConf 9.

I'm not doing any Debian work here, but I'm having a good time socializing meeting and talking with a lot of people and attending some of the talks and BOFs.

Yesterday we went to the Valle del Jerte for the Day Trip, where we did a short walk and got to Los Pilones, where we saw a lot of natural pools between the mountains where we swimmed (I loved a small cascade that was like a natural hydro massage system) and stayed there for a couple of hours until we had to go back to the bus to visit another natural pool on the village of Jerte, that time a big one built inside the river that was also very nice.

Anyway, what I wanted to say is that yesterday's Day Trip was another good example of how the Debian Project helps its users and developers; when we were walking back from the mountains to pick the bus we found Debian people on a cross road telling us what was the right way and after a little while we found a Debian Sign on the floor:

We followed the advice and we confirmed that it was a shortcut in our way down, obviously installed there by someone from the Debian Project.

On recent years I've only been in one or two free software related conferences per year, usually because I've been invited to go for a day or two and give a talk.

The truth is that my day to day activities don't leave me enough time to contribute or participate a little bit more in free software projects, but this year I decided (and negotiated) that I had to go to Debconf, as it is the best opportunity to go to a Debian conference that I'm going to have in the near future.

So this summer it is going to be a free software summer, the 3rd of July I'll be giving a talk at the Jornades de Programari Lliure in Barcelona and from the 23th to the 30th or 31th I'll be at Debconf 9 in Cáceres.

In Barcelona I will talk about building IT infrastructures using free software, explaining which programs I use, why I've choosen them and how I configure things depending on my needs and in Cáceres I will be just listening and exchanging gpg keys.

After my followup to the Tuesday post I've received some additional comments and I'm writing this entry to close the subject... ;)

One of the comments was from Gunnar to tell me that the followup setup was the same provided by the automatic partitioner of the Debian Installer since 2007.

I was unaware of that because until some weeks ago I never tried to install a system with encryption support and when I did it on my laptop I used the manual setup because I wanted to keep the MacOS X partitions.

Anyway my followup blog entry made sense anyway, as I just wanted to comment my thoughts about the advantages and disadvantages of each partitioning schema.

I also received a couple of messages proposing the use of three layers to keep the flexibility of the original setup and the simplicity of the second; the setup is as follows:

• Layer 1: use LVM on a physical volume,
• Layer 2: create a logical volume and format it as an encrypted volume,
• Layer 3: use LVM on top of the encrypted logical volume and put there the file systems that you want encrypted.

With the LVM at the lower level you get the advantages of my setup (mix encrypted and unencrypted partitions, the crypted volume can use multiple physical volumes, etc.) and the advantages of the second setup (only one key for all the encrypted file systems).

I believe that this setup is a little too much for a laptop, but can be a good option if you need encrypted file systems on a server.

Yesterday I received a mail message from a Debian user called Ekrem Erdem about my previous post, proposing a different partitioning schema that I found interesting.

The basic idea is to swap the order of the technologies, that is, use LVM on top of an encrypted partition instead of encrypting logical volumes.

I never thought about this schema because I always use LVM on servers and that is one of the fist things I setup (just after software RAID-1, if the machine has two hard drives); when I was evaluating how to setup my system for encryption I started with the LVM setup and never looked back.

The advantage of this setup is that there is only one pass phrase (the one used to unlock the encrypted partition, sda4 in my case), eliminating the need of derived keys (i. e. my swap setup) or key files (I use them to mount snapshots of the encrypted partition non interactively).

On the negative side I believe that this setup looses some flexibility:

• On my original model crypted and unencrypted partitions can coexist on the same volume group, while the new setup requires a different volume group for unencrypted volumes.

• If the user wants to have multiple partitions each one can use a different pass phrase or key file.

• If a logical volume is expanded through multiple physical volumes the new setup requires a key for each physical volume, while the original setup only needs one key.

Anyway if the plan is to encrypt all the file systems on a laptop the proposed setup is simpler and, IMHO, as safe as my configuration (remember that my keys are related).

I'm not going to change my setup now (it works great), but I'll probably try this one in the future if I need an encrypted setup on a different machine.

A couple of weeks ago I updated my Debian Sid setup on the MacBook to use disk encryption; this post is to document what I did for later reference.

The system was configured for dual booting Debian or Mac OS X using refit and grub2 as documented on the Debian Wiki; I don't use the Mac OS X system much, but I left it there to be able to test things and be able to answer questions of Mac OS X users when I have to.

The Debian installation was done using two primary partitions, one for swap (I used a partition to be able to suspend to disk without troubles) and an ext3 file system used as the root file system.

The plan was to use the Debian Installer to do the disk setup and recover the Sid installation from a backup once the encrypted setup was working OK.

Backup for later recovery

My first step was to install all the needed packages on the original system; basically I verified that I had the lvm2 and cryptsetup packages installed.

The second step was to backup the root file system; to do it I changed to run level 1 and copied the files to an external USB disk using rsync.

My third step was to boot into Mac OS X to reduce the space assigned to it; I had a lot of free space that I didn't plan to use with Mac OS X and I thought that this was the best occasion to reassign it to the Debian file system.

Encrypted Lenny installation

Now the machine was ready for the installer. As I formatted the system a couple of weeks ago I used a daily build of the Lenny Debian Installer, now that Lenny is out I would have used the official version.

I booted the installer and on the partition disk step I selected the manual method; I left sda1 and sda2 as they were (the Mac OS X installation uses them) and set up sda3 and sda4 as follows:

• sda3: 256 MB, use as ext3, mount point: /boot
• sda4: 86 GB, use as physical volume for LVM

Note that I decided to put /boot on a plain ext3 partition to be able to use grub2 as the boot loader (if we put the kernel on an LVM logical volume we need to use lilo as the boot loader).

Once sda4 was adjusted as LVM I entered on the LVM setup and created a LVM Volume Group (VG) with the name debian, using sda4 as the physical volume.

Once the VG was defined I created a couple of Logical Volumes (LV):

• root: 82 GB
• swap: 2 GB

I left some space unallocated to be able to create LVM snapshots (I use them to do backups, I'll post about it on the next days).

Once the LV were ready I finished with the LVM setup and went back to the partitioner to configure the Logical Volumes:

• debian-root: use as physicals volume for encryption
• debian-swap: use as pascal volume for encryption, encryption key: random

Once both encrypted volumes were ready I entered on the Configure the encrypted volumes menu and the installer formatted the volumes for encryption and asked for the debian-root pass phrase.

Back on the main partitioning menu I set up the debian-root_crypt encrypted volume:

• debian-root_crypt: use as ext3, mount point: /.

I didn't need to touch the debian-swap_crypt, it was configured automatically as swap because I choose a random encryption key.

At this point I was finished with the partitioning; to finish I installed a minimal system and rebooted to try the system.

As I had changed the disk layout I had to re-sync the partition tables from refit; once that was done I was able to boot from the newly installed system.

Setting up suspend to disk

I was using s2disk to suspend the system; to test if it still worked with the new setup I installed the uswsusp package and adjusted the resume device on the /etc/uswsusp.conf to /dev/mapper/debian-swap_crypt.

After my first try I noticed that the resume step failed with the encrypted swap partition because it was using a random key, which means that the swap contents are unrecoverable after a reboot.

Looking at the cryptsetup documentation I found that the solution was to use a derived key for the swap partition instead of a random one.

The command sequence was as follows:

# disable swap
swapoff -a
# close encrypted volume
cryptsetup luksClose debian-swap_crypt
# change the swap partition setup on the /etc/crypttab file
sed -e -i 's%^debian-swap.*%debian-swap_crypt /dev/mapper/debian-swap debian-root_crypt cipher=aes-cbc-essiv:sha256,size=256,swap,hash=sha256,keyscript=/lib/cryptsetup/scripts/decrypt_derived,swap%' /etc/crypttab
# open the encrypted volumes with the new setup
/etc/init.d/cryptdisks start
# enable swap
swapon -a
# update the initrd image
update-initramfs -u

After executing all those commands the suspend to disk system worked as expected.

Recovering the original system

If I were going to reinstall the system completely I would have finished here, but in my case I wanted to recover my original system setup (except the minimal changes required to use the encrypted passions, of course).

To recover my old installation I backed up some files (/etc/fstab, /etc/crypttab, /etc/uswsusp.conf and the current /boot contents to be able to boot in case of failure with my old kernel) from the current installation, after that I recovered all the files from the initial backup (except the ones just saved) using rsync again and regenerated the initrd images of my old kernels:

update-initramfs -u -k all

After that I rebooted and everything worked as on my original installation (except for the disk encryption, of course).