Difference between revisions of "Talk:Dm-crypt/Drive preparation"

From ArchWiki
Jump to navigation Jump to search
 
(Partitioning: re)
Line 69: Line 69:
 
* If the encrypted layer is created on top of LVM/RAID devices, it will still be possible to reorganize the file systems in the future, but with added complexity, since the encryption layers will have to be adjusted accordingly; moreover, separate passphrases or keys will be required to open each encrypted device. This, however, is the only choice for systems that need encrypted file systems to span multiple disks.
 
* If the encrypted layer is created on top of LVM/RAID devices, it will still be possible to reorganize the file systems in the future, but with added complexity, since the encryption layers will have to be adjusted accordingly; moreover, separate passphrases or keys will be required to open each encrypted device. This, however, is the only choice for systems that need encrypted file systems to span multiple disks.
  
<h3>Btrfs</h3>
+
<h3>Btrfs subvolumes</h3>
  
Finally, it is worth mentioning [[Btrfs]]'s built-in [[Btrfs#Sub-volumes|Subvolume-Feature]] that fully replaces the need for LVM if no other filesystems are required. An encrypted swap is not possible this way and swap files are [https://btrfs.wiki.kernel.org/index.php/FAQ#Does_btrfs_support_swap_files.3F not supported] by btrfs up to now.
+
Finally, it is worth mentioning [[Btrfs]]'s built-in [[Btrfs#Sub-volumes|subvolumes feature]] that fully replaces the need for LVM if no other filesystems are required. An encrypted swap is not possible this way and swap files are [https://btrfs.wiki.kernel.org/index.php/FAQ#Does_btrfs_support_swap_files.3F not supported] by btrfs up to now.
  
 
</div>
 
</div>
Line 82: Line 82:
 
::::::For [[Dm-crypt/Encrypting_an_entire_system#Overview]] - we prepared it to guide towards the scenarios on the subpage. Yes, it mentions partitioning as well, but mostly with a view on the encryption and not the physical devices. I'd leave it in place. I am on the road and won't have time again until next week. Neat stylish dash border by the way!! I hope that becomes the next gen "note" template :) (likewise for the "tip" template in fresh green dashes)
 
::::::For [[Dm-crypt/Encrypting_an_entire_system#Overview]] - we prepared it to guide towards the scenarios on the subpage. Yes, it mentions partitioning as well, but mostly with a view on the encryption and not the physical devices. I'd leave it in place. I am on the road and won't have time again until next week. Neat stylish dash border by the way!! I hope that becomes the next gen "note" template :) (likewise for the "tip" template in fresh green dashes)
 
::::::--[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 18:13, 7 May 2014 (UTC)
 
::::::--[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 18:13, 7 May 2014 (UTC)
 +
 +
:::::::Great, I'm merging the draft into the article then.
 +
:::::::About [[Dm-crypt/Encrypting_an_Entire_System#Expanding_LVM_on_multiple_disks]] I'd like to discuss moving it to [[Dm-crypt/Specialties]] and just linking it from [[Dm-crypt/Encrypting_an_Entire_System#LVM on LUKS]].
 +
:::::::About [[Dm-crypt/Encrypting_an_entire_system#Overview]] ok, let's leave it where it is.
 +
:::::::(About the dashed box yes, it looks very clean and simple, however I'm quite happy with the current note/tip/warning templates too, maybe-just-maybe they could be given lighter colors; you can still open a discussion in [[Help talk:Style]] if you want, and see if other users are interested)
 +
:::::::Well, have a safe trip! Let's continue when you're back :) -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 09:44, 8 May 2014 (UTC)

Revision as of 09:44, 8 May 2014

Partitioning

[Moved from User talk:Teateawhy#dm-crypt/drive preparation -- Kynikos (talk) 09:05, 8 May 2014 (UTC)]

Hi, I'm unsure about cutting that part of the subpage as much as did with [1]

The idea about the scenario subpages Dm-crypt/Encrypting an Entire System and Dm-crypt/Encrypting a Non-Root File System is that these primarily give the installation instructions and for details and (some) general points refer to the other subpages, i.e. general info on partitioning should be in this section. Clearly we have to find the right balance of what we cover in Dm-crypt/Drive_Preparation#Partitioning because it is linked to the subsequent encryption and where we can link out to the real articles on partitioning. But linking from here to the scenario pages for explanation, like you did in the edit, is against the structure we want for the subpages (we rather want to merge more of the general info from the LVM/LUKS partitioning examples here).

--Indigo (talk) 23:19, 4 May 2014 (UTC)

> I'm unsure about cutting that part of the subpage as much as did with
Yes, the edit looks like a lot of content was lost, but to my defense the content was not formulated concise. A lot of words were used to say basically 3 things:
1. You can combine RAID and LVM together with dm-crypt, stacking block devices on each other as you want.
2. You can create partitions as you want and encrypt some of them, leaving others unencrypted.
3. You need a seperate unencrypted partition for /boot for full system encryption.
All these 3 points are found in the new version.
> general info on partitioning should be in this section
Yes, i agree. Is there any "general info" missing besides above 3 points?
>But linking from here to the scenario pages for explanation, like you did in the edit, is against the structure we want for the subpages
But we can not give any information about the partition layout without seperating it into sections depending on what kind of encryption is wanted. So we need another 4 or more sub-sections for:
  • Partition layout when using full system encryption
  • Partition layout when using LUKS on LVM
  • Partition layout when using LVM on LUKS
  • Partition layout when using LVM on RAID on LUKS ...
I think that it is easier to include the information about the partition layout in the relevant articles like Dm-crypt/Encrypting an Entire System, instead of making sub-sections on the page Dm-crypt/Drive_Preparation#Partitioning.
-- Teateawhy (talk) 23:50, 4 May 2014 (UTC)
Sure it is easier, but that's not the point. Before Kynikos kicked off the re-structure and merge of the main old LUKS article and the newer ones, there was a long talk about how to perform a merge but not end up with an article twice as long as the LUKS page. Then it was decided to use "installation scenarios" and merge all the commmon content (incl. general info about partitioning) to subpages and link to them (see Talk:Dm-crypt#New_idea for the end of the discussion. We went a long way with this, but especially for the sections in Dm-crypt/Encrypting an Entire System it is not completed yet (and great you did edits to them). No problem with making this subsection more concise, but by linking back to the scenarios "for more info" you basically make it necessary to be more descriptive per scenario, what is exactly contrary to the intention of the structure.
If you still disagree, please move this talk item to Talk:Dm-crypt/Drive_Preparation. thanks.
--Indigo (talk) 10:49, 5 May 2014 (UTC)
I still have to look into the edit, but Indigo is right, it's the scenarios that must depend on the other subpages for details, not vice versa, otherwise we'll start re-encouraging people to add details in the wrong place. I'll try to give a more accurate reply after reviewing the edit. -- Kynikos (talk) 11:06, 5 May 2014 (UTC)
Ok, after examining the matter in detail, I've realized that dm-crypt/Drive Preparation is linked from the other subpages only when mentioning the secure drive erasure, while the "Partitioning" section is never referred to from them. When talking about partitioning, dm-crypt/Encrypting an Entire System always points the users directly to Partitioning, and the fact that /boot has to be unencrypted is always stated there anyway (and couldn't be otherwise).
Teateawhy does make a point when he says that partitioning is strongly dependent on the chosen system configuration and would require in practice mentioning the various scenarios in dm-crypt/Drive Preparation, thus increasing - and not decreasing - duplication of content. Put another way, I can't see a way to deal with partitioning in a "generic" way there.
This is why I propose to simply remove Dm-crypt/Drive Preparation#Partitioning, and let Partitioning, LVM and RAID be the detailed, generic articles that the scenarios should point the users to for more precise information (as they already do). At that point, Dm-crypt/Drive Preparation should probably be better renamed to Dm-crypt/Secure drive erasure or similar, also adding Securely wipe disk as a related article there, so as to remark the different scopes of the two articles.
-- Kynikos (talk) 15:35, 6 May 2014 (UTC)
I don't like that proposal to remove it: A Dm-crypt/Secure drive erasure would be rather stub and pretty similar to Securely wipe disk. Drive preparation continues with partitioning in any scenario, it's the logical step so Dm-crypt/Drive Preparation#Partitioning should be kept IMO.
I am fully with Teateawhy and you on that we don't want to create further duplication. Couple more thoughts to the contrary about why I am unsure the current state is the best way forward:
Ad 1) In my view the previous partitioning skeleton the subpage inherited from the LUKS page [2] already had a "generic" way of approaching partitioning with dm-crypt by (a) mentioning basics first, (b) distinguishing between single- and multiple disks (generic angle to physical level) and (c) miscellaneous (LVM placeholder section and btrfs tip).
Ad 2) What was purged (because it was too abstract, yes) on the LUKS merge was the generic info in the section on how dm-crypt and the other mappers (LVM now, perhaps RAID later) layer/work together. I'd say it is good to have the #partitioning subsection for that. It is too specialised to be covered in Partitioning, LVM and RAID and better placed in [3] pointing to the other pages for details as was. Maybe a more approachable way for it is to add another couple ascii charts next year. Maybe readers can be expected to abstract that from the scenarios already. I don't know.
Ad 3) If we leave the Dm-crypt/Drive Preparation#Partitioning as is, we loose out a place to merge still existing partitioning generics (e.g. (1) One could argue Dm-crypt/Encrypting_an_Entire_System#Expanding_LVM_on_multiple_disks serves no purpose for the initial installation scenario, may not be lost, but may be a good to exemplify mapper specifics for the LVM bits in Dm-crypt/Drive Preparation#Partitioning.
Ad 4) Minor: We also loose a place to point out existing miscellaneous issues in context (example the btrfs tip in [4], ever thought about dm-crypt on hybrid drives?).
Summarising: I am against removing #partitioning, but if you both think we cover (2) and (3) appropriately for wiki readership for now, I am deal and we can close this.
--Indigo (talk) 23:07, 6 May 2014 (UTC)
About 1) I'll reconsider my idea then, and instead propose the following section:

Partitioning

This section only applies when encrypting an entire system. After the drive(s) has/have been securely overwritten, a proper partitioning scheme will have to be accurately chosen, taking into account the requirements of dm-crypt, and the effects that the various choices will have on the management of the resulting system.

It is important to note from now that in every case there has to be a seperate partition for /boot that must remain unencrypted, because the bootloader needs to access the /boot directory where it will load the initramfs/encryption modules needed to load the rest of the system (see mkinitcpio for details). If this raises security concerns, see dm-crypt/Specialties#Securing the unencrypted boot partition.

Another important factor to keep into account is how the swap area and system suspension will be handled, see dm-crypt/Swap encryption.

Physical partitions

In the simplest case, the encrypted layers can be based directly on the physical partitions; see Partitioning for the methods to create them. Just like in an unencrypted system, a root partition is sufficient, besides another for /boot as noted above. This method allows deciding which partitions to encrypt and which to leave unencrypted, and works the same regardless of the number of disks involved. It will also be possible to add or remove partitions in the future, but resizing a partition will be limited by the size of the disk that is hosting it. Finally note that separate passphrases or keys are required to open each encrypted partition, even though this can be automated during boot using the crypttab file, see Dm-crypt/System configuration#crypttab.

Stacked block devices

If more flexibility is needed, though, dm-crypt can coexist with other stacked block devices like LVM and RAID: encrypted containers can either reside below or on top of other stacked block devices:

  • If the LVM/RAID devices are created on top of the encrypted layer, it will be possible to add, remove and resize the file systems under the same encrypted partition liberally, and only one key or passphrase will be required for all of them. Since the encrypted layer resides on a physical partition, though, it will not be possible to exploit the ability of LVM and RAID to span multiple disks.
  • If the encrypted layer is created on top of LVM/RAID devices, it will still be possible to reorganize the file systems in the future, but with added complexity, since the encryption layers will have to be adjusted accordingly; moreover, separate passphrases or keys will be required to open each encrypted device. This, however, is the only choice for systems that need encrypted file systems to span multiple disks.

Btrfs subvolumes

Finally, it is worth mentioning Btrfs's built-in subvolumes feature that fully replaces the need for LVM if no other filesystems are required. An encrypted swap is not possible this way and swap files are not supported by btrfs up to now.

Perhaps we could merge Dm-crypt/Encrypting_an_entire_system#Overview there?
About 2), 3) and 4) I'm sorry but I'll have to answer tomorrow. Let's really consider moving this discussion to Talk:Dm-crypt/Drive preparation, otherwise Teateawhy will receive notifications every time we post something (sorry) :)
-- Kynikos (talk) 16:28, 7 May 2014 (UTC)
Thanks for reconsidering and the re-worked text above. It basically covers (1), (2) and (4) already, I'd say. For (3) I am unsure myself whether it is useful to merge the example I gave #Expanding_LVM_on_multiple_disks to #partitioning. it is a bit tricky to pull it out the scenario and into context in #partitioning. Plus the scenario was chosen to cover an LVM over multiple disks somewhat.
For Dm-crypt/Encrypting_an_entire_system#Overview - we prepared it to guide towards the scenarios on the subpage. Yes, it mentions partitioning as well, but mostly with a view on the encryption and not the physical devices. I'd leave it in place. I am on the road and won't have time again until next week. Neat stylish dash border by the way!! I hope that becomes the next gen "note" template :) (likewise for the "tip" template in fresh green dashes)
--Indigo (talk) 18:13, 7 May 2014 (UTC)
Great, I'm merging the draft into the article then.
About Dm-crypt/Encrypting_an_Entire_System#Expanding_LVM_on_multiple_disks I'd like to discuss moving it to Dm-crypt/Specialties and just linking it from Dm-crypt/Encrypting_an_Entire_System#LVM on LUKS.
About Dm-crypt/Encrypting_an_entire_system#Overview ok, let's leave it where it is.
(About the dashed box yes, it looks very clean and simple, however I'm quite happy with the current note/tip/warning templates too, maybe-just-maybe they could be given lighter colors; you can still open a discussion in Help talk:Style if you want, and see if other users are interested)
Well, have a safe trip! Let's continue when you're back :) -- Kynikos (talk) 09:44, 8 May 2014 (UTC)