Arno Wagner <wagner@...> writes: > > To your question: > > the order of my "way to an encrypted raid" is this: > > > > #1 i use 4 HDDs. > > #2 i made a Soft raid5 with mdadm > > So raid is on unencrypted disks and the raid superblocks are > in the clear. Good. Any disk or RAID problem would now show up on > RAID level. Yes. And cat /proc/mdstat shows all 4 devices are up and clean. > > #3 i made a large logical volume with lvm > Within the RAID5 device, I take it. yes. And lvdisplay reports an ACTIVE lvm (vg-crypted_raid). > > #4 i created an encrypted device in that lvm (1,39TB) > ok. yes, with: cryptsetup luksFormat (aes-essiv:sha256). > > #5 i decrypted the device, mapped it as decrypted raid under > > /dev/mapper/raid and formatted it. > > So > (disks 1,2,3,4) --RAID5--> (/dev/mdx) > --cut out part with lvm--> (/dev/y) > --cryptsetup /dev/y /dev/mapper/raid ...--> (/dev/mapper/raid) /dev/sda to /dev/sdd are raid /dev/md0 /dev/mapper/vg-crypted_raid is the mapped lvm (out of a /dev/dm-[xy] ???) /dev/mapper/raid was generated by: cryptsetup luksOpen /dev/mapper/vg-crypted_raid raid -d/mnt/key.md0.orig > > The right way to do it IMO, unless you want to hide the existence of > the RAID, in which case you would have to build the raid on > something like /dev/mapper/d1 .... /dev/mapper/d4. i don`t want to hide the raid. I guess the setup is ok like i made it: /dev/sda to /dev/sdd are raid /dev/md0 > > > ####### > > > > This was the way to my encryption desaster: > > root <at> homeserver:~# cryptsetup luksOpen > > /dev/mapper/lvm2\|vg\|crypted_raid > > crypted_raid -d /mnt/usb/key.md0.orig > > key slot 0 unlocked. > > Command successful. > > So you forst mapped it to /dev/ammper/crypted_raid yes - and no. i posted some old commands out of my log files, so that you know how i made my setup. I think now, it is a bit confusing. Take this command as creation info, only. Now i do map the logical volume /dev/mapper/vg-crypted_raid now with cryptsetup luksOpen /dev/mapper/vg-crypted_raid raid -d/mnt/key.md0.orig to /dev/mapper/raid. > > root <at> homeserver:~# cryptsetup luksOpen /dev/mapper/lvm2\|vg\|crypted_raid raid -d /mnt/usb/key.md0.orig > > key slot 0 unlocked. > > Command successful. > > And then mapped it also to /dev/mapper/raid. It would now be mapped > (and decrypted) to both /dev/mapper/crypted_raid and /dev/mapper/raid. > Very bad idea, as this bypasses any synchronisation between > the two devices and any buffering/caching of data for them. Even > the mapping itself may also be a problem, if LUKS writes anything to > disk. No idea whether it does. Vanilla dm-cryot does not. This is also an old command. But it didn`t harmed the raid: This command mapped the crypted lvm /dev/mapper/lvm2.... to /dev/mapper/raid. Take this as creation info, only, too. > > > root <at> homeserver:~# cd /dev/mapper/ > > root <at> homeserver:/dev/mapper# ls > > control hda1 hda5 lvm2|vg|crypted_raid raid sde1 > > ok there you can see the encrypted volume lvm2|vg|crypted_raid and the mapped decrypted volume raid. > > > root <at> homeserver:/dev/mapper# mke2fs -b 4096 -j /dev/mapper/raid > > mke2fs 1.38 (30-Jun-2005) > > Filesystem label= > > OS type: Linux > > Block size=4096 (log=2) > > Fragment size=4096 (log=2) > > 178257920 inodes, 356515583 blocks > > 17825779 blocks (5.00%) reserved for the super user > > First data block=0 > > 10880 block groups > > 32768 blocks per group, 32768 fragments per group > > 16384 inodes per group > > Superblock backups stored on blocks: > > 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, > > 2654208, > > 4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968, > > 102400000, 214990848 > > > > Writing inode tables: done > > Creating journal (32768 blocks): done > > Writing superblocks and filesystem accounting information: done > > ########## > > > Since then the de- and encryption works fine: i copied about 200GB > > Data onto the decrypted raid. I pulled one HDD and formatted it > > separately. I added it later to the raid and it resynced. After > > resync all data was fine (checked with MD5Sum). Do i didn`t worry to > > use it for some weeks in test mode and switched after approx. 1 > > month heavy duty to raid only.... my fault, because i should have > > made at least some backups in encrypted containers on HDD.... > > Can you post the current output? The current state is, that all layers up to cryptsetup seem to be ok. The first command that fails is: cryptsetup luksOpen /dev/mapper/vg-crypted_raid raid -d/mnt/key.md0.orig Aufruf fehlgeschlagen. (Command failed.) If i use the option luksAddKey then i get something like: found no Masterkey with this passphrase. > Was anything ever written to > /dev/mapper/crypted_raid? no - not that i know: because this device cannot be mounted and i do not play with dd commands. > Or does LUKS maybe write to the disk > when mapping it and you have a conflict between the two mappings? As i use only a mapping to /dev/mapper/raid it should be ok. > Is there anything structured an the place were the LUKS superblock > should be in the encrypted device? The luks superblock is in my posting below and tells me correct infos. So the superblock can be found but the masterkey not. It seems that i am using a wrong passphrase (the wrong key file) but it is the same (verified against a key file backup). I also tried with fedora 8.0 and ubuntu 7.10 LiveCDs. They give me as well the hint, that no masterkey can be found. > I take it a LUKS superblock is > not or only partially encrypted and its presence should be > detectable. If it is not there, the data may be lost. If it > is there, then this may actually be some minor issue, like some > corrupted metadata that can be repaired. The LUKS Superblock is there and clean: cryptsetup luksDump /dev/mapper/vg-crypted_raid LUKS header information for /dev/mapper/vg-crypted_raid Version: 1 Cipher name: aes Cipher mode: cbc-essiv:sha256 Hash spec: sha1 Payload offset: 2056MK bits:256MK digest: f2 48 52 aa 27 1c 44 2f 8b 75 e7 f6 97 8a fd b1 e9 ca eb eb MK salt: 5b df c6 92 30 f4 4f 60 13 79 7d f2 13 xx xx xx 33 e5 71 f1 48 a7 ce 82 d2 5d 30 70 ac 23 84 0c MK iterations: 10 UUID: f4ede5a1-cbbd-493a-ab7b-27371cxxxxxx Key Slot 0: ENABLED Iterations: 170750 Salt: 15 de 36 21 58 43 24 88 d8 a3 35 cd c966 91 e55c de 5c 75 81 0b 0f 2e db 55 xx xx xx65 96 01 Key material offset: 8AF 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 > > Anyways, I see no potential problem with this set-up, right up to > the point where you map (decrypt) it to two different raw devices. > Raid resyncs, for example, should have no impact at all. LVM also > seems so be entirely blameless. As far as i use one mapping only, my setup should be ok. there has to be a problem with finding the masterkey.... Lets hope and lets find some metadata, but how ? > > Arno Thanks for answers, Arno. DP. --------------------------------------------------------------------- dm-crypt mailing list - http://www.saout.de/misc/dm-crypt/ To unsubscribe, e-mail: dm-crypt-unsubscribe@xxxxxxxx For additional commands, e-mail: dm-crypt-help@xxxxxxxx
