User talk:Silverhammermba

From ArchWiki
Latest comment: 25 December 2014 by Kynikos in topic Comments in code blocks

Active discussions

See WhatLinksHere

ESP Mount

I sort of tried to force my opinion that even having those guidelines in the article would perpetuate this mistaken belief that you shouldn't mount your ESP to /boot. There is no reason to not mount the ESP to /boot. It is not something you would do in all circumstances, it is not something you would do in some circumstances, and it is not something you would do in incredibly rare circumstances. All it does is force you copy kernels and initramdisks after every upgrade.

But some people inevitably will so I suppose the guidelines should stay. Kristof (talk) 01:38, 30 September 2013 (UTC)Reply

You could have a .path unit enabled in each operating system that moves kernels to subdirectories in the $ESP. You'd then tell gummiboot or GRUB to look for vmlinuz-arch or vmlinuz-opensuse or vmlinuz-fedora in EFI\arch or EFI\fedora or something analogous. On a single-kernel system, however I don't mind the kernels in my EFI's root because nothing else resides there besides some directories and it keeps things simple. Windows keeps its bootloader in EFI\boot\something-or-the-other and doesn't linger int he way. If I had other kernels, though, besides arch's stable, then I'd partition them out and use systemd units. I just think systemd .path units are kind of complex, especially when you only have one kernel. And if you have two or more, then you're competent enough to not need a wiki page to tell you how, anyway. Kristof (talk) 18:12, 1 October 2013 (UTC)Reply

Sorry

Just apologizing for inadvertently reverting 2 of your edits (immediately restored, [1] [2]), I clicked by mistake on the revert link... twice in a row... :P -- Kynikos (talk) 03:22, 18 September 2014 (UTC)Reply

MAILTO script

I understand that you may not like the mail_onf_failure shipped in systemd-cron (see Timers talk page); but please advise user to run the .service with User=nobody & Group=systemd-journal; to lower it's privileges. --A-detiste (talk) 08:08, 6 November 2014 (UTC)Reply

I don't dislike systemd-cron. But since it isn't an official package, I thought it would be useful to describe how to get MAILTO behavior without it.
As for security, might not the correct user and group depend on how mail is being sent? There are several packages that provide a sendmail binary and I have no idea what privileges they require. Regardless, I only included the mail script because there is no official way to send mail via the command line on Arch and I wanted to provide a complete working example. Feel free to add security recommendations if you think they are needed. Silverhammermba (talk) 13:14, 6 November 2014 (UTC)Reply
systemd-cron depends on mail_onf_failure, but this mail_on_failure rewrite can be ripped out and work independently of systemd-cron; see https://github.com/systemd-cron/systemd-cron/blob/master/src/bin/mail_on_failure
However the recipient is hard-coded (since unit templates can only take a single parameter) so you will need to create multiple services if you want to send emails to different sets of recipients.
It avoids this problem by parsing the "Environment=" of the caller unit to locate an eventual MAILTO= value.
For the User= & Group= ; "it works for me", with nullmailer as an MTA, but it should work with any MTA; they might be suid, but then it's their responsibility to avoid security holes.
--A-detiste (talk) 11:04, 7 November 2014 (UTC)Reply

Comments in code blocks

Hi, just a little remark about [3]'s edit summary: Help:Style#Command line text forbids comments in command-line code blocks, but in configuration file excerpts they are allowed. In this case however I agree that they were redundant and useless :) -- Kynikos (talk) 02:20, 25 December 2014 (UTC)Reply