Difference between revisions of "User talk:Indigo"

From ArchWiki
Jump to: navigation, search
(drafting for Dm-crypt/Encrypting_an_Entire_System#Overview: span like this?)
(drafting for Dm-crypt/Encrypting_an_Entire_System#Overview: alternative (even simpler table layout))
Line 26: Line 26:
  
 
The following refers to [[Talk:Dm-crypt#Scenario_intros]], contributions welcome.  --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 21:03, 16 February 2014 (UTC)
 
The following refers to [[Talk:Dm-crypt#Scenario_intros]], contributions welcome.  --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 21:03, 16 February 2014 (UTC)
 +
 +
Version 1:
  
 
{| class="wikitable"
 
{| class="wikitable"
 
|-
 
|-
 
! rowspan="2"|Scenarios  
 
! rowspan="2"|Scenarios  
! colspan="2" | Description <br>of the universe and its orbit in itself.
+
! colspan="2" | Description  
 
!
 
!
 
|-
 
|-
Line 57: Line 59:
 
| colspan="2" | Usage of ''dm-crypt'' plain mode, i.e. without LUKS options for multiple keys, and a /boot on USB.   
 
| colspan="2" | Usage of ''dm-crypt'' plain mode, i.e. without LUKS options for multiple keys, and a /boot on USB.   
 
|-
 
|-
 +
| Data resilience for cases where a LUKS header may be damaged
 +
| High care to all encryption parameters is required<br>It is not possible to change the single encryption key 
 +
|-
 +
|}
 +
 +
 +
Version 2:
 +
{| class="wikitable"
 +
|-
 +
! Scenario<br>description
 +
!! width="30%" |Pros
 +
!! width="30%" |Cons
 +
|-
 +
| [[#Scenario 1]]<br>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
 +
|-
 +
| [[#Scenario 2]]<br>A single LUKS encrypted partition, partitioning flexibility is achieved by using LVM inside it.
 +
| Simple partitioning with knowledge of [[LVM]]<br>Only one key required to unlock all volumes<br>Easy resume-from-disk setup<br>partition layout not transparent when locked
 +
| LVM adds one additional mapping layer
 +
|-
 +
| [[#Scenario 3]]<br>This setup uses ''dm-crypt'' only after the LVM is setup.
 +
| LVM can be used to span multiple disks
 +
| Complex to maintain, changing logical volumes requires changing encryption mappers first<br>Individual volumes require different keys
 +
|-
 +
| [[#Scenario 5]]<br>Usage of ''dm-crypt'' plain mode, i.e. without LUKS options for multiple keys, and a /boot on USB. 
 
| Data resilience for cases where a LUKS header may be damaged
 
| Data resilience for cases where a LUKS header may be damaged
 
| High care to all encryption parameters is required<br>It is not possible to change the single encryption key   
 
| High care to all encryption parameters is required<br>It is not possible to change the single encryption key   
 
|-
 
|-
 
|}
 
|}

Revision as of 09:54, 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
#Scenario 1 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
#Scenario 2 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
#Scenario 3 This setup uses dm-crypt only after the LVM is setup.
LVM can be used to span multiple disks Complex to maintain, changing logical volumes requires changing encryption mappers first
Individual volumes require different keys
#Scenario 5 Usage of dm-crypt plain mode, i.e. without LUKS options for multiple keys, and a /boot on USB.
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
#Scenario 1
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
#Scenario 2
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
#Scenario 3
This setup uses dm-crypt only after the LVM is setup.
LVM can be used to span multiple disks Complex to maintain, changing logical volumes requires changing encryption mappers first
Individual volumes require different keys
#Scenario 5
Usage of dm-crypt plain mode, i.e. without LUKS options for multiple keys, and a /boot on USB.
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