[dm-crypt] cryptsetup

[dm-crypt] cryptsetup

[omar ahizoun]

[-- Attachment #1: Type: text/plain, Size: 245 bytes --]

Hello,

I'm trying to setup a crypted filesystem using cryptsetup under Centos, but
when I execute it, it doesn't ask for password.

cryptsetup -c aes-xts-plain -y -s 256 luksFormat /dev/vg_consulate/lv_Luks

Any Ideas.

Thanks in advance

Omar

[-- Attachment #2: Type: text/html, Size: 378 bytes --]

[dm-crypt] Cryptsetup

[Steven Houtchen]

[-- Attachment #1: Type: text/plain, Size: 41 bytes --]

How to compile crypsetup to use in gdb??

[-- Attachment #2: Type: text/html, Size: 63 bytes --]

Re: [dm-crypt] cryptsetup

[Gilles PIETRI]

On 02/09/2009 03:14, solarflow99 wrote:
> can anyone say if this command is needed when resizing a partition?  
> What if I just used resize2fs? how could it know about the change of 
> size?  Also its a shame information like this has to be a secret, no one 
> seems to know or say anything about it.
> 
> Thanks,
> 

I have a question myself that is somehow related.. I do not know much 
about the internals of the payload alignment (--align-payload option of 
luksFormat), but I thought about something.. Say I have a RAID device of 
6 disks, that I have a stripe size of 64K, and that I use 
--align-payload (stripe width is 512 blocks here). Fine, should be 
aligned with the stripes.

Now, say that I add a disk there and migrate the array over it, the 
stripe width will increase to 640 blocks.. but how can I tell luks about 
it? Should I? Maybe newly written data could benefit from being aligned 
to the new stripe width (and let us say it won't be optimal for older 
data, but so be it)?

I know that xfs can then deal with the swidth growth by specifying the 
info in the mount options, so once cryptsetup knows about the geometry 
change, it should be fine..

Cheers,

Gilou

Re: [dm-crypt] cryptsetup

[Milan Broz]

f-dm-c@media.mit.edu wrote:
> Shouldn't there be a "cryptsetup resize" in there somewhere?
> [Presumably before you resized the ext2]

There is no device size stored in LUKS header, only data offset.

So after luksClose/luksOpen the device has always new size, of course
if you increase size extended part of device still contains old data.

You can also resize device online - just use "cryptsetup resize <name>".
(The --size parameter is not mandatory, man page is wrong here,
if --size is not provided, it will expand to whole device).

So if you have LUKS on partition, and you want extend it: 
extend partition -> resize crypt mapping (or deactivate/activate) -> resize fs

For reducing just do it in reverse order
resize fs -> deactivate cryptsetup -> reduce partition.
(if you need it online, you will have to specify --size for cryptsetup resize,
note that --size is in sectors)

Milan
--
mbroz@redhat.com

[dm-crypt] cryptsetup

[f-dm-c]

Shouldn't there be a "cryptsetup resize" in there somewhere?
[Presumably before you resized the ext2]

It might be interesting for you to look at the raw file and ensure
that there isn't some region of it that is (mostly) several megs of
zeroes (interrupted by superblocks and so forth).  I suspect that the
last half of your loopback device is now -not- encrypted unless LUKS
magically knew to extend its crypto mapping over it.

Re: [dm-crypt] cryptsetup

[test532]

Hi There,

I don't know anything about the internals of dmcrypt, but I was in an 
inquisitive mood, so I did some testing, and this is what I found:

I had success, and it appears that you don't have to do anything special with 
dmcrypt/cryptsetup. I did luksClose before resizing the 'partition' however, 
which is either required or at least a good idea to be safe.

Here is what I did:

1.I created a test file in my home directory:

# dd if=/dev/zero of=test bs=10000000 count=1

2. I then created a loop back device for it:

# losetup -f test

(this created /dev/loop0)

3. I then did a luksFormat on it:

# cryptsetup luksFormat /dev/loop0

4. Opened it.

# cryptsetup luksOpen /dev/loop0 test

5. formatted it

# mkfs.ext2 /dev/mapper/test

6. mounted it

# mkdir /mnt/test && mount /dev/mapper/test /mnt/test

7. filled it up

# dd if=/dev/urandom of=/mnt/test/fill

(resulting file was ~9megs, df reports 0 space left on drive)

8. md5sum on file to make sure it doesn't get corrupted from the next steps.

# md5sum /mnt/test/fill

(25d32f5e6a66e3ad7d7979b7785d7f02  fill)

9. unmounted

# umount /mnt/test

10. luksClosed it.

# cryptsetup luksClose /dev/mapper/test

11. detached the loop back device.

# losetup -d /dev/loop0

12. made the 'partition' bigger. (doubled the size of the file, by adding 
10megs of zeros to the end, not overwriting the first original 10 megs)

# dd if=/dev/zero of=test bs=10000000 seek=1 count=1

13. losetup'ed it.

# losetup -a test

14. luksOpened it, no special other luks stuff needed.

# cryptsetup luksOpen /dev/loop0 test

15. expanded the ext2 filesystem to fill the new larger size of the 
blockdevice.

# fsck.ext2 -f /dev/mapper/test && resize2fs /dev/mapper/test

(resize wants you to first run a fsck on it)

16. Mounted it,

# mount /dev/mapper/test /mnt/test

17. Filled it some more.

# dd if=/dev/urandom of=/mnt/test/fill2

(Resulted in another ~9meg file, thus proving that the filesystem resized 
properly)

18. checksumed the first fill file again to make sure it didn't change (Ie. 
get corrupted).

# md5sum fill

(25d32f5e6a66e3ad7d7979b7785d7f02  fill)

As you can see everything worked fine.

Here are the versions of my cryptsetup and dmsetup:

cryptsetup --version
cryptsetup 1.0.6-pre1

dmsetup --version
Library version:   1.02.27 (2008-06-25)
Driver version:    4.14.0


So based upon my testing, you should be fine. It shouldn't mater if you are 
resizing a loop back device like I did to test, or are resizing a partition, 
or are resizing a logical volume (LVM). What is important is it seems a 
luksFormat does not store any info regarding the size of the blockdevice. So 
if you close, resize and open, it will take advantage of the new space. I 
cannot say about shrinking though. If you are trying to shrink, try the same 
thing I did above, but with shrinking. I would assume that shrinking is more 
risky as who knows how cryptsetup stores the data, it might put stuff at the 
end of the drive that then you would be truncating away.

As for growing, as long as you do the things in the order I did, everything 
should be fine. (Like make sure to luksClose the partition/logical_volume 
before resizing it).

Good Luck!

Sam

> can anyone say if this command is needed when resizing a partition?  What
>  if I just used resize2fs? how could it know about the change of size? 
>  Also its a shame information like this has to be a secret, no one seems to
>  know or say anything about it.
> 
> Thanks,
> 

[dm-crypt] cryptsetup

[solarflow99]

[-- Attachment #1: Type: text/plain, Size: 260 bytes --]

can anyone say if this command is needed when resizing a partition?  What if
I just used resize2fs? how could it know about the change of size?  Also its
a shame information like this has to be a secret, no one seems to know or
say anything about it.

Thanks,

[-- Attachment #2: Type: text/html, Size: 274 bytes --]