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`.
4.0 has been out for a year without another upstream release, so
presumably 4.x's quite stable enough (and already in Arch & Debian
Buster for instance).
Certain tools, e.g. compilers, are customarily prefixed with the name of
their target platform so that multiple builds can be used at once
without clobbering each other on the PATH. I was using identifiers named
`prefix` for this purpose, but that conflicts with the standard use of
`prefix` to mean the directory where something is installed. To avoid
conflict and confusion, I renamed those to `targetPrefix`.
Would be just mdadm: 3.3.4 -> 4.0, but it doesn't look like there are
urgent bugfixes, and it is a major release, and wrong RAID handling
kills data, so let's let the early adopters test it a bit.
The updates we had in the past (7719f7f and 1faf610) broke the mdadm
installer test and systems in the wild using mdraid because newer mdadm
versions contained a self-referenc to its own store path.
Instead of putting a big warning about updating in the package
expression, let's just add allowedReferences so the build immediately
fails if there is a self-reference.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Let's use makeFlags directly instead of stitching together a
makeFlagsArray in preBuild.
This should make the expression much more readable and clean.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Okay, this update is a bit more tricky and the patch I've included is
not very nice to be honest.
So the patch causes "mdadm --udev-rules" to search for the right store
path using /proc/self/exec. This has the disadvantage that we could end
up having /run/current-system/bin/mdadm in the rule file.
But on the other hand, when we're on NixOS, we don't need to use that
command *at*all*, so we should be safe.
The patch also sets BINDIR to /sbin, which causes the included rule and
systemd files to not work out of the box on NixOS. But we have a
substituteInPlace where we do rewrite /sbin/mdadm to the right store
path in our udev rule generator, so that shouldn't be an issue.
I've tested this using the mdraid installer test and it succeeded.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This reverts commit 7719f7f23b, again!
It prevents systems from booting, for two reasons:
* The initrd size is going to explode, but I think this is not the
REAL issue. We had that in 666cf99 already, which reverted this
update already.
* Another reason I don't yet know, which is the REAL issue. We need to
investigate and fix that before attempting another update.
Because of that I've also added a small comment before the src attribute
to prevent further updates like this.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This reverts commit 1faf6106c3. It
causes the size of the initrd to explode from ~6 MB to 19 MB:
http://hydra.nixos.org/build/15728196
The reason is that mdadm now contains a self-reference:
$ strings ./result/sbin/mdadm | grep /nix/store
...
ACTION=="add", SUBSYSTEM=="block", ENV{DEVTYPE}=="%s", ENV{ID_PATH}=="%s", RUN+="/nix/store/y1ap6va0av6jhxf7ddnr8vdwxd7b44gd-mdadm-3.3.2/sbin/mdadm --incremental $env{DEVNAME}"
ACTION=="add", SUBSYSTEM=="block", ENV{ID_PATH}=="%s", RUN+="/nix/store/y1ap6va0av6jhxf7ddnr8vdwxd7b44gd-mdadm-3.3.2/sbin/mdadm --incremental $env{DEVNAME}"
/nix/store/y1ap6va0av6jhxf7ddnr8vdwxd7b44gd-mdadm-3.3.2/sbin/mdmon
(Previously, it referred to /sbin/mdadm.) This causes mdadm, glibc and
linux-headers to be added to the initrd.
