Nevertheless you, as I, want to try and code with Rails 2, right? Well, this is how I installed it in my Kubuntu box (should work the same for any Ubuntu and Debian derivate as well as others). I’ve decided to install everything on /opt/rails. I like to keep more-or-less self-contained directories in /opt. So I started with:

$ sudo mkdir /opt/rails
$ sudo chown pupeno:pupeno /opt/rails

and that’s the last time I’ll ever use root access in this document, and that’s the way I like it. Another important detail is that I’ll keep all the environment entirely optional. All you’ll do here will be in a separate directory and will not interfere with the rest of your computer. Actually, to use it, you’ll have to load a file, which means, you control when you are entering the Rails 2 environment. In ~/bin/rails.sh I put:

#!/usr/bin/env bash

RAILS_PREFIX=/opt/rails

export PATH="$RAILS_PREFIX/bin:$RAILS_PREFIX/lib/ruby/gems/1.8/bin/:$PATH"
export MANPATH="$RAILS_PREFIX/share/man:$MANPATH"
export LD_LIBRARY_PATH="$RAILS_PREFIX/lib:$LD_LIBRARY_PATH"

PS1="[rails] $PS1"

Ruby

I started installing Ruby. Maybe this wasn’t needed, but I wanted a really clean and separated environment (after downloading and unpacking):

$ cd ruby-1.8.6-p111/
$ ./configure --prefix=/opt/rails/
$ make
$ make install

Time to enter the Rails 2 environment:

$ source ~/bin/rails.sh
[rails] $ which ruby
/opt/rails/bin/ruby
[rails] $ ruby --version
ruby 1.8.6 (2007-09-24 patchlevel 111) [i686-linux]

Good! To have a nice irb and actually be able to run Rails’ console, we also need the readline gem:

[rails] # cd ext/readline
[rails] # ruby extconf.rb
[rails] # make
[rails] # make install

Gems

Installing rubygems is easy as well, after downloading and unpacking, be sure to be in the rails 2 environment and run:

[rails] $ cd rubygems-0.9.5/
[rails] $ ruby setup.rb
...
Removing old RubyGems RDoc and ri...
Installing rubygems-0.9.5 ri
into /opt/rails//lib/ruby/gems/1.8/doc/rubygems-0.9.5/ri...
Installing rubygems-0.9.5 rdoc
into /opt/rails//lib/ruby/gems/1.8/doc/rubygems-0.9.5/rdoc...
As of RubyGems 0.8.0, library stubs are no longer needed.
Searching $LOAD_PATH for stubs to optionally delete (may take a while)...
...done.
No library stubs found.
[rails]  $ which gem
/opt/rails/bin/gem
[rails]  $ gem --version
0.9.5

Good!

Rails

Just as explained on the Rails web site:

[rails]  $ gem install rails
Bulk updating Gem source index for: http://gems.rubyforge.org
ERROR:  While executing gem ... (Gem::RemoteFetcher::FetchError)
OpenURI::HTTPError: 404 Not Found reading

http://gems.rubyforge.org/gems/activesupport-2.0.1.gem

Ooops, I’ve got some of those. Just try again:

[rails]  $ gem install rails
Successfully installed actionmailer-2.0.1
Successfully installed activeresource-2.0.1
Successfully installed rails-2.0.1
3 gems installed
Installing ri documentation for actionmailer-2.0.1...
Installing ri documentation for activeresource-2.0.1...
Installing RDoc documentation for actionmailer-2.0.1...
Installing RDoc documentation for activeresource-2.0.1...

And that’s it, you are ready to rail! (as you can see, all the magic is in that little rails.sh file)

Update 2007-12-31: include installation of readline.

Motivation

Every day we put more and more personal information on our computers, and our computers become lighter, smaller, more mobile. In other words, the importance of the information gets higher and the possibility of being loosed or stolen gets higher as well.

I think that if anyone gets a-hold of the information in my personal computer (s)he’d be able to impersonate me and make my life a mess. That’s why I like keeping all my information encrypted. That is, I have a separate partition for /home and it is encrypted.

The level of security for this scheme is not very high and if you are a real paranoid you should be reading some other tutorials. I am using just a pass-phrase for the encryption so I am susceptible to dictionary attacks, my swap is not encrypted, so some personal information would be available there. But that’s OK. I am not trying to protect from the people with enough sophistication to perform the needed operations to retrieve that information. Those are not many and they have other means.

My goal is to protect from the regular thieve or from loosing it… so I would mourn for some money being lost but I will sleep well at night.

Disclaimer: the information will be encrypted, you’ll be able to access it with a key: a pass-phrase. If you loose it, you won’t be able to access than information again, so, be careful and make backups.

Installation

You should install the operating system as you always do with a little detail: create the root partition, the swap partition and the home partition. But don’t assign any filesystem to the home partition, do not make or format it and do not set it as home.

After you did that you should be booting into a fresh system. Be sure not to store any sensitive information now, because it’ll be accessible to anyone. Some thinks to take care, if you use a browser or some instant messaging client, do not make them save the password, if you can avoid typing the passwords at all, that will be better.

Once you got pass that you’ll need two packages: cryptsetup and libpam-mount. You can install them with a command like:

aptitude install cryptsetup libpam-mount

During installation, limpam-mount request to convert the previous configuration. As we don’t really have a previous configuration, I’m not sure what it’s going to convert so I just choose “No” (the default) and let it install a fresh configuration.

Partitioning

The encryption we are going to use works like this. Linux puts a layer around a device and creates a new virtual device. Whatever is written to this new virtual device is written to the real device but encrypted. All this works at a very low level and it is called mapping. There are other kind of mappings (to perform other operations than encrypting… think for example as creating volumes of various partitions so they’d be seen as one).

To create the mapping run:

sudo modprobe dm-crypt

sudo cryptsetup --verbose --verify-passphrase luksFormat /dev/sda6

replacing /dev/sda6 with your particular (real) device.

A bit more about that command. cryptsetup is a program to create this encryption mappings. –-verbose is there because I like to see a lot of useless data and feel more geeky. –-verify-passphrase is there to be asked twice for the pass-phrase, so we don’t insert a wrong pass-phrase by accident. luksFormat is the action. luks is a new system that lets us have more than one password, change passwords, add passwords, etc to some encrypted device. Very handy.A complete execution of that command will look like:

sudo cryptsetup --verbose --verify-passphrase luksFormat /dev/sda6

WARNING!
========
This will overwrite data on /dev/sda6 irrevocably.

Are you sure? (Type uppercase yes): YES
Enter LUKS passphrase:
Verify passphrase:
Command successful.

The new partition

This new system, luks, also let us inspect what is in a luks-formatted partition. It works like this:

sudo cryptsetup luksDump /dev/sda6
LUKS header information for /dev/sda6

Version:       	1
Cipher name:   	aes
Cipher mode:   	cbc-essiv:sha256
Hash spec:     	sha1
Payload offset:	1032
MK bits:       	128
MK digest:     	ff c3 22 a1 d1 fe 5e e4 e3 37 26 a7 8e 93 43 22 fa 83 c5 91
MK salt:       	27 59 46 c5 f2 21 5a 93 46 eb 2a cf 80 f1 46 95
               	b6 05 79 02 55 a4 49 33 87 d1 25 ae 49 74 40 b6
MK iterations: 	10
UUID:          	819cf83a-7c9b-49b8-9b74-e0d952aa1234

Key Slot 0: ENABLED
	Iterations:         	208350
	Salt:               	be 31 c7 e3 c9 a8 d5 37 09 12 34 e2 4a 3f a3 85
	                      	e0 fd bc 1e e4 3a fb d6 70 7c 7f 12 34 1a 6d 8e 43
	Key material offset:	8
	AF stripes:            	4000
Key Slot 1: DISABLED
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED

Lot’s of nice information, don’t you feel super-geek ? You can see there that you have 8 spaces for pass-phrases, you have 8 slots of which you are using one, the 0.

To be able to access the encrypted partition you have to open it… and to do it you’ll need a key of course (your pass-phrase). We’ll see the mappings on /dev/mapper/, which should be empty by now (except for a control file… I wouldn’t name a mapping control, just in case):

ls /dev/mapper/
control

Ok! Now open it:

sudo cryptsetup luksOpen /dev/sda6 home
Enter LUKS passphrase:
key slot 0 unlocked.
Command successful.

Great! We have opened it. The last parameter, “home”, is the name of the mapping. Let’s take a look at the mappings:

ls /dev/mapper/
control  home

Good. This device file is like a partition itself. So, we’ll make a file-system in there in the same way you’d make it in sda6 (from now on, don’t do anything with sda6 except opening and other luks operations, your partition is /dev/mapper/home now). In my case I’ve picked ReiserFS, but you can use whatever you want:

sudo mkfs.reiserfs -l home /dev/mapper/home
...lot's of geeky output...
ReiserFS is successfully created on /dev/mapper/home.

and we are done. We can mount it:

sudo mount /dev/mapper/home /media

copy the current data (the home of a user and a couple of files):

sudo cp -a /home/* /media/
cp: ne povas trovi stato-informon pri '/home/pupeno/.gvfs': Permeso rifuzita

If you don’t speak the international language, that mean: “cp: cannot stat `/home/pupeno/.gvfs’: Permission denied”. Everything seems to be OK anyway. Un-mount it:

sudo umount /media/

and close it:

sudo cryptsetup luksClose home

Automagically mounting

There are various ways to open and mount the encrypted file-system but after trying many different ones, this is the best one from my point of view. I like that it is not intrusive: when you log in, your user password will be used to open the file-system and it’ll be mounted automatically. Of course, then, the password of your user should match the pass-phrase in at least one of the slots of the encrypted device.

You need to modify /etc/pam.d/common-auth adding, at the end:

@include common-pammount

And /etc/pam.d/common-session to add that same line.

In /etc/security/pam_mount.conf.xml, around line 107 you have a list of “Linux encrypted home directory examples”, since what we are going to do is related to that it makes sense to put these lines after that comment (around line 183):

Of course replace “pupeno” with your username and “/dev/sda6″ with your device. And that is the line that will make the magical mount happen.

Now just try it. It is very simple, log out, log in again and that’s it. You should have you newly super-encrypted home partition mounted. To check it out issue a mount command and among a huge amount of cryptic information you should see:

/dev/mapper/_dev_sda6 on /home type reiserfs (rw)

You can also list the files on /dev/mapper to find the _dev_sda6 mapping.

And that’s it, it wasn’t so hard, was it ?

More users, more pass-phrases

If there are more users add more lines to /etc/security/pam_mount.conf.xml, I haven’t tested it but it should work. Also just add more pass-phrases to the device using cryptsetup in this way:

sudo cryptsetup luksAddKey /dev/sda6

It’ll ask you for a current pass-phrase as well. This is also useful if you are changing pass-phrases, while you work on remembering the new one, don’t delete the old one, so if you forget the new one you should still be able to access your information with the old one. After you are confident of the new one, you can delete the old one with:

sudo cryptsetup luksDelKey /dev/sda6 0

where “0″ is the slot where you have your old pass-phrase (hint: use luksDump). And here I want to remind you that if you lost the password you won’t be able to access the information. There’s no password recovery here: it is gone, forever, as scrambled, processed and destroyed as the dinner of Tuesday of the last week. Be very careful and always make backups.

Motivation

As we put more and more personal information on our computers or computers become lighter, small, more mobile. In other words, the importance of the information gets higher and the possibility of being loosed or stolen gets higher as well.

I think that if anyone gets a-hold of the information in my notebook (s)he’d be able to impersonate me and make my life a mess. That’s why I like keeping all my information encrypted. That is, I have a separate partition for /home and it is encrypted.

The level of security is not high and if you are a real paranoid you should be reading some other tutorials. I am using just a pass-phrase for the encryption so I am susceptible to dictionary attacks, my swap is not encrypted, so some personal information would be available there. But that’s Ok. I am not trying to protect from the people with enough sophistication to perform the needed operations to retrieve that information. And if the thing becomes really nasty I bet people can find other ways to access my information. My goal is to protect from the regular thieve or from loosing it… so I will mourn for some dollars being lost but I will sleep well at night.

Disclaimer: the information will be encrypted, you’ll be able to access it with a key: a pass-phrase. If you loose it, you won’t be able to access than information again, so, be careful.

Installation

You should install the operating system as you always do with a little detail: create the root partition, the swap partition but not the home partition. Leave some space for the home partition, we’ll create it latter.

After you did that you should be booting into a fresh system. Be sure not to store any sensitive information now, because it’ll be open to attacks. Some thinks to take care, if you use a browser or some instant messaging client, do not make them save the password, if you can avoid typing the passwords at all, that will be better.

Once you got pass that you’ll need two packages (in Ubuntu and Kubuntu, exactly this, in Debian probably too, in others you’ll have to figure it out; actually, this applies to all the document so I won’t repeat it again): cryptsetup and libpam-mount. You can install them with a command like:

aptitude install cryptsetup libpam-mount

Partitioning

Create the partition that will be your home partition. Do it in whatever way you prefer, I’ve personally use cfdisk a lot, but you can also use fdisk or any other partitioning tool. After that to ensure that the partition table is written and read by Linux reboot. Avoiding rebooting might not cause any problem or it may cause weird problems with error messages that are hard to understand and that made me loose an hour or so. So, be safe and reboot.

The encryption we are going to use works like this. Linux puts a layer around a device and creates a new virtual device. Whatever is written to this new virtual device is written to the real device but encrypted. All this works at a very low level and it is called mapping. There are other kind of mappings (to perform other operations than encrypting… think for example as creating volumes of various partitions so they’d be seen as one).

To create the mapping run:

cryptsetup --verbose --verify-passphrase luksFormat /dev/sda3

replacing /dev/sda3 with your particular (real) device. In my case sda1 is root and sda2 is swap. One important piece of advice here would be putting random information on /dev/sda3 so it is harder to guess what’s in there. I haven’t done it because I was working over some other encrypted partition which was created over random data… enough randomness for me. If you are working in a new or blank this putting the random data might be important. Using your favorite search-engine you can find how to do it in 30 seconds.

A bit more about that command. cryptsetup is a program to create this encryption mappings. –verbose is because we like to see a lot of useless data and feel more geeky. –verify-passphrase is to be asked twice for the pass-phrase, so we don’t insert a wrong pass-phrase by accident. luksFormat is the action. luks is a new system that lets us have more than one password, change passwords, add passwords, etc to some encrypted device. Very handy.

Update: I’ve recently installed Kubuntu in a MacBook Pro and I’ve had to modprobe aes (and possible modprobe dm-crypt too) before being able to run the following command line succesfuly, otherwise I’ve got this message:

Failed to setup dm-crypt key mapping.
Check kernel for support for the aes-cbc-essiv:sha256 cipher spec and verify that /dev/sda5 contains at least 133 sectors.
Failed to write to key storage.
Command failed.

A complete execution of that command will look like:

WARNING!
========
This will overwrite data on /dev/sda3 irrevocably.

Are you sure? (Type uppercase yes): YES
Enter LUKS passphrase:
Verify passphrase:
Command successful.
root@pulab:~#

The new partition

This new system, luks, also let us inspect what is in a luks-formatted partition. It works like this:

root@pulab:~# cryptsetup luksDump /dev/sda3
LUKS header information for /dev/sda3

Version:        1
Cipher name:    aes
Cipher mode:    cbc-essiv:sha256
Hash spec:      sha1
Payload offset: 1032
MK bits:        128
MK digest:      65 d9 47 47 f0 74 5c ad ae 79 03 6c c9 11 4d 56 b2 11 78 90
MK salt:        19 d7 3b c6 04 2d ee e1 77 c0 4b f1 ac e1 3a 21
                ce 02 10 9a c5 f7 5a b7 fd f5 d4 96 96 6d 79 0d
MK iterations:  10
UUID:           bf5ca0c3-a68f-4544-8840-ba2p2af98918

Key Slot 0: ENABLED
        Iterations:             70156
        Salt:                   08 e1 75 0e d1 1b 92 d1 f1 5f bd 50 9c ec a0 a2
                                b9 ea f8 da 1a 62 5d 4b 15 f3 4c a3 f3 49 12 83
        Key material offset:    8
        AF stripes:             4000
Key Slot 1: DISABLED
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED

Lot’s of nice information, don’t you feel super-geek ? You can see there that you have 8 spaces for pass-phrases, you have 8 slots of which you are using one, the 0.

To be able to access the encrypted partition you have to open it… and to do it you’ll need a key of course (your pass-phrase). We’ll see the mappings on /dev/mapper/, which should be empty by now (except for a control file… I wouldn’t name a mapping control, just in case):

root@pulab:~# ls /dev/mapper/
control

Ok! Now open it:

root@pulab:~# cryptsetup luksOpen /dev/sda3 home
Enter LUKS passphrase:
key slot 0 unlocked.
Command successful.

Great! We have opened it. The last parameter, “home”, is the name of the mapping. Let’s take a look at the mappings:

root@pulab:~# ls /dev/mapper/
control  home

Good. This device file is like a partition itself. So, we’ll make a file-system in there in the same way you’d make it in sda3 (from now on, don’t do anything with sda3 except opening and other luks operations, your partition is /dev/mapper/home now). In my case I’ve picked reiserfs, but you can use whatever you want:

root@pulab:~# mkfs.reiserfs -l home /dev/mapper/home
.
lot's of geeky output
.
root@pulab:~#

and we are done. We can mount it:

root@pulab:~# mount /dev/mapper/home /media/

copy the current data (the home of a user and a couple of files):

root@pulab:~# cp -a /home/* /media/

un-mount it:

root@pulab:~# umount /media/

and close it:

cryptsetup luksClose home

Automagically mounting

There are various ways to open and mount the encrypted file-system but after trying many different ones, this is the best one from my point of view. I like that it is not intrusive: when you log in, your user password will be used to open the file-system and it’ll be mounted automatically. Of course then the password of your user should match the pass-phrase in some of the slots of the encrypted device.

You need to modify /etc/pam.d/common-auth adding, at the end:

@include common-pammount

And /etc/pam.d/common-session to add that same line:

@include common-pammount

In /etc/security/pam_mount.conf, around line 174 you have a list of “Linux encrypted home directory examples”, since what we are going to do is related to that it makes sense to put this line:

volume pupeno crypt - /dev/sda3 /home cipher=aes - -

there changing “pupeno” with your username and “/dev/sda3″ with your device. And that is the line that will make the magical mount happen.

Now just try it. It is very simple, log out, log in again and that’s it. You should have you newly super-encrypted home partition mounted. To check it out issue a mount command and among a huge amount of cryptic information you should see:

/dev/mapper/_dev_sda3 on /home type reiserfs (rw)

You can also list the files on /dev/mapper to find the _dev_sda3 mapping.

And that’s it, it wasn’t so hard, was it ?

More users, more pass-phrases

If there are more users add more lines to /etc/security/pam_mount.conf, I haven’t tested it but it should work. Also just add more passphrases to the device using cryptsetup in this way:

cryptsetup luksAddKey /dev/sda3

It’ll ask you for a current pass-phrase as well. This is also useful if you are changing pass-phrases, while you work on remembering the new one, don’t delete the old one, so if you forget the new one you should still be able to access your information with the old one. After you are confident of the new one, you can delete the old one with:

cryptsetup luksDelKey /dev/sda3 0

where “0″ is the slot where you have your old pass-phrase (hint: use luksDump). And here I want to remind you that if you lost the password you won’t be able to access the information. There’s no password recovery here: it is gone, forever, as scrambled, processed and destroyed as the dinner of Tuesday of the last week. Be very careful and always make backups.

Comments on the original blog

michuk Says:

Two more articles describing the same:
* http://polishlinux.org/howtos/truecrypt-howto/
* http://polishlinux.org/howtos/encrypted-home-partition-in-linux/

June 11th, 2007 at 5:47

Motivation

As we put more and more personal information on our computers or computers become lighter, small, more mobile. In other words, the importance of the information gets higher and the possibility of being loosed or stolen gets higher as well.

I think that if anyone gets a-hold of the information in my notebook (s)he’d be able to impersonate me and make my life a mess. That’s why I like keeping all my information encrypted. That is, I have a separate partition for /home and it is encrypted.

The level of security is not high and if you are a real paranoid you should be reading some other tutorials. I am using just a pass-phrase for the encryption so I am susceptible to dictionary attacks, my swap is not encrypted, so some personal information would be available there. But that’s Ok. I am not trying to protect from the people with enough sophistication to perform the needed operations to retrieve that information. And if the thing becomes really nasty I bet people can find other ways to access my information. My goal is to protect from the regular thieve or from loosing it… so I will mourn for some dollars being lost but I will sleep well at night.

Disclaimer: the information will be encrypted, you’ll be able to access it with a key: a pass-phrase. If you loose it, you won’t be able to access than information again, so, be careful.

Installation

You should install the operating system as you always do with a little detail: create the root partition, the swap partition but not the home partition. Leave some space for the home partition, we’ll create it latter.

After you did that you should be booting into a fresh system. Be sure not to store any sensitive information now, because it’ll be open to attacks. Some thinks to take care, if you use a browser or some instant messaging client, do not make them save the password, if you can avoid typing the passwords at all, that will be better.

Once you got pass that you’ll need two packages (in Ubuntu and Kubuntu, exactly this, in Debian probably too, in others you’ll have to figure it out; actually, this applies to all the document so I won’t repeat it again): cryptsetup and libpam-mount. You can install them with a command like:

aptitude install cryptsetup libpam-mount

Partitioning

Create the partition that will be your home partition. Do it in whatever way you prefer, I’ve personally use cfdisk a lot, but you can also use fdisk or any other partitioning tool. After that to ensure that the partition table is written and read by Linux reboot. Avoiding rebooting might not cause any problem or it may cause weird problems with error messages that are hard to understand and that made me loose an hour or so. So, be safe and reboot.

The encryption we are going to use works like this. Linux puts a layer around a device and creates a new virtual device. Whatever is written to this new virtual device is written to the real device but encrypted. All this works at a very low level and it is called mapping. There are other kind of mappings (to perform other operations than encrypting… think for example as creating volumes of various partitions so they’d be seen as one).

To create the mapping run:

cryptsetup --verbose --verify-passphrase luksFormat /dev/hda3

replacing /dev/hda with your particular (real) device. In my case hda1 is root and hda2 is swap. One important piece of advice here would be putting random information on /dev/hda3 so it is harder to guess what’s in there. I haven’t done it because I was working over some other encrypted partition which was created over random data… enough randomness for me. If you are working in a new or blank this putting the random data might be important. Using your favorite search-engine you can find how to do it in 30 seconds.

A bit more about that command. cryptsetup is a program to create this encryption mappings. –verbose is because we like to see a lot of useless data and feel more geeky. –verify-passphrase is to be asked twice for the pass-phrase, so we don’t insert a wrong pass-phrase by accident. luksFormat is the action. luks is a new system that lets us have more than one password, change passwords, add passwords, etc to some encrypted device. Very handy.

A complete execution of that command will look like:

WARNING!
========
This will overwrite data on /dev/hda3 irrevocably.

Are you sure? (Type uppercase yes): YES
Enter LUKS passphrase:
Verify passphrase:
Command successful.
root@pulab:~#

The new partition

This new system, luks, also let us inspect what is in a luks-formatted partition. It works like this:

root@pulab:~# cryptsetup luksDump /dev/hda3
LUKS header information for /dev/hda3

Version: 1
Cipher name: aes
Cipher mode: cbc-essiv:sha256
Hash spec: sha1
Payload offset: 1032
MK bits: 128
MK digest: 65 d9 47 47 f0 74 5c ad ae 79 03 6c c9 11 4d 56 b2 11 78 90
MK salt: 19 d7 3b c6 04 2d ee e1 77 c0 4b f1 ac e1 3a 21
ce 02 10 9a c5 f7 5a b7 fd f5 d4 96 96 6d 79 0d
MK iterations: 10
UUID: bf5ca0c3-a68f-4544-8840-ba2p2af98918

Key Slot 0: ENABLED
Iterations: 70156
Salt: 08 e1 75 0e d1 1b 92 d1 f1 5f bd 50 9c ec a0 a2
b9 ea f8 da 1a 62 5d 4b 15 f3 4c a3 f3 49 12 83
Key material offset: 8
AF stripes: 4000
Key Slot 1: DISABLED
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED

Lot’s of nice information, don’t you feel super-geek ? You can see there that you have 8 spaces for pass-phrases, you have 8 slots of which you are using one, the 0.

To be able to access the encrypted partition you have to open it… and to do it you’ll need a key of course (your pass-phrase). We’ll see the mappings on /dev/mapper/, which should be empty by now (except for a control file… I wouldn’t name a mapping control, just in case):

root@pulab:~# ls /dev/mapper/
control

Ok! Now open it:

root@pulab:~# cryptsetup luksOpen /dev/hda3 home
Enter LUKS passphrase:
key slot 0 unlocked.
Command successful.

Great! We have opened it. The last parameter, “home”, is the name of the mapping. Let’s take a look at the mappings:

root@pulab:~# ls /dev/mapper/
control home

Good. This device file is like a partition itself. So, we’ll make a file-system in there in the same way you’d make it in hda3 (from now on, don’t do anything with hda3 except opening and other luks operations, your partition is /dev/mapper/home now). In my case I’ve picked reiserfs, but you can use whatever you want:

root@pulab:~# mkfs.reiserfs -l home /dev/mapper/home
.
lot's of geeky output
.
root@pulab:~#

and we are done. We can mount it:

root@pulab:~# mount /dev/mapper/home /media/

copy the current data (the home of a user and a couple of files):

root@pulab:~# cp -a /home/* /media/

un-mount it:

root@pulab:~# umount /media/

and close it:

cryptsetup luksClose home

Automagically mounting

There are various ways to open and mount the encrypted file-system but after trying many different ones, this is the best one from my point of view. I like that it is not intrusive: when you log in, your user password will be used to open the file-system and it’ll be mounted automatically. Of course then the password of your user should match the pass-phrase in some of the slots of the encrypted device.

You need to modify /etc/pam.d/common-auth adding, at the end:

@include common-pammount

And /etc/pam.d/common-session to add that same line:

@include common-pammount

In /etc/security/pam_mount.conf, around line 174 you have a list of “Linux encrypted home directory examples”, since what we are going to do is related to that it makes sense to put this line:

volume pupeno crypt - /dev/hda3 /home cipher=aes - -

there changing “pupeno” with your username and “/dev/hda3″ with your device. And that is the line that will make the magical mount happen.

Now just try it. It is very simple, log out, log in again and that’s it. You should have you newly super-encrypted home partition mounted. To check it out issue a mount command and among a huge amount of cryptic information you should see:

/dev/mapper/_dev_hda3 on /home type reiserfs (rw)

You can also list the files on /dev/mapper to find the _dev_hda3 mapping.

And that’s it, it wasn’t so hard, was it ?

More users, more passphrases

If there are more users add more lines to /etc/security/pam_mount.conf, I haven’t tested it but it should work. Also just add more passphrases to the device using cryptsetup in this way:

cryptsetup luksAddKey /dev/hda3

It’ll ask you for a current pass-phrase as well. This is also useful if you are changing pass-phrases, while you work on remembering the new one, don’t delete the old one, so if you forget the new one you should still be able to access your information with the old one. After you are confident of the new one, you can delete the old one with:

cryptsetup luksDelKey /dev/hda3 0

where “0″ is the slot where you have your old pass-phrase (hint: use luksDump). And here I want to remind you that if you lost the password you won’t be able to access the information. There’s no password recovery here: it is gone, forever, as scrambled, processed and destroyed as the dinner of Tuesday of the last week. Be very careful and always make backups.

Comments in the original blog

1. michuk Says:
   Two more articles describing the same:
   * http://polishlinux.org/howtos/truecrypt-howto/
   * http://polishlinux.org/howtos/encrypted-home-partition-in-linux/

June 11th, 2007 at 5:47 e

The most interesting feature is to be able to easily tell the packaging system that I want the unstable versions of this and that packages. I normally use the latest of GHC and Erlang (for example, the current GHC is just too old, and for Erlang, I like living on the edge; and the same for lots of other packages).

Although I was not able to reproduce that functionality completely I’ve found a good alternative. As usual this applies verbatim to other members of the Ubuntu family like Kubuntu and Edubuntu. They also apply to Debian, but for Debian there are already Backports so it doesn’t make any sense there. In this case I’ll do it for Ubuntu Edgy and Erlang, you’ll have to adapt it to your case.

Open the sources definitions in /etc/apt/sources.list and add the sources you want, but only to get sources and not binary packages (that is, the deb-src record and not the deb one). This is very important, if you add the deb you’ll get your whole system upgraded into the unstable version hence your system will be unstable. That option is only for developers, testers and adventurous people. In my case I added:

deb-src http://ar.archive.ubuntu.com/ubuntu/ feisty main restricted universe multiverse

Note that it is the mirror for Argentina (the “ar.” there), pick a mirror closer to you.

As usual you have to update the database of sources:

sudo aptitude update

where you should see something like:

Get:16 http://ar.archive.ubuntu.com feisty/main Sources [278kB]
Get:17 http://ar.archive.ubuntu.com feisty/restricted Sources [1740B]
Get:18 http://ar.archive.ubuntu.com feisty/universe Sources [1106kB]
Get:19 http://ar.archive.ubuntu.com feisty/multiverse Sources [43.3kB]

among the normal output. Very good.

I recommend running all the commands I’ll mention latter in a
particular directory for this purpose, like ~/pkg/Ubuntu/Erlang.
Basically, the build is done by one line:

fakeroot apt-get source --build erlang

but something can go wrong:

bash: fakeroot: command not found

We are missing fakeroot, we just install it:

sudo aptitude install fakeroot

and now we try the build command,

fakeroot apt-get source --build erlang

again:

Reading package lists... Done
Building dependency tree
Reading state information... Done
Need to get 10.2MB of source archives.
Get:1 http://ar.archive.ubuntu.com feisty/universe erlang 1:11.b.2-2 (dsc) [845B]
Get:2 http://ar.archive.ubuntu.com feisty/universe erlang 1:11.b.2-2 (tar) [10.2MB]
Get:3 http://ar.archive.ubuntu.com feisty/universe erlang 1:11.b.2-2 (diff) [33.7kB]
Fetched 10.2MB in 2m33s (66.5kB/s)
gpg: Signature made Thu 23 Nov 2006 02:59:49 AM ART using DSA key ID C4CF8EC3
gpg: Can't check signature: public key not found
dpkg-source: extracting erlang in erlang-11.b.2
dpkg-source: unpacking erlang_11.b.2.orig.tar.gz
dpkg-source: applying ./erlang_11.b.2-2.diff.gz
dpkg-buildpackage: source package is erlang
dpkg-buildpackage: source version is 1:11.b.2-2
dpkg-buildpackage: source changed by Erlang Packagers <erlang-pkg-devel@lists.berlios.de>
dpkg-buildpackage: host architecture i386
dpkg-buildpackage: source version without epoch 11.b.2-2
dpkg-checkbuilddeps: Unmet build dependencies: debhelper (>= 4.0.0) dpatch unixodbc-dev
dpkg-buildpackage: Build dependencies/conflicts unsatisfied; aborting.
dpkg-buildpackage: (Use -d flag to override.)
Build command 'cd erlang-11.b.2 && dpkg-buildpackage -b -uc' failed.
E: Child process failed

Believe it or not, that was better. We can see that it downloaded three file, a dsc, a tar and a diff. Those are the sources of a deb package. It tried to verify the gpg signature and it failed, don’t worry about that. The real problem is in the line that starts with “dpkg-checkbuilddep”, to build Erlang we need some packages we don’t have. So we install them:

sudo aptitude install debhelper dpatch unixodbc-dev

It is possible that a unstable package would depend on other unstable packages. Imagine if Ubuntu Edgy shipped debhelper 3.6.2, then it would not be enough to satisfy the dependency of debhelper (>= 4.0.0). In that case you should restart all this process for that other package until you have all the packages you need. You may run into trouble if you hit basic packages such as linux or libc… that’s beyond the scope of this little tutorial. With those packages installed we are ready to issue the build command again:

fakeroot apt-get source --build erlang

This time nothing goes wrong and we can see the familiar compiling output. Now it is just a matter of waiting. Wait. After the wait, and if everything went right, you’ll see your newly created Erlang packages:

$ ls *.deb
erlang_11.b.2-2_all.deb             erlang-dev_11.b.2-2_i386.deb      erlang-nox_11.b.2-2_all.deb
erlang-base_11.b.2-2_i386.deb       erlang-examples_11.b.2-2_all.deb  erlang-src_11.b.2-2_all.deb
erlang-base-hipe_11.b.2-2_i386.deb  erlang-mode_11.b.2-2_all.deb      erlang-x11_11.b.2-2_all.deb

All we have to do know is install them:

sudo dpkg -i erlang_11.b.2-2_all.deb erlang-base_11.b.2-2_i386.deb erlang-dev_11.b.2-2_i386.deb erlang-examples_11.b.2-2_all.deb erlang-mode_11.b.2-2_all.deb erlang-nox_11.b.2-2_all.deb erlang-src_11.b.2-2_all.deb erlang-x11_11.b.2-2_all.deb

Dpkg knows about dependencies and how to solve them but doesn’t know where to get packages from, that is what APT does (with all its repositories and all that). During that installation I’ve run into a problem:

dpkg: dependency problems prevent configuration of erlang-x11:
 erlang-x11 depends on tk8.4 | wish; however:
  Package tk8.4 is not installed.
  Package wish is not installed.

To solve it I just run:

sudo aptitude install tk8.4

and that was it:

$ erl
Erlang (BEAM) emulator version 5.5.2  [async-threads:0] [kernel-poll:false]

Eshell V5.5.2  (abort with ^G)
1>

Enjoy!

Comments in the original blog

1. Gwern Says:
   Wow. That’s pretty complex. Couldn’t you just pin packages to experimental or unstable, or run out of a local darcs repository?March 16th, 2007 at 2:49 e
2. Pupeno Says:

   You
   can’t just run packages from experimental or unstable because they are
   compiled for experimental or ustable. They are not likely to work with
   older versions of libraries, and if you start updatnig those libraries
   as well you are likely to soon hit libc6 and kaboom, your whole system
   will be upgraded to experimental or unstable.

   I don’t know what you mean by a local darcs repository, but if it is
   download the source code, compiling (like in configure, make) and
   install (make install), of course you can… but you loose the hability
   to do package-related actions, like uninstalling (aptitude uninstall
   package), finding out what files it installed (dpkg -L package),
   finding out to what package a file belongs when it belongs to our
   experimental software (dpkg -S /some/file) or spread the experimental
   package across comptures.

   I hope I have answered your question.

   March 16th, 2007 at 7:56 e

$ wget http://www.cse.unsw.edu.au/~dons/dlist/dlist-0.1.tar.gz
$ tar xvfz dlist-0.1.tar.gz
dlist-0.1
dlist-0.1/Data
dlist-0.1/Data/DList.hs
dlist-0.1/dlist.cabal
dlist-0.1/Setup.lhs
dlist-0.1/tests
dlist-0.1/tests/Parallel.hs
dlist-0.1/tests/Properties.hs
dlist-0.1/LICENSE
dlist-0.1/README

All the files we are going to create for packaging go in the “debian” directory inside dlist-0.1:

$ cd dlist-0.1/
~/dlist-0.1$ mkdir debian
~/dlist-0.1$ cd debian

We are going to take the files from another Haskell package to use them as templates. There are some Debian tools that generate a huge set of files inside the debian dir for making a package, but they are not targeted to Haskell and since you’d have to make so many changes that it’ll be easier to start from another Haskell package. Pick almost any from package from Haskell Unsafe, I’ve picked haskell-hunit:

~/dlist-0.1/debian$ wget http://haskell-unsafe.alioth.debian.org/.../haskell-hunit_1.1-1.diff.gz

It is a diff we have to apply after uncompressing it:

~/dlist-0.1/debian$ gunzip haskell-hunit_1.1-1.diff.gz
~/dlist-0.1/debian$ patch < haskell-hunit_1.1-1.diff
patching file copyright
patching file compat
patching file control
patching file rules
patching file changelog
patching file control.in
patching file libghc6-hunit-dev.prerm
patching file libghc6-hunit-dev.postinst
patching file libghc6-hunit-dev.prerm.in
patching file libghc6-hunit-dev.postinst.in

Some of those files are automatically generated (this is very different to normal Debian packages), so, we delete them:

~/dlist-0.1/debian$ rm control libghc6-hunit-dev.postinst libghc6-hunit-dev.prerm

And we can also remove the diff now:

~/dlist-0.1/debian$ rm haskell-hunit_1.1-1.diff

Now it is time to edit the files and customize them accordingly. Let’s start with changelog. The format of this file is very precise, one extra or missing space in some places and you’ll get an error. The result now looks like:

dlist (0.1-1) unstable; urgency=low

* Initial release.

-- José Pablo "Pupeno" Fernández

Mon, 11 Dec 2006 12:08:04 -0300

From that file the system will get the version of the package: 0.1-1. The first part, 0.1 is the mainstream release. The second part, -1, is the Debian release. It is there so you can correct a packaging mistake and release a new package, 0.1-2. The next file is control.in:

Source: dlist
Section: devel
Priority: optional
Maintainer: José Pablo "Pupeno" Fernández
Standards-Version: 3.7.2
Build-Depends: debhelper (>= 4), haddock (>= 0.6), $ghc6_lib_bdeps,
haskell-utils (>= 1.5), libghc6-base-dev, libghc6-base-prof
Package: libghc6-dlist-dev
Provides: libghc6-dlist-prof
Architecture: any
Depends: $ghc6_lib_deps, ${shlibs:Depends}, ${misc:Depends},
libghc6-base-dev, libghc6-base-prof
Description: A Haskell list type supporting O(1) append and snoc operations.
dlist provides Data.DList, a list type supporting O(1) append and snoc operations.

Build-Depends and Depends should be on one line, they were broken just to fit in the screen here. Description has two parts. The one in the first line is the short description. The rest, indented by spaces, is the long description. If the long description has more than one paragraph, each paragraph should be separated by an indented line containing a dot, like this:

this is the first paragraph.
.
this is the second paragraph.

The first line with nothing in it finishes the description. Now the copyright. This file contains some general information about who created the deb and who created the software itself:

This package was debianised by José Pablo "Pupeno" Fernández
on Mon, 11 Dec 2006.
It was downloaded from:

http://www.cse.unsw.edu.au/~dons/dlist/dlist-0.1.tar.gz

The homepage for the module is:

http://www.cse.unsw.edu.au/~dons/dlist.html

Copyright (c) 2006, Don Stewart
Licensed under the BSD3 license. A copy can be found at:
/usr/share/common-licenses/BSD

We now rename some files:

~/dlist-0.1/debian$ mv libghc6-hunit-dev.postinst.in libghc6-dlist-dev.postinst.in
~/dlist-0.1/debian$ mv libghc6-hunit-dev.prerm.in libghc6-dlist-dev.prerm.in

And that’s all. We don’t have to change anything in those last two files. In file rules we only have to replace Setup.hs for Setup.lhs, but that obviously depends on wether the package comes with a Setup.hs or a Setup.lhs. We now have to run some commands to get our beloved .deb file:

~/dlist-0.1/debian$ chmod +x rules

Generate the real control and other files:

~/dlist-0.1/debian$ cd ..
~/dlist-0.1$ debian/rules update-generated-files
update-haskell-control
ghc5 varfile not found
nhc98 varfile not found
hugs varfile not found
sed "s/@PACKAGE@/`dh_listpackages`/g"
debian/`dh_listpackages`.prerm.in
> debian/`dh_listpackages`.prerm
sed "s/@PACKAGE@/`dh_listpackages`/g"
debian/`dh_listpackages`.postinst.in
> debian/`dh_listpackages`.postinst

And to build the package:

$ dpkg-buildpackage -rfakeroot

That generates a lot of output, and in the end:

dpkg-deb: building package `libghc6-dlist-dev' in `../libghc6-dlist-dev_0.1-1_i386.deb'.

We can now try installing it:

$ sudo dpkg -i libghc6-dlist-dev_0.1-1_i386.deb
Password:
Selecting previously deselected package libghc6-dlist-dev.
(Reading database ... 137227 files and directories currently installed.)
Unpacking libghc6-dlist-dev (from .../libghc6-dlist-dev_0.1-1_i386.deb) ...
Setting up libghc6-dlist-dev (0.1-1) ...
Reading package info from stdin ... done.
Saving old package config file... done.
Writing new package config file... done.

Let’s check what was installed:

$ dpkg -L libghc6-dlist-dev
/.
/usr
/usr/bin
/usr/lib
/usr/lib/libghc6-dlist-dev
/usr/lib/libghc6-dlist-dev/unregister.sh
/usr/lib/libghc6-dlist-dev/register.sh
/usr/lib/dlist-0.1
/usr/lib/dlist-0.1/ghc-6.6
/usr/lib/dlist-0.1/ghc-6.6/Data
/usr/lib/dlist-0.1/ghc-6.6/Data/DList.p_hi
/usr/lib/dlist-0.1/ghc-6.6/Data/DList.hi
/usr/lib/dlist-0.1/ghc-6.6/libHSdlist-0.1.a
/usr/lib/dlist-0.1/ghc-6.6/HSdlist-0.1.o
/usr/lib/dlist-0.1/ghc-6.6/libHSdlist-0.1_p.a
/usr/lib/dlist-0.1/ghc-6.6/include
/usr/share
/usr/share/doc
/usr/share/doc/libghc6-dlist-dev
/usr/share/doc/libghc6-dlist-dev/copyright
/usr/share/doc/libghc6-dlist-dev/changelog.Debian.gz

Very nice. That’s it. The only missing step is letting the people at Debian Haskell know about it so it may be included in Debian. When people approach a new language they often want to do something with it. When that something is half done in a library, they are more likely to use the language. When that library has a simple and sane build system they are more likely to be able to use the library. When the library is sane and simple, it is more likely to be pre-packaged for different operating systems. When getting a library is such a matter of running a familiar command that is safe and simple, with easy removal and tracking of file, people feel safer and indeed is safer. So, if you follow Don’s advice when making your library you are helping improve the Haskell comunity. I’ve tried many languages and the ultimate test is how easy or hard is getting the libraries in place and working (and wether the libraries exist or not). I see a great potential here in Haskell.

In the end I ended up changing my own approach for one that is faster and cleaner so I wanted to share it with you. Still, go to the Debian Administration version of the article and read the comments, they are very cool (thanks to all those who posted!).

Here’s the approach: I mark all the packages as automatically installed:

aptitude --schedule-only markauto ~i

This doesn’t really mark them; if it did, it would also remove them (try dropping the “–schedule-only” and you’ll see what I am talking about).

Then I run aptitude in graphical mode, that is, by:

aptitude

there I press “g” to perform the actions… what actions ? the previously scheduled ones. It’ll mark every single package as automatically installed so it’ll show you a long list of packages to remove (all of them ? it’d be interested to let it run and see where it dies). I read the list, one by one, pressing “+” on each one I want to mantain installed. Automatically the dependencies will be marked as not-to-delete (although they’ll remain in auto mode). Once you finish you press “g” again and that’s it, it’ll remove all the un-needed packages.

To remove the configurations of those packages no longer needed (you have made backups first… no, it’s not a question) I run:

aptitude purge ~c

Thank you to the anonymous poster of this last tip and Kevin Locke for the previous one and let me repeat again: if you are interested in this, go see the comments, they are very interesting.

I also mentioned Ubuntu because this works for Ubuntu as well (actually, the last times I’ve used it was on Ubuntu installations). It will also work in other members of the Ubuntu family, like Kubuntu, Edubuntu and Xubuntu as well as other Debian derivate like Mepis.

One form of neglect is to install, install, install and never un-install any package. The common utility to perform installation and un-installation of packages is apt-get which adds to the problem because it doesn’t have automatic removal of non-needed dependences.

PHP and ton of other packages. phpMyAdmin was removed when it was no longer needed but Apache, PHP and the ton of packages remain there.

Aptitude to the rescue. Aptitude is another package manager front-end like apt-get but it can keep track of automatically and non-automatically installed packages. That means that when you installed phpMyAdmin it was marked as non-auto while Apache and company was marked as auto. When you remove phpMyAdmin all the non-needed automatically installed packages like Apache would be removed.

That is nice, but since the neglecting previous administrator didn’t use Aptitude, all the packages are marked as non automatically installed. The safe way so Aptitude doesn’t remove anything that it is needed.

So, what to do now ?

Well, the answer is: try to mark all files as automatically installed except those that you really want. To do that you can use the following (which you could write in one line if you want):

for pkg in $(aptitude search ~i | grep -v "i A" | cut -d " " -f 4) ; do
  echo "-- markauto $pkg --"
  aptitude markauto $pkg
done

A little explanation about this. This piece:

aptitude search ~i | grep -v "i A" | cut -d " " -f 4

you can run it by itself. It list all installed packages, then grep remove all those marked as automatically (we really don’t care about them). The cut part extracts the name of the package.

Once you have the name of each package you print a little header to know what package we are talking about and then try to mark it as automatic with:

aptitude markauto <pkg name>

in many cases marking a package as auto will not remove it, because another package depends on it, on other cases it’ll remove the package and maybe some other non-needed packages. In those cases Aptitude will ask you wether you want to continue or not. That is where you’ll have to do your job, analyze wether those packages are needed or not. If they are, tell Aptitude not to perform the operation and the for loop will continue with the next package.

At last, you may also consider removing the configurations of all those removed packages. Before doing this, make backups, that’s very important and I meant it.

To remove the configurations you can use the following code:

for pkg in $(dpkg -l | grep ^rc | cut -d " " -f 3) ; do
  dpkg -P $pkg ;
done

At the end you’ll have a system that is a bit cleaner.