Difference between revisions of "User talk:Indigo"

From ArchWiki
Jump to: navigation, search
(drafting for Dm-crypt/Encrypting_an_Entire_System#Overview)
(drafting for Dm-crypt/Encrypting_an_Entire_System#Overview)
Line 88: Line 88:
 
|-
 
|-
 
|}
 
|}
 +
 +
Version 1 might be preferable, if we want to have more verbose in the description.
 +
Version 2 is simpler, but space efficient.
 +
 +
I'd be content with (2) for the overview. Other opinions? --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 10:43, 17 February 2014 (UTC)

Revision as of 10:43, 17 February 2014

Feel free to leave comments about my wiki edits or other points of interest. --Indigo (talk) 17:43, 27 September 2012 (UTC)

Comments

sd-encrypt

I am writing this as I frequently edit disk encryption wiki pages here and want to gain some input on upcoming news and hopefully help to minimize disjunct editing:

Systemd is evolving a lot. One recent change has been the new systemd hook. It simplifies a lot of setups, but is not compatible with a number of older hooks. One of those is encrypt. Now User:brain0 is thankfully working on a new hook sd-encrypt to remedy that. While that has one big advantage of using systemd backend, i.e. systemd-cryptsetup-generator, to setup the encrypted devices, it also is not compatible in the kernel command line options. So, these and the mkinitcpio configuration advice have to be changed to show the new options on various pages.

Now how do we handle this on the various wiki pages on disk encryption? Imo a reasonable way would be to add a respective alternative for the mkinitcpio and bootloader sections of the disk encryption wiki pages. However, it would be good in my view to give a general advice on when and how to use the new hook. Likewise this should detail when the old encrypt should be used.

So, question (1): what should that general advice contain? E.g. which other hooks (a setup might need) are known not to be compatible with the systemd and, hence, sd-encrypt. Keyboard, keymap? (sd-vconsole I saw is going to be added). How about mdadm_udev, lvm and resume? Others?

Question (2): In my view it would be very preferable to have the general configuration advice in one place, so that the specific disk encryption pages do not have to go to lengths but can crosslink and just state the two alternatives where available. A good place for this should be Mkinitcpio, which can be referred to by the disk encryption pages. But the hooks are explained there very brief in a table. Other good options?

Question (3): I have not tried it, but I was wondering what the new option of having a /etc/crypttab.initramfs entails. What is a usecase where one might want to use that? The usual way of crypttab being parsed during boot is not affected by the change to sd-encrypt I reckon.

Thanks for input on 1,2,3 and other points you might see. --Indigo (talk) 20:30, 4 October 2013 (UTC)

Ad (1): Basically all runtime hooks (those in /usr/lib/initcpio/hooks/) are not supported by the systemd hook. I guess they would have to be ported to systemd units to be actually executed from the initrd. Some install hooks (those in /usr/lib/initcpio/install/) are probably unsupported too. -- Lahwaacz (talk) 06:36, 5 October 2013 (UTC)
Thanks for the input. I am hoping to collect such so that we can make an appropriate wiki task for it. Of the runtime hooks shutdown appears to work. One major question appears to be the status for LVM and mdadm/_udev. Relevant link: [1] --Indigo (talk) 13:16, 5 October 2013 (UTC)
Quick update: I did some testing of sd_encrypt and it turned out that /etc/crypttab is not parsed automatically. While the systemd activation for the crypt devices can be manually setup, it is unclear whether this is expected behaviour or a bug. The above quoted bug report has some more detail. --Indigo (talk) 20:41, 22 October 2013 (UTC)

drafting for Dm-crypt/Encrypting_an_Entire_System#Overview

The following refers to Talk:Dm-crypt#Scenario_intros, contributions welcome. --Indigo (talk) 21:03, 16 February 2014 (UTC)

Version 1:

Scenarios Description
Pros Cons
Simple partition layout with LUKS A simple partitioning and straight-forward set-up for a fully LUKS encrypted root.
Simple partitioning Inflexible; all disk-space to be encrypted has to be pre-allocated
LVM on LUKS A single LUKS encrypted partition, partitioning flexibility is achieved by using LVM inside it.
Simple partitioning with knowledge of LVM
Only one key required to unlock all volumes
Easy resume-from-disk setup
partition layout not transparent when locked
LVM adds one additional mapping layer
LUKS on LVM This setup uses dm-crypt only after the LVM is setup. It is the only scenario where an encrypted volume (partition) can span over one disk.
LVM can be used to span multiple disks Complex to maintain, changing logical volumes requires changing encryption mappers too
Individual volumes require different keys
plain dm-crypt Usage of dm-crypt plain mode, i.e. without LUKS options for multiple keys. This scenario also uses USB devices for /boot key storage.
Data resilience for cases where a LUKS header may be damaged High care to all encryption parameters is required
It is not possible to change the single encryption key


Version 2:

Scenario
description
Pros Cons
Simple partition layout with LUKS
shows a basic and straight-forward set-up for a fully LUKS encrypted root.
Simple partitioning Inflexible; all disk-space to be encrypted has to be pre-allocated
LVM on LUKS
achieves partitioning flexiblity by using LVM inside a single LUKS encrypted partition.
Simple partitioning with knowledge of LVM
Only one key required to unlock all volumes
Easy resume-from-disk setup
partition layout not transparent when locked
LVM adds one additional mapping layer
LUKS on LVM
uses dm-crypt only after the LVM is setup. This is the only scenario where an encrypted volume (partition) can span over one disk.
LVM can be used to span multiple disks Complex to maintain, changing logical volumes requires changing encryption mappers too
Individual volumes require different keys
plain dm-crypt
uses Usage of dm-crypt plain mode, i.e. without LUKS options for multiple keys. This scenario also uses USB devices for /boot key storage.
Data resilience for cases where a LUKS header may be damaged High care to all encryption parameters is required
It is not possible to change the single encryption key

Version 1 might be preferable, if we want to have more verbose in the description. Version 2 is simpler, but space efficient.

I'd be content with (2) for the overview. Other opinions? --Indigo (talk) 10:43, 17 February 2014 (UTC)