June 10, 2008, at 05:44 AM by none -- Adding pam_mount scripts

Changed lines 143-151 from:

	TODO: configure the NFS server

to:

	TODO: configure the NFS server

 mounting and umounting

To simplify mounting and unmounting the encrypted partitions, consider

using the pam_mount scripts mount.crypt and umount.crypt

        http://dev.computergmbh.de/gitweb.cgi?p=pam_mount;a=blob_plain;f=scripts/mount.crypt;hb=HEAD

http://dev.computergmbh.de/gitweb.cgi?p=pam_mount;a=blob_plain;f=scripts/umount.crypt;hb=HEAD

December 03, 2007, at 03:04 PM by fcarolo -- fixed false wikilinks

Changed lines 1-2 from:

Project CryptSlug ?

to:

Project CryptSlug

Changed lines 22-24 from:

And thus, ProjectCryptSlug was born.

This HowTo will explain how to configure a freshly flashed NSLU2

to:

And thus, ProjectCryptSlug was born.

This HowTo will explain how to configure a freshly flashed NSLU2

Changed line 28 from:

Flashing your NSLU2 is not covered by this HowTo as it is already

to:

Flashing your NSLU2 is not covered by this HowTo as it is already

Changed lines 31-32 from:

Goals of this HowTo

to:

Goals of this HowTo

November 27, 2007, at 01:19 AM by ka6sox --

Changed line 10 from:

HR database with SSNs ? for debugging purposes or your not-so-legal

to:

HR database with SSNs for debugging purposes or your not-so-legal

Changed line 18 from:

But what if these drives must be accessible to multiple client PCs ?

to:

But what if these drives must be accessible to multiple client PCs

November 27, 2007, at 01:18 AM by ka6sox --

Changed line 33 from:

Sharing one or more fully encrypted HDDs ? via NFS (or other means) \\

to:

Sharing one or more fully encrypted HDDs via NFS (or other means) \\

Changed line 45 from:

One or more HDDs ? to be encrypted and used as shared drives

to:

One or more HDDs to be encrypted and used as shared drives

November 27, 2007, at 01:17 AM by ka6sox --

Changed lines 54-55 from:

not keep the HDDs ? spinning uselessly.

to:

not keep the HDDs spinning uselessly.

Changed lines 66-67 from:

You should use ext3 instead of ext2 for HDDs ?.

to:

You should use ext3 instead of ext2 for HDDs.

November 27, 2007, at 01:16 AM by ka6sox --

Changed line 64 from:

mkfs.ext2 -m0 -L "Boot" /dev/sda1

to:

 mkfs.ext2 -m0 -L "Boot" /dev/sda1

November 27, 2007, at 01:15 AM by ka6sox --

Changed line 38 from:

Recuirements

to:

Requirements

Changed lines 54-55 from:

not keep the HDDS spinning uselessly.

to:

not keep the HDDs ? spinning uselessly.

Changed lines 57-58 from:

I assume that you know how to partition an HDD at this point.

to:

(I assume that you know how to partition an HDD at this point.)

Changed lines 70-71 from:

turnup disk -i /dev/sda1 -t ext2

to:

 turnup disk -i /dev/sda1 -t ext2

Changed lines 73-75 from:

reboot

to:

 reboot

Changed lines 78-80 from:

Filesystem 1k-blocks Used Available Use% Mounted on

/dev/sda1 975112 9652 965460 1% /

to:

 Filesystem           1k-blocks      Used Available Use% Mounted on
 /dev/sda1               975112      9652    965460   1% /

Changed lines 86-87 from:

ipkg update && ipkg install cryptsetup nfs-utils

to:

 ipkg update && ipkg install cryptsetup nfs-utils

Changed lines 95-96 from:

echo �dm-crypt� > /etc/modutils/dm-crypt && update-modules

to:

 echo �dm-crypt� > /etc/modutils/dm-crypt && update-modules

Changed lines 98-102 from:

root@nslu2:/etc/modutils$ /etc/init.d/modutils.sh

Calculating module dependencies ...

Loading modules: dm-crypt

to:

 root@nslu2:/etc/modutils$ /etc/init.d/modutils.sh
 Calculating module dependencies ...
 Loading modules: dm-crypt

Changed lines 113-114 from:

cryptsetup -c aes-cbc-essiv:sha256 -y luksFormat /dev/sdb1

to:

 cryptsetup -c aes-cbc-essiv:sha256 -y luksFormat /dev/sdb1

Changed lines 120-121 from:

cryptsetup luksOpen /dev/sdb1 $SOMENAME

to:

 cryptsetup luksOpen /dev/sdb1 $SOMENAME

Changed lines 129-130 from:

mkfs.ext3 -m0 /dev/mapper/$SOMENAME

to:

 mkfs.ext3 -m0 /dev/mapper/$SOMENAME

Changed lines 133-134 from:

mount /dev/mapper/$SOMENAME /media/somewhere

to:

 mount /dev/mapper/$SOMENAME /media/somewhere

November 27, 2007, at 12:51 AM by none --

Changed lines 109-110 from:

This process causes complete data loss on that HDD!

to:

This process causes complete data loss on that HDD!

Changed line 139 from:

via the cryptsetup luksOpen /dev/sdb1 $SOMENAME command after every

to:

via the cryptsetup luksOpen /dev/sdb1 $SOMENAME command after every

November 27, 2007, at 12:49 AM by none --

Changed lines 109-110 from:

This process causes complete data loss on that HDD!

to:

This process causes complete data loss on that HDD!

November 27, 2007, at 12:48 AM by none --

Changed lines 22-23 from:

And thus, Project CryptSlug ? was born.

to:

And thus, ProjectCryptSlug was born.

Changed lines 109-110 from:

! This process involves complete data loss on that HDD ! !

to:

This process causes complete data loss on that HDD!

November 27, 2007, at 12:45 AM by none --

Changed lines 86-87 from:

ipkg update && ipkg install cryptsetup nfs-utils

to:

ipkg update && ipkg install cryptsetup nfs-utils

Changed lines 95-96 from:

echo �dm-crypt� > /etc/modutils/dm-crypt ; update-modules

to:

echo �dm-crypt� > /etc/modutils/dm-crypt && update-modules

Changed lines 99-102 from:

root@nslu2:/etc/modutils$ /etc/init.d/modutils.sh

Calculating module dependencies ...

Loading modules: dm-crypt

to:

root@nslu2:/etc/modutils$ /etc/init.d/modutils.sh

Calculating module dependencies ...

Loading modules: dm-crypt

Changed lines 113-114 from:

cryptsetup -c aes-cbc-essiv:sha256 -y luksFormat /dev/sdb1

to:

cryptsetup -c aes-cbc-essiv:sha256 -y luksFormat /dev/sdb1

Changed lines 120-121 from:

cryptsetup luksOpen /dev/sdb1 $SOMENAME

to:

cryptsetup luksOpen /dev/sdb1 $SOMENAME

Changed lines 129-130 from:

mkfs.ext3 -m0 /dev/mapper/$SOMENAME

to:

mkfs.ext3 -m0 /dev/mapper/$SOMENAME

Changed lines 133-134 from:

mount /dev/mapper/$SOMENAME /media/somewhere

to:

mount /dev/mapper/$SOMENAME /media/somewhere

November 27, 2007, at 12:43 AM by none --

Changed line 64 from:

mkfs.ext2 -m0 -L "Boot" /dev/sda1

to:

mkfs.ext2 -m0 -L "Boot" /dev/sda1

Changed lines 70-71 from:

turnup disk -i /dev/sda1 -t ext2

to:

turnup disk -i /dev/sda1 -t ext2

Changed lines 74-75 from:

reboot

to:

reboot

Changed lines 78-80 from:

Filesystem 1k-blocks Used Available Use% Mounted on

/dev/sda1 975112 9652 965460 1% /

to:

Filesystem 1k-blocks Used Available Use% Mounted on

/dev/sda1 975112 9652 965460 1% /

November 27, 2007, at 12:41 AM by none --

Changed line 64 from:

mkfs.ext2 -m0 -L "Boot" /dev/sda1

to:

mkfs.ext2 -m0 -L "Boot" /dev/sda1

Changed lines 70-71 from:

turnup disk -i /dev/sda1 -t ext2

to:

turnup disk -i /dev/sda1 -t ext2

Changed lines 74-80 from:

reboot

	The output of df  now shows our USB key as new rootfs:

	Filesystem           1k-blocks      Used Available Use% Mounted on
	/dev/sda1               975112      9652    965460   1% /

to:

reboot

The output of df now shows our USB key as new rootfs:

Filesystem 1k-blocks Used Available Use% Mounted on

/dev/sda1 975112 9652 965460 1% /

Changed lines 83-100 from:

	The following command installs all required packages for our
	little project:

 		ipkg update && ipkg install cryptsetup nfs-utils

	You may get one or more warning about missing modules.
	Usually these can be ignored.

	Cryptsetup depends on the dm-crypt module to function. For some 	reason the module does not auto-load so we need to force a 	modprobe on each boot:

 		echo �dm-crypt� > /etc/modutils/dm-crypt ; update-modules

	 Running modutils.sh should now auto-modprobe dm-crypt:

		root@nslu2:/etc/modutils$ /etc/init.d/modutils.sh 
		Calculating module dependencies ...
		Loading modules: dm-crypt

to:

The following command installs all required packages for our

little project:

ipkg update && ipkg install cryptsetup nfs-utils

You may get one or more warning about missing modules.

Usually these can be ignored.

Cryptsetup depends on the dm-crypt module to function. For some

reason the module does not auto-load so we need to force a modprobe

on each boot:

echo �dm-crypt� > /etc/modutils/dm-crypt ; update-modules

Running modutils.sh should now auto-modprobe dm-crypt:

root@nslu2:/etc/modutils$ /etc/init.d/modutils.sh

Calculating module dependencies ...

Loading modules: dm-crypt

Changed lines 105-110 from:

	At this point out slug is ready to handle encrypted partitions via 	cryptsetup. Now I'll explain how to format and encrypt an entire
	partition of an HDD.

	! ! This process involves complete data loss on that HDD ! !

Encrypt the partition:

to:

At this point out slug is ready to handle encrypted partitions via

cryptsetup. Now I'll explain how to format and encrypt an entire

partition of an HDD.

! This process involves complete data loss on that HDD ! !

Encrypt the partition:

Changed lines 113-135 from:

		cryptsetup -c aes-cbc-essiv:sha256 -y luksFormat /dev/sdb1

	 You will be asked for a password, you should try really hard
	not to forget it! Lose the password, lose the encrypted data.

Make the encrypted partition readable to the OS:

		cryptsetup luksOpen /dev/sdb1 $SOMENAME

	$SOMENAME can be anything at all, it identifies the partition.
	The encrypted partition can now be accessed via  	/dev/mapper/$SOMENAME. You can work with it like with a normal 	partition, just remember to not use /dev/sd* but always 	/dev/mapper/$SOMENAME.

Create a filesystem on the partition:

 		mkfs.ext3 -m0 /dev/mapper/$SOMENAME

Mount the partition somewhere:

		mount /dev/mapper/$SOMENAME /media/somewhere

	Congratulations. You're now the proud owner of a fully encrypted 	partition mounted on your NSLU2. After a reboot (or a power loss, 	someone stealing the HDD) the disk is fully encrypted and 	useless 	to any attacker. You have to manually specify the password
 	via the cryptsetup luksOpen /dev/sdb1 $SOMENAME command 	after every boot. As the NSLU2 usually is very stable, that shouldn't 	happen too often.

to:

cryptsetup -c aes-cbc-essiv:sha256 -y luksFormat /dev/sdb1

You will be asked for a password, you should try really hard

not to forget it! Lose the password, lose the encrypted data.

Make the encrypted partition readable to the OS:
cryptsetup luksOpen /dev/sdb1 $SOMENAME

$SOMENAME can be anything at all, it identifies the partition.

The encrypted partition can now be accessed via /dev/mapper/$SOMENAME.

You can work with it like with a normal partition, just remember to

not use /dev/sd* but always /dev/mapper/$SOMENAME.

Create a filesystem on the partition:
mkfs.ext3 -m0 /dev/mapper/$SOMENAME
Mount the partition somewhere:
mount /dev/mapper/$SOMENAME /media/somewhere

Congratulations. You're now the proud owner of a fully encrypted

partition mounted on your NSLU2. After a reboot (or a power loss,

someone stealing the HDD) the disk is fully encrypted and useless

to any attacker. You have to manually specify the password

via the cryptsetup luksOpen /dev/sdb1 $SOMENAME command after every

boot. As the NSLU2 usually is very stable, that shouldn't happen too often.

November 27, 2007, at 12:37 AM by none --

Changed lines 61-62 from:

Format the target partition onto which we will copy the rootfs.

In my case, I used an USB key drive:

to:

Format the target partition onto which we will copy the rootfs.
In my case, I used an USB key drive:

Changed line 64 from:

mkfs.ext2 -m0 -L "Boot" /dev/sda1

to:

mkfs.ext2 -m0 -L "Boot" /dev/sda1

Changed lines 66-68 from:

You should use ext3 instead of ext2 for HDDs ?.

Copy the rootfs

to:

You should use ext3 instead of ext2 for HDDs ?.

Copy the rootfs

Changed lines 70-75 from:

turnup disk -i /dev/sda1 -t ext2

Reboot the slug to switch to the new rootfs:

			reboot

to:

turnup disk -i /dev/sda1 -t ext2

Reboot the slug to switch to the new rootfs:

reboot

November 27, 2007, at 12:35 AM by none --

Changed line 45 from:

One or more HDDs ? to be encrypted and used as shared drives \\

to:

One or more HDDs ? to be encrypted and used as shared drives

Changed lines 50-56 from:

	As I mentioned before, the onboard flash of the NSLU2 is not
	large enough to hold all packages required, so we need to copy
	the rootfs to either an USB key or a small partition on an connected 	HDD. Many people prefer USB keys as they are cheap, fast and do 	not keep the HDDS spinning uselessly.

	The turnup script in SlugOS will do most of the grunt work for us.
	I assume that you know how to partition an HDD at this point.

to:

As I mentioned before, the onboard flash of the NSLU2 is not

large enough to hold all packages required, so we need to copy

the rootfs to either an USB key or a small partition on an connected

HDD. Many people prefer USB keys as they are cheap, fast and do

not keep the HDDS spinning uselessly.

The turnup script in SlugOS will do most of the grunt work for us.

I assume that you know how to partition an HDD at this point.

Changed lines 61-62 from:

Format the target partition onto which we will copy the rootfs. In my case, I used an USB key drive:

to:

Format the target partition onto which we will copy the rootfs.

In my case, I used an USB key drive:

Changed line 64 from:

 			mkfs.ext2 -m0 -L "Boot" /dev/sda1

to:

mkfs.ext2 -m0 -L "Boot" /dev/sda1

Changed lines 66-68 from:

		 You should use ext3 instead of ext2 for HDDs?.

Copy the rootfs

to:

You should use ext3 instead of ext2 for HDDs ?.

Copy the rootfs

Changed lines 70-73 from:

 			turnup disk -i /dev/sda1 -t ext2

Reboot the slug to switch to the new rootfs:

to:

turnup disk -i /dev/sda1 -t ext2

Reboot the slug to switch to the new rootfs:

November 27, 2007, at 12:33 AM by none --

Changed lines 33-34 from:

Sharing one or more fully encrypted HDDs ? via NFS (or other means) over NFS via an NSLU2

to:

Sharing one or more fully encrypted HDDs ? via NFS (or other means)
over NFS via an NSLU2

Changed line 40 from:

A cleanly flashed NSLU2 NAS box with a firmware not older than

to:

A cleanly flashed NSLU2 NAS box with a firmware not older than \\

Changed lines 42-43 from:

A USB flash drive or a dedicated (unencrypted) small partition on an HDD to hold the rootfs. The flash is too small to handle all

to:

A USB flash drive or a dedicated (unencrypted) small partition
on an HDD to hold the rootfs. The flash is too small to handle all \\

Changed line 45 from:

One or more HDDs ? to be encrypted and used as shared drives

to:

One or more HDDs ? to be encrypted and used as shared drives \\

November 27, 2007, at 12:31 AM by none --

Changed lines 39-40 from:

A cleanly flashed NSLU2 NAS box with a firmware not older than slugosbe-4.6-beta
A USB flash drive or a dedicated (unencrypted) small partition on an HDD to hold the rootfs. The flash is too small to handle all packages!

to:

A cleanly flashed NSLU2 NAS box with a firmware not older than slugosbe-4.6-beta
A USB flash drive or a dedicated (unencrypted) small partition on an HDD to hold the rootfs. The flash is too small to handle all packages!

November 27, 2007, at 12:30 AM by none --

Changed lines 33-35 from:

Sharing one or more fully encrypted HDDs ? via NFS (or other means) over NFS via an NSLU2 The encrypted drives can be connected to any Linux PC as well

to:

Sharing one or more fully encrypted HDDs ? via NFS (or other means) over NFS via an NSLU2
The encrypted drives can be connected to any Linux PC as well

Changed lines 39-43 from:

A cleanly flashed NSLU2 NAS box with a firmware not older than slugosbe-4.6-beta A USB flash drive or a dedicated (unencrypted) small partition on an HDD to hold the rootfs. The flash is too small to handle all packages! One or more HDDs ? to be encrypted and used as shared drives A bit of your time and some patience ;)

to:

A cleanly flashed NSLU2 NAS box with a firmware not older than slugosbe-4.6-beta
A USB flash drive or a dedicated (unencrypted) small partition on an HDD to hold the rootfs. The flash is too small to handle all packages!
One or more HDDs ? to be encrypted and used as shared drives
A bit of your time and some patience ;)

November 27, 2007, at 12:29 AM by none --

Changed line 5 from:

Imagine that you have a good amountof data on external drives

to:

Imagine that you have a good amount of data on external drives

Changed lines 13-21 from:

Storing this kind of stuff unencrypted is downright stupid. But that isn't too much of a problem if the number of external drives is small. If hooked up to a workstation, the external drives can be used with a wide range of encryption applications.

But what if these drives must be accessible to multiple client PCs ? at all times? Normally one would use a cheap NAS box to share all drives with the network. Problem is, at the time of writing, none of the usual NAS boxes supported any kind of encryption. And thus, Project CryptSlug ? was born.

	This HowTo will explain how to configure a freshly flashed NSLU2 	NAS box running SlugOS to securely encrypt attached drives and 	act as an NFS server. 

	Flashing your NSLU2 is not covered by this HowTo as it is already
	documented elsewhere.

to:

Storing this kind of stuff unencrypted is downright stupid.

But that isn't too much of a problem if the number of external

drives is small. If hooked up to a workstation, the external drives

can be used with a wide range of encryption applications.

But what if these drives must be accessible to multiple client PCs ?

at all times? Normally one would use a cheap NAS box to share

all drives with the network. Problem is, at the time of writing,

none of the usual NAS boxes supported any kind of encryption.

And thus, Project CryptSlug ? was born.

This HowTo will explain how to configure a freshly flashed NSLU2

NAS box running SlugOS to securely encrypt attached drives and

act as an NFS server.

Flashing your NSLU2 is not covered by this HowTo as it is already

documented elsewhere.

November 27, 2007, at 12:27 AM by none --

Changed lines 5-8 from:

Imagine that you have a good amountof data on external drives which you really would not want to be compromised in case of theft or curious relatives with too much time on their hands.

That data may be anything from company secrets, a dump of the HR database with SSNs ? for debugging purposes or your not-so-legal BT movie collection.

to:

Imagine that you have a good amountof data on external drives

which you really would not want to be compromised in case of theft

or curious relatives with too much time on their hands.

That data may be anything from company secrets, a dump of the

HR database with SSNs ? for debugging purposes or your not-so-legal

BT movie collection.

November 27, 2007, at 12:26 AM by none --

Changed lines 5-12 from:

	Imagine that you have a good amountof data on external drives 	which you really would not want to be compromised in case of theft 	or curious relatives with too much time on their hands.

	That data may be anything from company secrets, a dump of the 	HR database with SSNs? for debugging purposes or your not-so-	legal BT movie collection.

	Storing this kind of stuff unencrypted is downright stupid. But that 	isn't too much of a problem if the number of external drives is 	small. If hooked up to a workstation, the external drives can be 	used with a wide range of encryption applications.

	But what if these drives must be accessible to multiple client PCs? at 	all times? Normally one would use a cheap NAS box to share all 	drives with the network. Problem is, at the time of writing, none of 	the usual NAS boxes supported any kind of encryption. And thus, 	Project CryptSlug? was born.

to:

Imagine that you have a good amountof data on external drives which you really would not want to be compromised in case of theft or curious relatives with too much time on their hands.

That data may be anything from company secrets, a dump of the HR database with SSNs ? for debugging purposes or your not-so-legal BT movie collection.

Storing this kind of stuff unencrypted is downright stupid. But that isn't too much of a problem if the number of external drives is small. If hooked up to a workstation, the external drives can be used with a wide range of encryption applications.

But what if these drives must be accessible to multiple client PCs ? at all times? Normally one would use a cheap NAS box to share all drives with the network. Problem is, at the time of writing, none of the usual NAS boxes supported any kind of encryption. And thus, Project CryptSlug ? was born.

November 27, 2007, at 12:22 AM by none --

Added lines 1-113:

Project CryptSlug ?

Introduction

	Imagine that you have a good amountof data on external drives 	which you really would not want to be compromised in case of theft 	or curious relatives with too much time on their hands.

	That data may be anything from company secrets, a dump of the 	HR database with SSNs? for debugging purposes or your not-so-	legal BT movie collection.

	Storing this kind of stuff unencrypted is downright stupid. But that 	isn't too much of a problem if the number of external drives is 	small. If hooked up to a workstation, the external drives can be 	used with a wide range of encryption applications.

	But what if these drives must be accessible to multiple client PCs? at 	all times? Normally one would use a cheap NAS box to share all 	drives with the network. Problem is, at the time of writing, none of 	the usual NAS boxes supported any kind of encryption. And thus, 	Project CryptSlug? was born.

	This HowTo will explain how to configure a freshly flashed NSLU2 	NAS box running SlugOS to securely encrypt attached drives and 	act as an NFS server. 

	Flashing your NSLU2 is not covered by this HowTo as it is already
	documented elsewhere.

Goals of this HowTo

Sharing one or more fully encrypted HDDs ? via NFS (or other means) over NFS via an NSLU2 The encrypted drives can be connected to any Linux PC as well

Recuirements

A cleanly flashed NSLU2 NAS box with a firmware not older than slugosbe-4.6-beta A USB flash drive or a dedicated (unencrypted) small partition on an HDD to hold the rootfs. The flash is too small to handle all packages! One or more HDDs ? to be encrypted and used as shared drives A bit of your time and some patience ;)

Moving the rootfs

	As I mentioned before, the onboard flash of the NSLU2 is not
	large enough to hold all packages required, so we need to copy
	the rootfs to either an USB key or a small partition on an connected 	HDD. Many people prefer USB keys as they are cheap, fast and do 	not keep the HDDS spinning uselessly.

	The turnup script in SlugOS will do most of the grunt work for us.
	I assume that you know how to partition an HDD at this point.

Copy the rootfs

Format the target partition onto which we will copy the rootfs. In my case, I used an USB key drive:

 			mkfs.ext2 -m0 -L "Boot" /dev/sda1

		 You should use ext3 instead of ext2 for HDDs?.

Copy the rootfs

 			turnup disk -i /dev/sda1 -t ext2

Reboot the slug to switch to the new rootfs:

			reboot

	The output of df  now shows our USB key as new rootfs:

	Filesystem           1k-blocks      Used Available Use% Mounted on
	/dev/sda1               975112      9652    965460   1% /

Installing & configuring additional packages

	The following command installs all required packages for our
	little project:

 		ipkg update && ipkg install cryptsetup nfs-utils

	You may get one or more warning about missing modules.
	Usually these can be ignored.

	Cryptsetup depends on the dm-crypt module to function. For some 	reason the module does not auto-load so we need to force a 	modprobe on each boot:

 		echo �dm-crypt� > /etc/modutils/dm-crypt ; update-modules

	 Running modutils.sh should now auto-modprobe dm-crypt:

		root@nslu2:/etc/modutils$ /etc/init.d/modutils.sh 
		Calculating module dependencies ...
		Loading modules: dm-crypt

Setting up an encrypted partition

	At this point out slug is ready to handle encrypted partitions via 	cryptsetup. Now I'll explain how to format and encrypt an entire
	partition of an HDD.

	! ! This process involves complete data loss on that HDD ! !

Encrypt the partition:

		cryptsetup -c aes-cbc-essiv:sha256 -y luksFormat /dev/sdb1

	 You will be asked for a password, you should try really hard
	not to forget it! Lose the password, lose the encrypted data.

Make the encrypted partition readable to the OS:

		cryptsetup luksOpen /dev/sdb1 $SOMENAME

	$SOMENAME can be anything at all, it identifies the partition.
	The encrypted partition can now be accessed via  	/dev/mapper/$SOMENAME. You can work with it like with a normal 	partition, just remember to not use /dev/sd* but always 	/dev/mapper/$SOMENAME.

Create a filesystem on the partition:

 		mkfs.ext3 -m0 /dev/mapper/$SOMENAME

Mount the partition somewhere:

		mount /dev/mapper/$SOMENAME /media/somewhere

	Congratulations. You're now the proud owner of a fully encrypted 	partition mounted on your NSLU2. After a reboot (or a power loss, 	someone stealing the HDD) the disk is fully encrypted and 	useless 	to any attacker. You have to manually specify the password
 	via the cryptsetup luksOpen /dev/sdb1 $SOMENAME command 	after every boot. As the NSLU2 usually is very stable, that shouldn't 	happen too often.

	TODO: Use keys instead of passphrase
	TODO: configure the NFS server

NSLU2-Linux

General

OS/Firmware Projects

Firmware Targets

Optware

Optware Targets

Other Hardware

Wiki Resources

Sponsored Links

HowTo.ProjectCryptSlug History

Project CryptSlug ?

Project CryptSlug

Goals of this HowTo

Goals of this HowTo

Recuirements

Requirements

! This process involves complete data loss on that HDD ! !

! This process involves complete data loss on that HDD ! !

Project CryptSlug ?

Introduction

Goals of this HowTo

Recuirements

Moving the rootfs

Copy the rootfs

Installing & configuring additional packages

Setting up an encrypted partition