User talk:Hgabreu

Separate LUKS header

Hi, regarding [1], please do not add instructions to store a LUKS header separately in Dm-crypt/Encrypting an entire system, because tnat article is meant to be only a list of common scenarios with links to the other subpages of dm-crypt. I suggest you contribute to dm-crypt/Device encryption (for example there's already Dm-crypt/Device_encryption#Backup_and_restore), or dm-crypt/Specialties. -- Kynikos (talk) 11:56, 14 July 2014 (UTC)

Thanks, will do. -- Hgabreu (talk) 12:12, 14 July 2014 (UTC)

Hi, thanks for your contributions to the dm-crypt pages!

However, there was a little misunderstanding. When Kynikos suggested you could contribute to Dm-crypt/Device_encryption he meant that some of the content you contribute could be added on the encryption subpage in a general manner (he referred to Dm-crypt/Device_encryption#Backup_and_restore because that is where we have examples on the --header option already).

The way you have written your contribution as installation instructions does not fit well on that subpage.

But we have special installation instructions and also other modifications of the encrypt hook in Dm-crypt/Specialties#Modifying_the_encrypt_hook_for_multiple_partitions, so it fits better there in my view. For example, it could be a subsection right under Dm-crypt/Specialties#The_encrypt_hook_and_multiple_disks as a subsection like it is. (we have other options too)

Question 1: What do you think about moving it there? (If you are ok with it, feel free to move it yourself right away.)

Then I have another question: With [2] you modify the prevous partitioning example of the LVM on LUKS scenario and removed additional volumes for home and media. Why?

(I ask that because I am unsure why you did it and I think it is useful to have at least one secondary volume as installation reference for readers; simple reason: it is a common setup people look for).

--Indigo (talk) 20:25, 15 July 2014 (UTC)

Thanks for the orientation Indigo and sorry for the trouble. I'm a total noob at this (contributing to the wiki) and this is my first entry. I wrote it as installation instructions because that's the most natural to me and how I think is most useful. But please, feel free to edit/move/remove it as you see fit.

I've moved it to the specialties multiple disks as recommended and fixed the links to it on the LVM on LUKS entry. I've also re-included a home volume as suggested. My idea for that change was to add a swap example, which is very useful and half way to allow suspending to disk, while keeping the example simple. I've also included there an example of using the remaining space on the volume group, which was a doubt I had when following it. Again, sorry if I did something wrong and please instruct me so I can do better contributions in the future.

--Hgabreu (talk) 23:56, 15 July 2014 (UTC)

No trouble, thanks for taking up the points right away and promising to continue contributing :) with us. In my view you take great care of doing it properly already so I am sure you have discovered the wealth of guidance from ArchWiki:Contributing to help us. One further comment: we try to de-duplicate content as much as possible. For the dm-crypt article it was decided to do this via the subpage structure (and the work is not finished yet), but you will see it on other articles as well with more and more extensive crosslinking in recent edits. It's good to keep that in mind, if you start getting into contributing. Até mais. --Indigo (talk) 21:57, 16 July 2014 (UTC)

There was a small typo in the section name, so I renamed it to Dm-crypt/Specialties#Encrypted system using a remote LUKS header. I made some more changes to your contribution, please see in particular the last sentence: [3]

--Indigo (talk) 20:50, 17 July 2014 (UTC)

I had not read the ArchWiki:Contributing thanks for guiding me. About the changes: I see your point, I think it's pertinent. Just the last part regarding the wording "different" over "easier" that I don't agree completely. Have you attempted the setup using openssl or gpg? But it's alright. I'm glad that most of my changes were salvageable :)

--Hgabreu

True, it is easier again. Don't refrain from editing it yourself again, if you want to change it. --Indigo (talk) 22:01, 17 July 2014 (UTC)

@Kynikos: Hgabreu moved the contribution to Dm-crypt/Specialties#Encrypted system using a remote LUKS header along with some trimming. Are you ok with it? --Indigo (talk) 10:58, 22 July 2014 (UTC)

Well, as you note, more de-duplication of content could be done, however I guess that's where the section better belongs. Honestly I'm more concerned with the leftover edits to Dm-crypt/Encrypting_an_entire_system [4], there seems to be some inconsistency between the diagram and the partitioning commands below (root and home are swapped), and, to me, giving 30GB to root is a bit of an eyesore, even if it's just an example... (but maybe we should continue the discussion in the article's talk page, in case Hgabreu is no longer interested) -- Kynikos (talk) 15:38, 22 July 2014 (UTC)

I'm interested, you may continue here if you want. Sorry about the leftovers I'll fix the diagram. What's a "good" root fs size? About the de-duplication, I tried hard not to repeat any commands or explanations. How do you think I could enhance it? Or are you talking about the Dm-crypt/Encrypting_an_entire_system article in general? -- Hgabreu (talk) 15:57, 22 July 2014 (UTC)

Ah, the diagram indeed does not match anymore. Considering it again, I would actually prefer if we move back to the previous version (incl. sizes for the partitioning; no need to specify sizes in the diagram). Changing it again, I also vote against having a default logical volume for swap but just crosslink Dm-crypt/Swap_encryption (for a number of reasons, see: Dm-crypt/Swap_encryption#With_suspend-to-disk_support).

We could link from the tip we added down to Dm-crypt/Encrypting_an_entire_system#Plain_dm-crypt to reference a similar disk layout Hgabreau intended instead (see the note mentioning the "--header" option there, that should be adapted to link to the new section anyhow).

Hgabreu: Yes, we want to consolidate Dm-crypt/Encrypting_an_entire_system much further with moving and crosslinking content to the other subpages. Some examples I still see for de-duplication in Dm-crypt/Specialties#Encrypted_system_using_a_remote_LUKS_header: (1) the intro (2nd para) could be shortened considerably, referencing Dm-crypt/Encrypting_an_entire_system#Plain_dm-crypt after adaptions and Disk encryption, (2) the last sentence is an ideal candidate of generic info we want to move to Dm-crypt/System_configuration#Mounting_at_boot_time.

Talking about these changes: is it not more efficient and contextually similar, if the new section instructions are linked to the "plain dm-crypt" scenario instead to the first LVM one? What do you think? --Indigo (talk) 18:08, 22 July 2014 (UTC)

I've made some of the adaptations we discussed to the LVM on LUKS scenario.

About swap, all the scenarios are pretty inconsistent anyway, so for the moment I've left it there. Note that currently it wouldn't allow suspension to disk, since the resume hook is not mentioned (and shouldn't be, since we don't want to duplicate dm-crypt/Swap encryption about that). Maybe we could add a tip with a link to the suspension to disk instructions, since it's a pretty popular feature.

About the link to/from Dm-crypt/Encrypting_an_entire_system#Plain_dm-crypt could you please reword/expand it 'cause I haven't got it (maybe I'm just tired and can't reason too much now) :)

-- Kynikos (talk) 13:19, 24 July 2014 (UTC)

Ok, so let's leave swap in. If we put swap into LVM like we do in this case, it is always static. With static encryption, suspension to disk is safer than suspend to memory. I changed my mind about the swap logical volume above, because I felt uncomfortable not to make readers think about implications whether they need swap with volatile or static encryption. So I added a sentence about swap at the top (maybe the tip you propose should replace it, rather than adding it per scenario).

In the Dm-crypt/Encrypting_an_entire_system#Plain_dm-crypt intro we have this note:

Note: If you have a requirement for a blockdevice without a cryptheader but want to use LUKS instead of plain mode for above noted disadvantages, cryptsetup offers a --header option too. While it cannot be used with the encrypt hook, it can generally be used to place the LUKS header remote from the encrypted blockdevice. For example it could be placed on the usb-key /dev/sdZ instead of the key-file (using a passphrase instead gives easy two-factor authentication).

Hgabreu's set up example overcomes the mentioned limitation by modifying the hook. (so the note can crosslink to it as well now anyhow.) When proposing to move the LVM partitioning back to the previous version, I had in mind that Hgabrau's contribution could also crosslinked to the plain-scenario as a base now because the partitioning of the plain scenario is much more like the one Hgabreu proposed originally when re-working the LVM example (adding swap, an optional usb for boot). Moreover I think readers looking for the particular benefits of the new contribution will be more likely to focus on the plain scenario than readers of the regular LVM set up (where an optional usb /boot will not be a popular feature and confuse more than anything else). I hope this clarifies? --Indigo (talk) 18:49, 24 July 2014 (UTC)

It is clear to me now. Yes, crosslinking with the plain-scenario makes more sense. --Hgabreu (talk) 19:04, 25 July 2014 (UTC)

I support your idea too, Indigo, thanks for clarifying. -- Kynikos (talk) 04:22, 27 July 2014 (UTC)

Great, I have gone ahead with it: [5]. Please have a look, if I missed something. Thanks. --Indigo (talk) 22:33, 29 July 2014 (UTC)

It looks like you've done a good job (again), so I'm closing this one. -- Kynikos (talk) 07:01, 30 July 2014 (UTC)