:: This is new territory for me, but I want to implement this topic myself soon. I'll start with removing some duplicated content. [[User:T1nk3r3r|T1nk3r3r]] ([[User talk:T1nk3r3r|talk]]) 07:25, 16 June 2013 (UTC)

:: This is new territory for me, but I want to implement this topic myself soon. I'll start with removing some duplicated content. [[User:T1nk3r3r|T1nk3r3r]] ([[User talk:T1nk3r3r|talk]]) 07:25, 16 June 2013 (UTC)

−

== Luks and suspend2 ==

+

==<s> Splitting sections into separate pages </s>==

−

Would it be worth adding a section on opening encrypted drives from the kernel command line, or more specifically on combining luks and suspend2? As far as I can tell opening a swap partition from crypttab doesn't make it available in time to resume from, but adding the following to a lilo append option does:

−

resume2=swap:/dev/mapper/swap cryptdevice=/dev/sda2:swap

−

I'm not sure if this is the correct/best way of doing this, though, and didn't see other documentation.

−

−

== Proposed update of the section 'Storing the key between MBR and 1st partition' ==

I tried to setup automatic mount of my LUKS encrypted {{ic|/home}} using a keyfile stored between MBR and first partition header of my USB key following this wiki page and realized that it didn't work out because the howto is incomplete. I had to manually go through the encrypt hook to figure out what it does. To save other users this tiresome work that cost me hours until all finally worked out the way I wanted it I propose to update the mentioned section in the following way. Suggestions welcome. Maybe it should be noted in the parent section that {{ic|/etc/crypttab}} conflicts with using the howto presented here.

−

|}

−

−

Add the temporary keyfile we created before with cryptsetup:

−

cryptsetup luksAddKey /dev/hda3 secretkey

−

−

That should return you output like this:

−

Enter any LUKS passphrase:

−

key slot 0 unlocked.

−

Command successful.

−

−

Next you'll have to write the key directly between MBR and first partition.

−

−

WARNING: you should only follow this step if you know what you are doing - '''it can cause data loss and damage your partitions or MBR on the stick!'''

−

−

If you have a bootloader installed on your drive you have to adjust the values. E.g. GRUB needs the first 16 sectors, you would have to replace seek=4 with seek=16; otherwise you would overwrite parts of your GRUB installation. When in doubt, take a look at the first 64 sectors of your drive and decide on your own where to place your key.

OFFSET and SIZE match in this example, but this is coincidence - they can differ (and often will). An other possible example could be (if you use skip=16 in the 'dd' command above to protect the bootloader)

The encrypted block device BLOCKDEVICE will then be mapped to {{ic|/dev/mapper/MAPPING_TARGET}}

−

−

'''Note:''' You will _not_ need to have {{ic|/etc/crypttab}} setup for this device then (but maybe you want to use it for other encrypted devices where you want to enter the passphrase manually or e.g. use a keyfile stored on this afterwards decrypted partition)! But don't forget to activate the ''encrypt'' hook in {{ic|/etc/mkinitcpio.conf}} (_before_ the ''filesystems'' hook)

−

−

That's all, reboot and have fun! And look if your partitions still work after that ;-).

−

−

---

−

: I removed the section referenced above today with [https://wiki.archlinux.org/index.php?title=Dm-crypt_with_LUKS&diff=273959&oldid=273945 this] edit. The method described of storing a key was in the past maybe more often used than today. However, it was always dangerous for the partition table and the secrets. There are plenty better options. If someone sees reasons to keep this (and maybe also why we should re-add it to the wiki), please give some input here in talk. Otherwise I'll propose to close this discussion and the related one below sometime later. Thanks. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 19:24, 1 September 2013 (UTC)

−

−

== Decryption of root during boot with the assistance of UDEV when key is stored on USB drive between MBR and 1st Partition ==

−

The instructions in the wiki were very helpful but a bit confusing/lacking when it comes to getting Decryption via USB keyfile stored between MBR and 1st Partition.

−

−

[[System_Encryption_with_LUKS#Storing_the_key_between_MBR_and_1st_partition]] makes references to {{ic|/dev/usbkey}} but the previous instructions aren't entirely clear on how to ensure your usb drive can always be found at this location.

−

−

When modifying your bootloader you will be unable to use ''/dev/disk/by-uuid'' because you are not referencing a filesystem. You wouldn't want to use ''/dev/sd[x]'' because this can and will change depending on what other drives and media you have connected during boot. The best bet is to create a udev rule that will exist in early userspace to alias your usb drive to an arbitrary name, in this case "usbkey". The rule must be added to the initial ramdisk so it can be read and processed to alias your drive at ''/dev/usbkey'' before root decryption is attempted via the key hidden on the drive.

−

−

[[System_Encryption_with_LUKS#Using_udev]] runs you through the initial steps you need to create a basic rule based on the USB drive's serial number. That is the very same rule I used. I named the rules file "62-usbkey.rules" and placed it in {{ic|/etc/udev/rules.d/}}.

−

−

Now modify {{ic|/etc/mkinitcpio.conf}}, look for the "FILES" section and add the udev rule that you created above:

−

−

<pre>

−

# FILES

−

# This setting is similar to BINARIES above, however, files are added

−

# as-is and are not parsed in any way. This is useful for config files.

−

# Some users may wish to include modprobe.conf for custom module options

−

# like so:

−

# FILES="/etc/modprobe.d/modprobe.conf"

−

FILES="/etc/udev/rules.d/62-usbkey.rules"

−

</pre>

−

−

Run ''mkinitcpio'' ala [[Mkinitcpio#Image_creation_and_activation]] and rebuild your ramdisk with the new udev rule you've included. You can now continue to follow the instructions in [[System_Encryption_with_LUKS#Storing_the_key_between_MBR_and_1st_partition]] to modify your bootloader and substitute references to "usbkey" to whatever you named your drive alias above.

−

−

[[User:S0ma|S0ma]] 13:48, 16 December 2011 (EST)

−

−

== Feature of Grub2 to decrypt /boot ==

−

Original comment by Chehri on 8.6.13, moved from [Dm-crypt_with_LUKS#Creating_Disk_Partitions] to here:

−

It is now possible to include /boot on a LUKS container thanks to grub 2.00. Zack Buhman (buhman) has proposed a [https://bugs.archlinux.org/task/31877 patch] which allows this. This allows kexec to be used to start a new kernel in remote situations. It also removes any possibility of the kernel being tampered with (though grub is still unencrypted; store on a removable drive for added safety).

−

:Interesting patch/idea. I moved the out-of-date box here to discussion first for the following reason:

−

:The patch you link to is proposed and not even commented on, i.e. it is not in the encrypt hook. Having it there as out-of-date in this general Luks section at the beginning will confuse new readers totally. Another reason is that the Luks page in that section is general, not grub specific. Everything there can be setup with standard Arch [core], i.e. also Syslinux.

−

:I hope you agree to that, if not let's please discuss it. Thanks.

−

−

:I think the best way forward for the contribution would be to draft a subsection under 3.2 (e.g. as 3.2.7), we have different hook modifications there for the swap. (later on there is a specific section on encrypted keyfiles too where it might fit well). Once the section is complete and accurate to modify a standard Arch, one could link to it from the general section above. Once something like that goes into the vanilla Arch-encrypt hook, it should definetely be described earlier. Another (different) point would be to discuss the pros/cons security-wise of such a modification a bit. That could be done in the subsection too. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 17:35, 8 June 2013 (UTC)

−

−

==<s>Encrypting a LVM setup (ex section 8) </s>==

−

The content in sections 8.1 to 8.4 has to be updated, particularly the AIF and /etc/rc.conf references must go. Since another user created a "Encrypted LVM" stub article, which (arguably) has style problems but is a good read otherwise, I see two alternatives for section 8:

−

−

A. (1) Remove all outdated install instructions from 8.1 to 8.4, (2) link to the "Encrypted LVM" stub article for users looking for verbose LVM/LUKS install instructions, but (3) keep the LVM short instructions in this article too as a quick reference section. Next, (4) the "Encrypted LVM" should then properly link back properly to the "LUKS" page (particularly to the explanations about the LUKS options)!

−

−

B. The second option would be to (5) move the stub article here into section 8, but this would require a major work to make it fit with the rest of the page (double content, a lot of linking up/down).

−

−

Both can be done, I prefer A, also because the LUKS page itself is rather huge already. In fact I added links over to that stub page a while back so that new users find it so noone stumbles over /arch/setup et al.

−

Maybe you have another idea than A or B. Opinions? --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 20:16, 16 July 2013 (UTC)

−

−

:Yep, if you could take the time to implement A it would be a great improvement. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 07:42, 20 July 2013 (UTC)

−

::Glad you approve. I have done a re-work today of that; could not wait somehow. Would be good, if someone has a look over it in case I missed out on something. The editing was not that much, more trying not to loose great content which still applies. Still missing is A(4) from above (backlinking from the stub page) and removing the merge-tag in the section (ex sec 8). I also moved some sections to get connected content together (please check TOC). I hope it is not only better in my view. Anyone missing something can find the original section 8 (LUKS-LVM) pasted on my user-page for the time being. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 17:44, 20 July 2013 (UTC)

−

:::I've taken the time to check your edits (you made it a lot easier by properly commenting really everything), and I like what you've done, it's a very good job!! :)

−

:::Yes, A(4) still has to be done, while about removing the Merge template I don't know, maybe "Encrypting a LVM setup" can still be merged to [[Encrypted LVM]], what do you think? (This would be kind of a C. alternative, opposed to B.).

::::Thanks for taking the time to check it! Currently I would leave it at A as opposed to C, for two reasons: Firstly, the [[Encrypted LVM]] works/reads well with the two main setup options shown. Then it picks up different important subjects (gpt, multiple disks) but lacks some of the setup the LVM example this page has (e.g. nowhere on [[Encrypted LVM]] you find the word "swap"). So a merge would entail rework of the page in order not to loose content in the merge. Or even adding another example there (better not imho). Secondly, the other installation instructions on this page [[LUKS#Encrypting_a_system_partition]] are deliberately describing the simplest encrypted setup. So, the LVM install example here adds options which a reader might want to mix in (e.g. swap, separate /home; maybe those options are worth a mention revisiting it). I think about it again, but currently I would consider the current split easier comprehensible for both pages and outweighing the duplicity (of LVM commands). Any further LVM install tricks should of course be on the other pages, LUKS tricks here. Thoughts? --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 21:06, 21 July 2013 (UTC)

−

:::::All right, you convinced me, let's leave it there, thanks again ^^ (this discussion will stay open until all the remaining points are implemented) -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 10:06, 22 July 2013 (UTC)

−

::::::Okies, I added three (sublime:p) link-backs in the [[Encrypted LVM]] howto where I would consider LUKS pointers useful at the least. I will surely revisit the page, but at current A(4) is done from my view. Maybe the merge tag can go for now. Next bits of re-work here on the page may be further streamlining the starting section with better guidance through the page, but that's out-of-bounds this discussion (more the first point on this page). I also marked some old discussions here as closed. It would be nice if you or someone else could look at them sometime and rm as appropriate. Thanks. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 20:04, 25 July 2013 (UTC)

−

:::::::Well done, you can remove the merge template and close this discussion then (don't worry, all closed discussions ''are'' removed sooner or later). If you will want to discuss more changes to this article, do not hesitate to open another thread. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 04:51, 27 July 2013 (UTC)

−

−

==Merge with "plain dm-crypt without LUKS"==

−

[[User:Develper|Develper]] has written a new A-Z howto for setting up a plain dm-crypt system, a subject not covered yet in our wiki. It is discussed how to effectively use common content for the benefit of the articles on disk crypto. If you have ideas or thoughts about it, head over: [[Talk:Plain_dm-crypt_without_LUKS#Merge]]

Does anyone else feel that 11,305 words is too long for a single article? I'd like to propose splitting this article across multiple pages. If MediaWiki's Subpages feature is enabled, this might be a good time to use it. The article contains many sections that are not greatly related to one another. For example, does one really need to know how to (section 6) encrypt a loopback filesystem or (section 3.2) use a keyfile in order to (section 3.3) encrypt a swap partition? It's common to encrypt a swap partition without using a keyfile or an encrypted loopback filesystem, so why are they discussed in the same article?

Does anyone else feel that 11,305 words is too long for a single article? I'd like to propose splitting this article across multiple pages. If MediaWiki's Subpages feature is enabled, this might be a good time to use it. The article contains many sections that are not greatly related to one another. For example, does one really need to know how to (section 6) encrypt a loopback filesystem or (section 3.2) use a keyfile in order to (section 3.3) encrypt a swap partition? It's common to encrypt a swap partition without using a keyfile or an encrypted loopback filesystem, so why are they discussed in the same article?

Line 172:

Line 59:

::::::::::::Great, I will answer you there then. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 11:37, 18 November 2013 (UTC)

::::::::::::Great, I will answer you there then. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 11:37, 18 November 2013 (UTC)

+

+

::::::::::::Just to make it as clear as possible, [[User:Kynikos/Dm-crypt with LUKS]] has "moved" to <s>[[Dm-crypt with LUKS/draft]]</s> and [[User talk:Kynikos/Dm-crypt with LUKS]] has moved to <s>[[Talk:Dm-crypt with LUKS/draft]]</s>. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 14:00, 18 November 2013 (UTC)

:::::::::::::So what have we decided, exactly? I see there's now a [[Dm-crypt]] page with subpages. Is that where sections from this page are going to be moved? What about the merge from section 7 to [[Encrypted LVM]] that [[User:Kynikos]] mentioned? Is that still happening, or are we going to make a [[Dm-crypt/Encrypted LVM]] subpage instead and merge [[Encrypted LVM]] into it? I'm willing to help, but I'm not sure as to what I should be doing.

+

::::::::::::::Have a look at [[Talk:Dm-crypt#New_idea]] for your questions and the new plan, and then the [[Dm-crypt]] subpages. There's plenty of stuff to do to implement it to plan. If you are unsure how to help, look for the 'accuracy' and 'expansion' tags for example. Would be great, if you want to join in. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 19:35, 6 December 2013 (UTC)

+

+

:::::::::::::::I'd only like to add that [[Encrypted LVM]] is already merged into the new [[dm-crypt/Encrypting an Entire System]], it's only a matter of properly moving duplicated content to the other subpages of [[dm-crypt]]. Of course any help is really welcome, as there's still a lot to do! -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 02:50, 7 December 2013 (UTC)

The philosophy behind the <s>current</s> old structure was to try to generalize the various steps for encrypting an entire system or a device and managing it, however we've noticed it's kind of hard. A new idea for reducing duplication of content while maintaining, if not improving, readability, would be to <s>rename the "/Examples" subpage to "/Common Scenarios" and move it to first place in [[Dm-crypt with LUKS/draft]], so it's used</s> use the [[dm-crypt#Common scenarios]] section as the starting point by the readers. It should contain the most common uses for encryption, which IMO are:

+

+

*[[dm-crypt/Encrypting a Non-Root File System]]

+

**partition

+

**loopback

+

*[[dm-crypt/Encrypting an Entire System]]

+

**plain dm-crypt (merge [[Plain dm-crypt without LUKS]], done)

+

**dm-crypt + LUKS (no LVM)

+

**LVM on LUKS (merge [[Encrypted LVM]], done)

+

**LUKS on LVM (merge [[Encrypted LVM]], done)

+

**(I think it would be really cool if we could also include an example with software RAID)

+

+

Each of those scenarios should be mostly a stripped sequence of commands with short descriptions that should link to generic sections in the other subpages of <s>[[Dm-crypt with LUKS]]</s> [[dm-crypt]], pointing out all the particular suggested adaptations that apply to that particular scenario.

+

+

The idea is quite clear in my mind, I hope I've managed to explain it well enough, I'll try to put it into practice and see if it raises major problems.

EDIT: since [[Plain dm-crypt without LUKS]] would be merged here, the main article should be just renamed to [[dm-crypt]]. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 03:09, 23 November 2013 (UTC)

:Plenty of stuff to do, yet: Taking for granted we want an additional example with RAID sometime, it might be worth considering to split [[dm-crypt/Encrypting an Entire System]] into a subpage for (e.g.) [[dm-crypt/Encrypting a single disk system]] and [[dm-crypt/Encrypting a system across multiple disks]] scenarios. The latter covering "LUKS on LVM" and said RAID. Main reason: page length. If you agree, let's better do it now. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 12:11, 8 December 2013 (UTC)

+

+

::Not a bad idea at all! However IMHO the proposed titles are a bit misleading: I would go for [[dm-crypt/Encrypting a System on Physical Devices]] and [[dm-crypt/Encrypting a System on Virtual Devices]], in fact you ''can'' use multiple physical disks in every case if you want. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 03:48, 9 December 2013 (UTC)

+

::EDIT: Note that the history of [[dm-crypt/Encrypting an Entire System]] should be preserved by ''moving'' it to one of the two titles, and then (or before) splitting the other page. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 03:49, 9 December 2013 (UTC)

+

:::+1 to your edit, I learned that from watching. The one letdown of this whole fun exercise is that the wiki engine does not seem to support basic content splits and joins preserving history. Anyhow, we might as well just keep it in mind and consider splitting it later (when there is something about RAID). Funnily, I find the use of "physical" (all blockdevices are on one) and "virtual" (suggests a qcow device) as differentiator not totally clear too. Let's meditate over it again until someone has another snappy idea. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 23:16, 9 December 2013 (UTC)

+

===Scenario intros===

+

I want to bring up another contexual point: You put in 'expansion' tags at the beginning of each section of the scenario page to "Compare to the other scenarios with advantages/disadvantages.". If I understand those tags correctly, you have [[Dm-crypt/Encrypting_an_Entire_System#Plain_dm-crypt]] in mind as an example. Yes, we want a common structured intro for each scenario, but I'd like it better to be just shortly descriptive regarding the scenario content. For example a para introducing the setup, followed by an ascii chart of the disk layout used (as per [[Dm-crypt/Encrypting_an_Entire_System#Preparing_the_logical_volumes]] example), followed by another sentence or two max. Remember the core of your scenario idea was to cut verbose in the scenario down as much as possible. A small comparison of the section scenarios may be suitable as the first subpage intro itself, anything more better be linked (pros/cons of disk layouts in [[Dm-crypt/Drive_Preparation#Partitioning]], scenario specific pros/cons of encryption modes in [[Dm-crypt/Device_Encryption#Encryption_options_with_dm-crypt]], general ones should be in: [[Disk_encryption#Comparison_table]] anyway, ..). --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 23:16, 9 December 2013 (UTC)

+

+

:I added intros on [[Dm-crypt/Encrypting_an_Entire_System]] and [[Dm-crypt/Encrypting_a_non-root_file_system]]. Is that similar to what you were going for? I really want to emphasize the importance of keeping these introductions concise. It's easy to write about use case after use case, but let's not forget why we refactored [[Dm-crypt with LUKS]] in the first place. Even [[Dm-crypt/Encrypting_an_Entire_System]] has gotten rather long and disorganized already, but that's a discussion for its own talk page. [[Dm-crypt]] has a nice layout so far, and it is definitely more readable than [[Dm-crypt with LUKS]]. --[[User:EscapedNull]]

+

+

::@Indigo: I approve 100% what you said: a single, small comparison section is what we need!

+

::@EscapedNull (please remember to sign your edits in talk pages, use <nowiki>~~~~</nowiki>): I think you're referring to [https://wiki.archlinux.org/index.php?title=Dm-crypt&diff=287479&oldid=286255 this] edit on the [[dm-crypt]] page; honestly those intros, despite being very clear and well written, are indeed too long for that page, as you note yourself: the intended size of those intros was like the ones in [[Dm-crypt#Swap device encryption]] or [[Dm-crypt#Specialties]], they should just sum up very briefly what's contained in each subpage. I wouldn't like to just throw your work away, I'd rather move it to a more suitable place in some of the existing subpages, what do you reckon?

+

::[[Dm-crypt/Encrypting_an_Entire_System]] is ''still'' (not "already") "long and disorganized", if you read the discussions above you'll see that it's the result of merging some pre-existing articles, and our goal is indeed slimming it down by moving duplicated content to the other subpages.

:::Maybe they are a little too long for an introduction, but in comparison to what we were dealing with [[Dm-crypt with LUKS|before]], I'd say they're pretty succinct. I wrote them with the goal of <u>educating the reader about the different scenarios enough to make a decision, but no more than that</u>. If you'd like to strip them down further, however, I'm completely okay with that.

+

:::Re: [[Dm-crypt/Encrypting_an_Entire_System]]: You're right. ''Still'' long and disorganized is more accurate. I think there are some improvements still to be made (i.e. splitting sections into subpages even further), but I wasn't trying to criticize anyone's decisions about the merge.

+

:::About the scenario comparison: that's more or less what I was trying to accomplish with the introductions. Are you just suggesting that we follow the "advantages and disadvantages" bulleted lists format for all scenarios on [[Dm-crypt]], or did you have different semantics in mind? Additionally, [[User:Indigo]] mentions adding a paragraph introducing the setup, and an ascii chart of the disk layout. I'd be strongly opposed to including any how-to or step-by-step information on the main [[Dm-crypt]] page. That's what the subpages are there for. The main page should serve to inform the reader about what options are available and what strengths and weaknesses each one has, not about the execution of those options. Besides that, I do feel that comparing and contrasting scenarios is highly beneficial, I'm just uncertain as to whether the introductions I wrote are what you had intended.

+

:::(Yes, I have been forgetting to sign my edits. That really should be automatic.) [[User:EscapedNull|EscapedNull]] ([[User talk:EscapedNull|talk]]) 20:39, 10 December 2013 (UTC)

+

+

::::Uh now I see where the confusion comes from: Indigo and I were discussing about [[Dm-crypt/Encrypting_an_Entire_System]], but instead you understood we were talking about [[dm-crypt#Common scenarios]], and that's why you've put the intros there :) Note the difference between "subpage", "section" and "subsection": subpages have a "/" in the article title, while sections and subsections are indicated by the link fragment ("#").

+

::::>>EscapedNull: "The main page should serve to inform the reader about what options are available and what strengths and weaknesses each one has"

+

::::We have to be even stricter than that on the main page ([[dm-crypt]]): it should only "serve to inform the reader about what options are available"; the "what strengths and weaknesses each one has" part should be described in the subpage.

+

::::>>Indigo: "A small comparison of the section scenarios may be suitable as the first subpage intro itself"

+

::::He means that a unified comparison section should be put at the top of [[Dm-crypt/Encrypting_an_Entire_System]] instead of having comparisons at the start of each section of [[Dm-crypt/Encrypting_an_Entire_System]], and that's what I agreed with.

:::::Oops. We were talking about different things I guess. Since you moved the intros to the subpages, I see that does make a lot more sense now. I understand the difference between subpages and sections/subsections, but I guess I didn't read the discussion closely enough.

+

:::::In addition, when [[User:Indigo]] said "comparison" I thought he or she meant Encrypting an Entire System versus Encrypting a Non-root Partition. You're saying the suggestion was to compare LUKS on LVM versus LVM on LUKS versus Plain dm-crypt without LUKS? [[User:EscapedNull|EscapedNull]] ([[User talk:EscapedNull|talk]]) 15:25, 11 December 2013 (UTC)

+

::::::Yes, that was the suggestion he had. Just a small comparison comparing the ''scenarios'' (read: examples to employ dm-crypt for ''specific'' ('''not''' generic) setups) on that page, as [[User:Kynikos|Kynikos]] writes. Great you joined in. Let me add to your above discussion: In September we worked a bit on [[Disk_encryption]] to finalise it as the entry point comparing methods. References you wrote in [https://wiki.archlinux.org/index.php?title=Dm-crypt%2FEncrypting_a_Non-Root_File_System&diff=287588&oldid=286178] to ecryptfs et al are discussed there. If you feel you can add to it - cool, but generic encryption comparison and references leading away from the dm-crypt subpages are meant to belong there. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 21:13, 11 December 2013 (UTC)

Revision as of 07:23, 20 January 2014

Contents

Cleanup and Clarification

I'm considering to do some editing and rewriting of this page, mainly in part "4 The Steps". The content would mostly stay the same, safe for some changes introduced with the newer versions of arch, where less console switching and module loading is needed. On the same subject should we drop, or move to a subsection, the parts related to versions 0.72 of arch?

Does anyone have objections to my plans, or should I just go ahead and we can revert back if it doesn't fit?
WhiteMagic 12:56, 24 May 2007 (EDT)

This is new territory for me, but I want to implement this topic myself soon. I'll start with removing some duplicated content. T1nk3r3r (talk) 07:25, 16 June 2013 (UTC)

Splitting sections into separate pages

Does anyone else feel that 11,305 words is too long for a single article? I'd like to propose splitting this article across multiple pages. If MediaWiki's Subpages feature is enabled, this might be a good time to use it. The article contains many sections that are not greatly related to one another. For example, does one really need to know how to (section 6) encrypt a loopback filesystem or (section 3.2) use a keyfile in order to (section 3.3) encrypt a swap partition? It's common to encrypt a swap partition without using a keyfile or an encrypted loopback filesystem, so why are they discussed in the same article?

I acknowledge that all the sections are related to LUKS, but many of them are not dependent on each other. Having many vaguely related topics makes the article difficult to follow and maintain. I propose Subpages because subpages can show their relationship to LUKS (and other sections, just as an example: /LUKS/Configuration/Keyfiles). In the absence of Subpages, placing a general overview of LUKS in the main article -- and links to pages on more specific topics -- would also be an improvement. Separating sections into (sub)pages would also keep talk pages attuned to a specific subject.

I have some suggestions for improvement of individual sections as well, but I think separating sections would be a good first step. EscapedNull (talk) 14:26, 29 September 2013 (UTC)

Hi, the article is among the longest, splitting it into subpages could help not feeling overwhelmed by it, however a lot of care should be taken in doing it, that's why I think you've been very wise to start a discussion first. We've had a number of users working hard on it, in particular I'd like to point you to a recent discussion I had with User:Indigo, #Encrypting_a_LVM_setup_.28ex_section_8.29, on which we agreed on keeping Dm-crypt_with_LUKS#Encrypting_a_LVM_setup here instead of merging it to Encrypted LVM: moving it to a subpage would somehow conflict with that decision, so I'll try to invite Indigo to discuss here with us on what to do now.

Finally, just to answer your doubts, this wiki doesn't have the subpage feature enabled on the Main namespace, nonetheless subpages (i.e. article names with slashes) are already commonly used to keep series of related articles together, so that would indeed be the way to split this article.

After reading the discussion, I see what you mean. However, I don't think splitting up the article would interfere too much with the decision to keep a brief overview of LUKS and LVM in addition to the Encrypted LVM page. The setup I had in mind was roughly giving each top-level section its own page (but don't quote me on that). The overview and the Encrypted LVM page seem to overlap, and I don't see much benefit to maintaining both, although Kynokos and Indigo might not agree and that's fine. Personally I find the Encrypted LVM page easier to follow and I think it gives the reader a better understanding of the subject, which is why my own edits on the subject have gone there rather than this page. Case and point, I'd propose replacing the overview with Encrypted LVM (as a pseudo-subpage, or just a link), but maintaining the overview is also okay, and perhaps it would just get its own article or pseudo-subpage. The main point I was trying to make is that I think LUKS/dm-crypt is too broad a topic for a single article. And as you said, I'd also be interested in hearing what Indigo has to say about this. EscapedNull (talk) 17:24, 30 September 2013 (UTC)

Hi, thanks for sharing your ideas here. Getting rid of not required content would be a preferable way, if you ask me. Particularly by (a) streamlining to LUKS and vacuuming for clarity. Then (b) splitting content by moving out sections to new pages can help and be a way forward. Yet I don't see a reason why (a) cannot be done while possibilites for (b) are figured out. If you look at the sections you quote in your first post, you will notice 2/3 have short introductory paras and would work as a subpage or even separate pages. Quite a number of edits were made to that respect and continuing with it should make it easier to re-structure the article, if that is the outcome of the discussion. If not, it is still more readable this way.

For (a) maybe you want to re-consider to join in for editing in the suggestions you have in mind first.

For (b) another point that should be addressed along is how the new pages (plain dm-crypt and encrypted LVM) could benefit at the same time. If you ask me now, separating common content would be a preferable approach to using a subpage structure (e.g. like the multipage BG). Perhaps you can detail options you see for (b). How would you re-structure the top sections on this page? Which sections would you fork out from LUKS, ideally with perspective to the other encryption pages? --Indigo (talk) 05:03, 1 October 2013 (UTC)

By "overview" I was talking about section 7 "Encrypting an LVM setup." I didn't even notice that LVM was discussed twice (a testament to disorganization of the page as it is now). I see what you mean about the disadvantages of subpages. I mentioned subpages because, for example, an LVM can be encrypted using almost any block level encryption, and one could argue that setups using different underlying technologies should be separate pages (e.g. LUKS/Encrypted_LVM, Plain_dm-crypt/Encrypted_LVM, and cryptoloop/Encrypted_LVM) as the information is likely to be different (but this could lead to duplicated information, too). It was only an idea, and perhaps something like Category:Disk_Encryption would be more appropriate. After all, subpages are disabled for a reason.

I thought it would be a good idea to split the article first and edit second because it would be easier to focus on a single topic, and because it could save us from editing information twice in case it conflicts with the new structure. But if you think it would be best to edit first and restructure later, I'm fine with that I guess. Kynikos, do you have a preference? EscapedNull (talk) 13:44, 1 October 2013 (UTC)

My suggestion was that editing section content can be done in a way so that forking one out does not require major double edits. Meanwhile we gained another section LUKS#Encrypting_the_home_partition. With that it becomes easier to get rid of LUKS#Encrypting_a_LVM_setup here by finalizing Encrypted_LVM and double checking nothing is lost. Apart from that, anyone has a suggestion which section may be a first worthwhile candidate for a separate page? --Indigo (talk) 21:54, 1 November 2013 (UTC)

Hm, since you mention subpages again: the reason I am unsure about them, as described above, is that I find them confusing to browse. The example I keep having in mind is the multipage BG guide. Reading that I have to scroll down to the page end in order to see links to subsequent subpages (e.g. Beginners'_Guide/Post-installation). If the master page had a TOC including sections of the subpages, that would be more transparent. But the TOC always starts with 1 per page and makes no reference back or forth. A reader not knowing the content will only find the subpages by coincidence, if at all.

Now, while writing the reply, I had the idea to leave in the section heading, but move the content to a subpage. This way the main LUKS article keeps at least a reference in the TOC and links out content not necessary for all readers. I just created two subpages to see and show how it works out:

Quoting your last post, "A reader not knowing the content will only find the subpages by coincidence, if at all", I think this system would avoid that problem, both because of the little introductions with links, and because the shortness of the article would make the reader curious to open all the subpages to see what they talk about, none of them being seen as a subpage more important than the others.

I hope I've been able to express the idea clearly enough ^^' -- Kynikos (talk) 10:36, 11 November 2013 (UTC)

You develop it further and I see what you mean, yes. Yet the General Recommendations serve a totally different purpose. That article gives a guide across a wide variety of system setup topics. The LUKS page focusses on one kernel toolset and the various specialities for it (which is why I prefer a complete TOC as a reader totally). Nonetheless, I like your idea and (quickly - not attempting to change content but to show the case) tried to mod the test case 2 above accordingly: [1]. Now that results in us keeping the TOC of the main page complete but still forks the section out: Dm-crypt_with_LUKS#Encrypting_a_loopback_filesystem. Is this more something you would anticipate?

I still prefer the single page format myself really, but the point is more how other readers not familiar with the topic can cope with it in KISS style. (unfortunately just few raised opinions). All in all I agree now that this can be a good way forward to re-structure the article. I guess I could just not picture it earlier. Anyhow, it will be a pleasure to help you with it. I have left comments and questions in User_talk:Kynikos/Dm-crypt_with_LUKS.

So what have we decided, exactly? I see there's now a Dm-crypt page with subpages. Is that where sections from this page are going to be moved? What about the merge from section 7 to Encrypted LVM that User:Kynikos mentioned? Is that still happening, or are we going to make a Dm-crypt/Encrypted LVM subpage instead and merge Encrypted LVM into it? I'm willing to help, but I'm not sure as to what I should be doing.

Have a look at Talk:Dm-crypt#New_idea for your questions and the new plan, and then the Dm-crypt subpages. There's plenty of stuff to do to implement it to plan. If you are unsure how to help, look for the 'accuracy' and 'expansion' tags for example. Would be great, if you want to join in. --Indigo (talk) 19:35, 6 December 2013 (UTC)

New idea

The philosophy behind the current old structure was to try to generalize the various steps for encrypting an entire system or a device and managing it, however we've noticed it's kind of hard. A new idea for reducing duplication of content while maintaining, if not improving, readability, would be to rename the "/Examples" subpage to "/Common Scenarios" and move it to first place in Dm-crypt with LUKS/draft, so it's used use the dm-crypt#Common scenarios section as the starting point by the readers. It should contain the most common uses for encryption, which IMO are:

(I think it would be really cool if we could also include an example with software RAID)

Each of those scenarios should be mostly a stripped sequence of commands with short descriptions that should link to generic sections in the other subpages of Dm-crypt with LUKSdm-crypt, pointing out all the particular suggested adaptations that apply to that particular scenario.

The idea is quite clear in my mind, I hope I've managed to explain it well enough, I'll try to put it into practice and see if it raises major problems.

+1 to your edit, I learned that from watching. The one letdown of this whole fun exercise is that the wiki engine does not seem to support basic content splits and joins preserving history. Anyhow, we might as well just keep it in mind and consider splitting it later (when there is something about RAID). Funnily, I find the use of "physical" (all blockdevices are on one) and "virtual" (suggests a qcow device) as differentiator not totally clear too. Let's meditate over it again until someone has another snappy idea. --Indigo (talk) 23:16, 9 December 2013 (UTC)

@Indigo: I approve 100% what you said: a single, small comparison section is what we need!

@EscapedNull (please remember to sign your edits in talk pages, use ~~~~): I think you're referring to this edit on the dm-crypt page; honestly those intros, despite being very clear and well written, are indeed too long for that page, as you note yourself: the intended size of those intros was like the ones in Dm-crypt#Swap device encryption or Dm-crypt#Specialties, they should just sum up very briefly what's contained in each subpage. I wouldn't like to just throw your work away, I'd rather move it to a more suitable place in some of the existing subpages, what do you reckon?

Dm-crypt/Encrypting_an_Entire_System is still (not "already") "long and disorganized", if you read the discussions above you'll see that it's the result of merging some pre-existing articles, and our goal is indeed slimming it down by moving duplicated content to the other subpages.

Maybe they are a little too long for an introduction, but in comparison to what we were dealing with before, I'd say they're pretty succinct. I wrote them with the goal of educating the reader about the different scenarios enough to make a decision, but no more than that. If you'd like to strip them down further, however, I'm completely okay with that.

Re: Dm-crypt/Encrypting_an_Entire_System: You're right. Still long and disorganized is more accurate. I think there are some improvements still to be made (i.e. splitting sections into subpages even further), but I wasn't trying to criticize anyone's decisions about the merge.

About the scenario comparison: that's more or less what I was trying to accomplish with the introductions. Are you just suggesting that we follow the "advantages and disadvantages" bulleted lists format for all scenarios on Dm-crypt, or did you have different semantics in mind? Additionally, User:Indigo mentions adding a paragraph introducing the setup, and an ascii chart of the disk layout. I'd be strongly opposed to including any how-to or step-by-step information on the main Dm-crypt page. That's what the subpages are there for. The main page should serve to inform the reader about what options are available and what strengths and weaknesses each one has, not about the execution of those options. Besides that, I do feel that comparing and contrasting scenarios is highly beneficial, I'm just uncertain as to whether the introductions I wrote are what you had intended.

(Yes, I have been forgetting to sign my edits. That really should be automatic.) EscapedNull (talk) 20:39, 10 December 2013 (UTC)

Uh now I see where the confusion comes from: Indigo and I were discussing about Dm-crypt/Encrypting_an_Entire_System, but instead you understood we were talking about dm-crypt#Common scenarios, and that's why you've put the intros there :) Note the difference between "subpage", "section" and "subsection": subpages have a "/" in the article title, while sections and subsections are indicated by the link fragment ("#").

>>EscapedNull: "The main page should serve to inform the reader about what options are available and what strengths and weaknesses each one has"

We have to be even stricter than that on the main page (dm-crypt): it should only "serve to inform the reader about what options are available"; the "what strengths and weaknesses each one has" part should be described in the subpage.

>>Indigo: "A small comparison of the section scenarios may be suitable as the first subpage intro itself"

Oops. We were talking about different things I guess. Since you moved the intros to the subpages, I see that does make a lot more sense now. I understand the difference between subpages and sections/subsections, but I guess I didn't read the discussion closely enough.

In addition, when User:Indigo said "comparison" I thought he or she meant Encrypting an Entire System versus Encrypting a Non-root Partition. You're saying the suggestion was to compare LUKS on LVM versus LVM on LUKS versus Plain dm-crypt without LUKS? EscapedNull (talk) 15:25, 11 December 2013 (UTC)

Yes, that was the suggestion he had. Just a small comparison comparing the scenarios (read: examples to employ dm-crypt for specific (not generic) setups) on that page, as Kynikos writes. Great you joined in. Let me add to your above discussion: In September we worked a bit on Disk_encryption to finalise it as the entry point comparing methods. References you wrote in [2] to ecryptfs et al are discussed there. If you feel you can add to it - cool, but generic encryption comparison and references leading away from the dm-crypt subpages are meant to belong there. --Indigo (talk) 21:13, 11 December 2013 (UTC)