User talk:Neitsab

From ArchWiki
Latest comment: 6 September 2015 by Indigo in topic keyfile in initramfs

Aria2


You don't need to add --enable-rpc to uGet for it to work with Aria2, while it does require it to function the plugin settings have it set by default so don't actually have to change anything except for just enabling the plugin. MichaelTunnell (talk) 08:03, 11 January 2014 (UTC)Reply[reply]

You're right, and it wasn't my intention to say something different. Re-reading the introductory note of "Frontends" section, it appears I misunderstood/misread it. To me it was just laying off a distinction between "frontends that needs --rpc-enable option" (wherever it may be set) and those who don't. And as uGet needs this option set in its preferences...
I'm considering rewriting this section as follows:

Frontends

{warning about configuration, specifying that uGet stores its own parameters for aria2}

Web UI

{note: these front-ends need aria2 to be started with --enable-rpc option (in terminal or as a daemon)}

...

Other frontends

These frontends don't need aria2 to be separately started with --enable-rpc.

...

uGet

..."

What do you think?

-- Neitsab (talk) 13:00, 12 January 2014 (UTC)Reply[reply]


That seems fine to me. MichaelTunnell (talk) 10:39, 13 January 2014 (UTC)Reply[reply]

It's done. Thanks for your notice! -- Neitsab (talk) 15:00, 13 January 2014 (UTC)Reply[reply]

Discussion standards

Hi, thank you for your contributions, but please avoid edits like [1] because, as you can see by the diff, they make it very hard and time-consuming to understand what happened (one may even not realize that you replied to a discussion). I've fixed the page, but next time you should try to split big edits in various little edits. In particular, do not edit an old post if someone has already replied, but instead simply add a new reply. A discussion is closed by striking its header. For more info see Help:Discussion. -- Kynikos (talk) 06:46, 10 May 2014 (UTC)Reply[reply]

Hi, thanks for your advice and corrections. The edit you refer to was indeed quite troublesome for me, as I didn't know what was the standard way to do it (delete my previous comment, reply to another...), and I had overlooked Help:Discussion. At first I wanted to strike my outdated comment, but I didn't find how to do it in Mediawiki markup via Help:Style/Formatting_and_punctuation. Now I see it was elsewhere... I stand corrected and will strive to maintain more correctness in my edits. Thanks. -- Neitsab (talk) 14:36, 12 May 2014 (UTC)Reply[reply]
Ahem... are you sure you understood what I meant with "not edit[ing] an old post if someone has already replied"? [2] -- Kynikos (talk) 02:41, 14 May 2014 (UTC)Reply[reply]
Ha, right. I thought correcting my first post while not changing info brought up in the following comments would make no harm; I actually thought it'd make it clearer. All right, I'll stop editing old posts and just queue up new stuff. And I read your sticky in the "Forum & wiki discussion" section of the boards ([3]), I can feel it's been partly redacted because of what you said above. I'll try to re-read it carefully and digest its content. Cheers -- Neitsab (talk) 10:29, 14 May 2014 (UTC)Reply[reply]
Yep, you have to try to make it easy for the other users, it's not expected to have to check the diff of a talk page in order to follow a discussion :)
You can strike the old parts, but then add new stuff in a new post, just like you'd do in the forums. If you want to maintain some sort of a plan that changes frequently, you could do it in a separate sub-heading, and have comments added in a "Comments" subsection.
-- Kynikos (talk) 03:16, 15 May 2014 (UTC)Reply[reply]

haveged in chroot

Hi, regarding [4], wouldn't running haveged in the host system be the right way to get around the issue of low entropy? Otherwise, the SSH session is mentioned for the first time in this tip, so you might want to clear that up. -- Lahwaacz (talk) 08:00, 27 July 2015 (UTC)Reply[reply]

Hi, you're perfectly right, I was so entrenched in my specific use case that I forgot other possibilities to do so (it was pretty late in my time zone).
Indeed trying to install haveged on the host system was the first thing I tried, but it appeared that dpkg lock file (/var/lib/dpkg/lock) was on a read-only mount point so I couldn't install or update anything. That's why I went the ls -Ra / route.
Note that if we advise users to install something on the host, then we should do it before the initializing pacman keyring step, like somewhere in Using the bootstrap image, so people can do it before chrooting (this will give haveged some time to generate entropy).
About the sudden mention of SSH: you're right here too, that is the result of me being stuck in my use case (remote server install). I'll modify the tip to generalize it ("open a new session from another TTY, terminal or SSH session"...). Neitsab (talk) 12:58, 27 July 2015 (UTC)Reply[reply]
Modifications visible at [5]. Neitsab (talk) 13:21, 27 July 2015 (UTC)Reply[reply]
Thanks for the explanation, updating the tip and the whole very confused page/section.[6] Looking forward to your next great contributions! -- Lahwaacz (talk) 13:41, 27 July 2015 (UTC)Reply[reply]
No problem, thanks to you, and Kynikos, Alad, Lonaowna and the other great admins and mods for helping maintain such an amazing common good.
I look up to your examples and try to do my best to improve this documentation, which was part of what drew me to Arch and constitutes a unique resource for all GNU/Linux users. Neitsab (talk) 14:05, 27 July 2015 (UTC)Reply[reply]

keyfile in initramfs

Hi, I just see you are working on adding an additional section in Dm-crypt/Device_encryption#With a keyfile embedded in the initramfs. Did you see how our instructions of the encrypted boot scenario use a keyfile stored in the encrypted boot? Same way you can store it anywhere in /boot. Moving it to the initramfs makes things more complex. What advantages do you see in doing so? --Indigo (talk) 22:39, 5 September 2015 (UTC)Reply[reply]

Hi, thanks for your quick notice!
Indeed, I've been swamped since a couple of hours in cascading edits: at first I simply wanted to correct GRUB#Boot partition, which currently says that "in both cases it is required to input two passphrases to boot", which isn't true.
So I was about to add the instructions there in a new subsection about "how to bypass the second password prompt using a keyfile embedded in the initramfs" as per this post, but then I realized that this was a general possibility offered by the intersection of LUKS key management and mkinitcpio FILES= features, and therefore that it was probably better suited to the dm-crypt guides.
I hadn't seen the "encrypted /boot scenario" instructions you linked to, however the fact that they are strongly tied to a particular use case (separate /boot partition, which I'm hoping to get rid of thanks to GRUB boot encryption feature) makes me uneasy. I'm envisioning more general instructions, which would mention that by calling the keyfile crypto_keyfile.bin and placing it at the root of the FS it will be automatically picked up by the encrypt hook (see [7]).
This is an information I'd like to see well separated out in the wiki, not only mentioned in the "Configure fstab and crypttab" subsection of the "encrypted boot partition" section of the "Encrypting an entire system" page. Moreover they really seem like different situations to me, where in one you keep a separate /boot, which indeed therefore requires post-boot mounting, and one whre you don't and therefore don't have to mess with /etc/crypttab.
I have no preference for the initramfs embedding except that I find it really KISS actually :) Neitsab (talk) 22:47, 5 September 2015 (UTC)Reply[reply]
Yes, ok. Actually I did not remember the encrypt hook has the tweak for crypto_keyfile.bin. That indeed makes it simple. I should have waited until you wrote it to make me remember :), but I saw your initial edit and was unsure so I left this message to potentially save you designing overly complicated instructions.
In bringing the existing example from the "encrypted boot partition" scenario I only wanted to make you aware of the other (non-embedded) method, not say it is not useful to generalize such a method. I agree the section you picked to expand for the generalization is the right place for it, much better than the GRUB#Boot_partition one. Just go ahead, thanks for explaining your idea! I close this item. --Indigo (talk) 08:16, 6 September 2015 (UTC)Reply[reply]