On Thu, Jan 10, 2008 at 10:45:13PM +0000, Da Powah wrote: > Hi Arno, > > i formatted the whole text floating - but readable. > The hotmail webmailer seems to throw some returns away. Ah, that would explain it. > I`m sorry - i try a correct formatted post later. I fought my way through and got the gist. I also can read the initial german version (Gruesse aus Zuerich!) which I initially overlooked, so don't bother. > 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. > #3 i made a lage logical volume with lvm Within the RAID5 device, I take it. > #4 i created an encrypted device of that lvm (1,39TB) ok. > #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) 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. > ####### > > This was the way to my encryption desaster: > root@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 > root@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. > root@homeserver:~# cd /dev/mapper/ > root@homeserver:/dev/mapper# ls > control hda1 hda5 lvm2|vg|crypted_raid raid sde1 ok > root@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? Was anything ever written to /dev/mapper/crypted_raid? Or does LUKS maybe write to the disk when mapping it and you have a conflict between the two mappings? Is there anything structured an the place were the LUKS superblock should be in the encrypted device? 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. 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. Arno -- Arno Wagner, Dipl. Inform., CISSP --- CSG, ETH Zurich, arno@xxxxxxxxxxx GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F ---- Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans If it's in the news, don't worry about it. The very definition of "news" is "something that hardly ever happens." -- Bruce Schneier --------------------------------------------------------------------- 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
