Hello list,
I bought a Thinkpad T420 and installed CentOS 7 recently.
I choosed to use lvm encryption for the entire volume group. It works so far.
But now I am planning to install a second hard disk. My thought is to create a new volume group on this additional disk.
But how can I integrate/do this according to the existing encryption so that it will be decrypted by the same passphrase I use at startup?
Regards and thanks in advance Tim
On Thu, Mar 5, 2015 at 2:09 PM, Tim lists@kiuni.de wrote:
Hello list,
I bought a Thinkpad T420 and installed CentOS 7 recently.
I choosed to use lvm encryption for the entire volume group. It works so far.
But now I am planning to install a second hard disk. My thought is to create a new volume group on this additional disk.
But how can I integrate/do this according to the existing encryption so that it will be decrypted by the same passphrase I use at startup?
http://linux.die.net/man/5/crypttab
When you create a new entry in crypttab, you can use the 3rd field to point to a file that contains the passphrase for this new LUKS volume. In effect, one passphrase gives access to both drives.
So there's a pro con here. Pro is that you could actually opt for a completely different passphrase for the 2nd drive, but never have to directly type it in. The con is that should you forget this passphrase, and its only location is on the primary drive that's already encrypted and that drive dies - then anything on the 2nd drive cannot be decrypted. Oops. So be careful of that.
Hi Chris,
thanks for your answer.
It is the first time I decided to encrypt my lvm. I choosed to encrypt the volume group, not every logical volume itself, because in case of doing lvm snapshots in that group they will be encrypted too?
And how do I create a new encrypted volume group?
Regards Tim
Am 6. März 2015 01:58:23 MEZ, schrieb Chris Murphy lists@colorremedies.com:
On Thu, Mar 5, 2015 at 2:09 PM, Tim lists@kiuni.de wrote:
Hello list,
I bought a Thinkpad T420 and installed CentOS 7 recently.
I choosed to use lvm encryption for the entire volume group. It works
so far.
But now I am planning to install a second hard disk. My thought is to
create a new volume group on this additional disk.
But how can I integrate/do this according to the existing encryption
so that it will be decrypted by the same passphrase I use at startup?
http://linux.die.net/man/5/crypttab
When you create a new entry in crypttab, you can use the 3rd field to point to a file that contains the passphrase for this new LUKS volume. In effect, one passphrase gives access to both drives.
So there's a pro con here. Pro is that you could actually opt for a completely different passphrase for the 2nd drive, but never have to directly type it in. The con is that should you forget this passphrase, and its only location is on the primary drive that's already encrypted and that drive dies - then anything on the 2nd drive cannot be decrypted. Oops. So be careful of that.
-- Chris Murphy _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Thu, Mar 5, 2015 at 10:25 PM, Tim lists@kiuni.de wrote:
Hi Chris,
thanks for your answer.
It is the first time I decided to encrypt my lvm. I choosed to encrypt the volume group, not every logical volume itself, because in case of doing lvm snapshots in that group they will be encrypted too?
Yes, anything that's COW'd is also encrypted in this case.
And how do I create a new encrypted volume group?
Strictly speaking the VG isn't the target of the encryption, the underlying PV is. Also, it's not absolutely necessary to partition the drive at all if you have no need for unencrypted space on this new drive. Since I use drives on multiple platforms, I always partition so that other OS's recognize the drive space is spoken for instead of appearing unpartitioned and hence blank. Linux via libblkid always looks at disk contents whether partitioned or not so if this is a Linux only drive you don't have to partition it.
1. Use cryptsetup to create a LUKS volume on the whole disk or a partition thereof. For the exact command, you can cheat by doing 'grep cryptsetup /var/log/anaconda/program.log' which will show you the command Anaconda used when setting up your first drive. PLEASE make sure you don't use that command directly or it'll wipe the LUKS header on your current drive. You have to change the /dev/sdX designation to point to the new drive or partition.
2 cryptsetup luksOpen /dev/sdX newdrive 3. pvcreate /dev/mapper/newdrive 4. vgcreate newvg /dev/mapper/newdrive 5. lvcreate -L 300G -n morestuff newvg 6. mkfs.xfs /dev/mapper/newvg-morestuff
Adapt as needed. Don't forget crypttab is used to point to the LUKS volume, once it's unlocked the PV is revealed and lvm will activate the VG and the LVs on it, and then in your fstab you'll have the UUID for the XFS volume and mount this whereever you want it mounted.
I will have a look at the anaconda log. Thanks for the first help. I will have to buy a new Ultrabay case.
Am 6. März 2015 07:10:31 MEZ, schrieb Chris Murphy lists@colorremedies.com:
On Thu, Mar 5, 2015 at 10:25 PM, Tim lists@kiuni.de wrote:
Hi Chris,
thanks for your answer.
It is the first time I decided to encrypt my lvm. I choosed to
encrypt the
volume group, not every logical volume itself, because in case of
doing lvm
snapshots in that group they will be encrypted too?
Yes, anything that's COW'd is also encrypted in this case.
And how do I create a new encrypted volume group?
Strictly speaking the VG isn't the target of the encryption, the underlying PV is. Also, it's not absolutely necessary to partition the drive at all if you have no need for unencrypted space on this new drive. Since I use drives on multiple platforms, I always partition so that other OS's recognize the drive space is spoken for instead of appearing unpartitioned and hence blank. Linux via libblkid always looks at disk contents whether partitioned or not so if this is a Linux only drive you don't have to partition it.
- Use cryptsetup to create a LUKS volume on the whole disk or a
partition thereof. For the exact command, you can cheat by doing 'grep cryptsetup /var/log/anaconda/program.log' which will show you the command Anaconda used when setting up your first drive. PLEASE make sure you don't use that command directly or it'll wipe the LUKS header on your current drive. You have to change the /dev/sdX designation to point to the new drive or partition.
2 cryptsetup luksOpen /dev/sdX newdrive 3. pvcreate /dev/mapper/newdrive 4. vgcreate newvg /dev/mapper/newdrive 5. lvcreate -L 300G -n morestuff newvg 6. mkfs.xfs /dev/mapper/newvg-morestuff
Adapt as needed. Don't forget crypttab is used to point to the LUKS volume, once it's unlocked the PV is revealed and lvm will activate the VG and the LVs on it, and then in your fstab you'll have the UUID for the XFS volume and mount this whereever you want it mounted.
-- Chris Murphy _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
I'm sorry, but grep -i crypt /var/log/anaconda/anaconda.program.log returns nothing. But I have got an entry in /etc/crypttab.
I only found this with grep -i luks /var/log/anaconda/anaconda.*: /var/log/anaconda/anaconda.storage.log:20:47:55,959 DEBUG blivet: LUKS.__init__: /var/log/anaconda/anaconda.storage.log:20:49:25,009 DEBUG storage.ui: LUKS.__init__: /var/log/anaconda/anaconda.storage.log:20:49:25,009 DEBUG storage.ui: getFormat('luks') returning LUKS instance /var/log/anaconda/anaconda.storage.log:20:49:25,014 DEBUG storage.ui: PartitionDevice._setFormat: sda2 ; current: None ; type: luks ; /var/log/anaconda/anaconda.storage.log:20:49:25,015 INFO storage.ui: registered action: [23] Create Format luks on partition sda2 (id 15) /var/log/anaconda/anaconda.storage.log:20:49:25,018 DEBUG storage.ui: LUKSDevice._setFormat: luks-sda2 ; current: None ; type: lvmpv ; /var/log/anaconda/anaconda.storage.log:20:49:25,019 INFO storage.ui: added luks/dm-crypt luks-sda2 (id 21) to device tree /var/log/anaconda/anaconda.storage.log:20:49:25,019 INFO storage.ui: registered action: [24] Create Device luks/dm-crypt luks-sda2 (id 21) /var/log/anaconda/anaconda.storage.log:20:49:25,019 INFO storage.ui: registered action: [25] Create Format lvmpv on luks/dm-crypt luks-sda2 (id 21) /var/log/anaconda/anaconda.storage.log:20:49:25,020 DEBUG storage.ui: LUKSDevice.addChild: kids: 0 ; name: luks-sda2 ; ...
Seems as there is no command to crib. :-(
Regards Tim
Am 06.03.2015 um 07:10 schrieb Chris Murphy:
On Thu, Mar 5, 2015 at 10:25 PM, Tim lists@kiuni.de wrote:
Hi Chris,
thanks for your answer.
It is the first time I decided to encrypt my lvm. I choosed to encrypt the volume group, not every logical volume itself, because in case of doing lvm snapshots in that group they will be encrypted too?
Yes, anything that's COW'd is also encrypted in this case.
And how do I create a new encrypted volume group?
Strictly speaking the VG isn't the target of the encryption, the underlying PV is. Also, it's not absolutely necessary to partition the drive at all if you have no need for unencrypted space on this new drive. Since I use drives on multiple platforms, I always partition so that other OS's recognize the drive space is spoken for instead of appearing unpartitioned and hence blank. Linux via libblkid always looks at disk contents whether partitioned or not so if this is a Linux only drive you don't have to partition it.
- Use cryptsetup to create a LUKS volume on the whole disk or a
partition thereof. For the exact command, you can cheat by doing 'grep cryptsetup /var/log/anaconda/program.log' which will show you the command Anaconda used when setting up your first drive. PLEASE make sure you don't use that command directly or it'll wipe the LUKS header on your current drive. You have to change the /dev/sdX designation to point to the new drive or partition.
2 cryptsetup luksOpen /dev/sdX newdrive 3. pvcreate /dev/mapper/newdrive 4. vgcreate newvg /dev/mapper/newdrive 5. lvcreate -L 300G -n morestuff newvg 6. mkfs.xfs /dev/mapper/newvg-morestuff
Adapt as needed. Don't forget crypttab is used to point to the LUKS volume, once it's unlocked the PV is revealed and lvm will activate the VG and the LVs on it, and then in your fstab you'll have the UUID for the XFS volume and mount this whereever you want it mounted.
On Sun, Mar 8, 2015 at 5:36 AM, Tim lists@kiuni.de wrote:
I'm sorry, but grep -i crypt /var/log/anaconda/anaconda.program.log returns nothing. But I have got an entry in /etc/crypttab.
OK ignore what I wrote about crypttab and pointing to a file. Robert's message is essentially correct.
It looks like the cryptesetup command gets stripped out of the anaconda.program.log, probably because it contains the user passphrase in it. This is the basic command used in RHEL 7 documentation [1] which you can adapt for either a whole disk or partition thereof rather than an LV. cryptsetup --verbose --verify-passphrase luksFormat Just use the same passphrase you're using for the other drive. Note that the actual key is different for the two LUKS volumes, so you should back up both of those LUKS headers (with cryptsetup), one isn't enough even though the passphrases are the same. (The DEK used to actually encrypt your data is randomly chosen)
You'll need to make the following modifications:
/etc/fstab mount options for LUKS encrypted volumes includes x-systemd.device-timeout=0 which means it'll wait indefinitely for this fs volume to appear.
/etc/crypttab just mimic what's already there for the existing LUKS volume, but of course use the correct UUIDs supplied by blkid.
/etc/default/grub needs an additional rd.luks.uuid= to make systemd aware to expect it early boot, for example [2]. If you look in the existing /etc/default/grub you'll see something like: GRUB_CMDLINE_LINUX="rd.luks.uuid=luks-bbf5ebbd-d3f8-425e-9fc4-c48abd23bd8e.... So just add, anywhere in there, another rd.luks.uuid=luks-<uuid> including the uuid for the new luks volume. And then: grub2-mkconfig -o /boot/grub2/grub.cfg ##assumes a BIOS system which then creates a new grub.cfg with that addition.
That should be it. Definitely don't confuse UUIDs. The LUKS volume has a UUID, and the filesystem on that LUKS volume has its own UUID. They're not the same thing.
[1] https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/htm...
[2] [ 0.471569] localhost.localdomain systemd[1]: Expecting device dev-disk-by\x2duuid-cd8dda17\x2d82d2\x2d48d0\x2da1b4\x2d2e68c16a7cc4.device... [ 0.471584] localhost.localdomain systemd[1]: Expecting device dev-mapper-luks\x2dcd8dda17\x2d82d2\x2d48d0\x2da1b4\x2d2e68c16a7cc4.device... [ 3.255684] localhost.localdomain systemd[1]: Starting Cryptography Setup for luks-cd8dda17-82d2-48d0-a1b4-2e68c16a7cc4... [ 9.309257] localhost.localdomain systemd-cryptsetup[264]: Set cipher aes, mode xts-plain64, key size 512 bits for device /dev/disk/by-uuid/cd8dda17-82d2-48d0-a1b4-2e68c16a7cc4. [ 12.024581] localhost.localdomain systemd[1]: Found device /dev/mapper/luks-cd8dda17-82d2-48d0-a1b4-2e68c16a7cc4. [ 12.025339] localhost.localdomain systemd[1]: Started Cryptography Setup for luks-cd8dda17-82d2-48d0-a1b4-2e68c16a7cc4. [ 12.226048] localhost.localdomain kernel: btrfs: device label centos devid 1 transid 39 /dev/mapper/luks-cd8dda17-82d2-48d0-a1b4-2e68c16a7cc4 [ 13.701094] localhost.localdomain systemd[1]: Found device /dev/mapper/luks-cd8dda17-82d2-48d0-a1b4-2e68c16a7cc4. [ 13.727673] localhost.localdomain kernel: btrfs: device label centos devid 1 transid 39 /dev/mapper/luks-cd8dda17-82d2-48d0-a1b4-2e68c16a7cc4
On 03/05/2015 06:58 PM, Chris Murphy wrote:
On Thu, Mar 5, 2015 at 2:09 PM, Tim lists@kiuni.de wrote:
Hello list,
I bought a Thinkpad T420 and installed CentOS 7 recently.
I choosed to use lvm encryption for the entire volume group. It works so far.
But now I am planning to install a second hard disk. My thought is to create a new volume group on this additional disk.
But how can I integrate/do this according to the existing encryption so that it will be decrypted by the same passphrase I use at startup?
http://linux.die.net/man/5/crypttab
When you create a new entry in crypttab, you can use the 3rd field to point to a file that contains the passphrase for this new LUKS volume. In effect, one passphrase gives access to both drives.
You don't even need to do that. The init scripts try your passphrase on every encrypted volume. If that one passphrase unlocks everything, you're done. In a graphical boot, you don't even know which volume you are being prompted to unlock (and the order is not consistent).
On Thu, Mar 5, 2015 at 11:17 PM, Robert Nichols rnicholsNOSPAM@comcast.net wrote:
You don't even need to do that. The init scripts try your passphrase on every encrypted volume. If that one passphrase unlocks everything, you're done. In a graphical boot, you don't even know which volume you are being prompted to unlock (and the order is not consistent).
man systemd.special
cryptsetup.target A target that pulls in setup services for all encrypted block devices.
Hmm. I think it still needs a crypttab entry so this target knows to try to unlock it, and the volumes within need an fstab entry also if you want them automounted.
-
Chris Murphy -
Robert Nichols -
Tim