mdadm: allow sending mail when using opensmtpd #38067
Conversation
|
@GrahamcOfBorg build mdadm |
|
Success on x86_64-linux (full log) Attempted: mdadm Partial log (click to expand)
|
|
Success on aarch64-linux (full log) Attempted: mdadm Partial log (click to expand)
|
|
Success on x86_64-linux (full log) Attempted: mdadm Partial log (click to expand)
|
|
Success on aarch64-linux (full log) Attempted: mdadm Partial log (click to expand)
|
|
If no absolulte path is needed, simple $PATH lookup could suffice, with priority ordering by directory position in the $PATH list. Does mdadm need absolute path? Please add full explanation in the commit message, not just the PR message. The PR message starts out with the contents of the commit message, so the text only needs to be written once (not even copy-pasted). |
OpenSMTPD does not require the setuid bit for its `sendmail`. This works around it by wrapping the called `sendmail` so that the wrapper falls back on either the setuid `sendmail` or the non-setuid `sendmail` depending on what's available. The solution of relying on `$PATH` to be set is unfortunately unreliable, as `mdadm --monitor` will likely be executed from a `systemd` unit, that runs with a clean `$PATH`.
Ekleog
force-pushed
the
sendmail-from-path
branch
from
289ed91
to
5a8d8ef
Compare
|
Just added information to the commit message. Also copying it here as it'll be easier to access: So I thought it'd be better to just follow what the previous |
|
Success on x86_64-linux (full log) Attempted: mdadm Partial log (click to expand)
|
|
Success on aarch64-linux (full log) Attempted: mdadm Partial log (click to expand)
|
|
Both approaches have their benefits. I personally prefer to not leak NixOS specific paths into nixpkgs (the packages). Sometimes it doesn't really matter, other times it makes packages break on non-NixOS. By the way, here you can see the $PATH approach implemented in the kbfs NixOS module. Does mdadm work with sendmail PATH lookup and something like |
|
I can confirm it does work with PATH, actually that's the way I initially chose to develop. The issue I came upon with that is that there are likely people with services such as: systemd.services.mdadm-monitor = {
description = "Monitor RAID disks";
wantedBy = [ "multi-user.target" ];
script = "${pkgs.mdadm}/bin/mdadm --scan --monitor -m root";
};And such a script would be silently broken by such an update: it would no longer send any email were one of the disks to fail. This sounds like an easy way to have someone hate nixpkgs, unfortunately. And I don't really know of any way to handle the switch cleanly. Using Do you have any idea how to handle this better? |
|
Good point. (I have a hand-written service like that myself.) The problem is that we don't have a NixOS module for mdadm, #31840. Let's merge. |
|
Applied to master (ec9a51d). |
|
Thanks! |
opensmtpddoes not require the setuid bit for itssendmail. This works around it by wrapping the calledsendmailso that the wrapper falls back on either the setuidsendmailor the non-setuidsendmaildepending on what's available.I don't know whether that's something that happens often, but maybe it'd make sense to generate a linkfarm to both
current-system/sw/binandwrappers/bin, for when an absolute path is requested?Tested on 18.03.