Creating and then erasing the key relies on the disk erasing data
correctly, and otherwise allows attackers to simply decrypt swap just
using "secretkey". We don't actually need a LUKS header, so we can save
ourselves some pointless disk writes and identifiability.
In addition, I wouldn't have made the awful mistake of backing up my swap partition's LUKS header instead of my zpool's. May my data rest in peace.
- Remove useless escape of question mark
- Fix and quoting
- Add some '&&s' for correctness
- Add escapeShellArg
- Remove &&s in preStart
Edited by grahamc: fixed the ${} typo on line 246
The previous package didn't build properly due to a bug in the build
script, and the nixos module didn't evaluate due to missing descriptions
in the options. This fixes both issues.
It also adds missing command-line options that weren't able to be set
and properly converts bools to the strings exhibitor expects.
Syntax errors prevented important parameters from being passed to
oauth2_proxy, which could have permitted unauthorised access to
services behind the proxy.
This allows to run the prune job periodically on a machine.
By default the if enabled the job is run once a week.
The structure is similar to how system.autoUpgrade works.
The systemd service file shipped with strongswan has strongswan started after `network-online`. It turns out that this is for good reason: failure to connect on boot otherwise.
See this thread on the mailing list, which my colleague initiated after finding that our NixOS strongswan config wouldn't connect on boot:
https://lists.strongswan.org/pipermail/users/2017-January/010359.html
Tested on a local config (which has the strongswan service config overridden).
The helper tool had a very early check whether the automatically created
CA key/cert are available and thus it would abort if the key was
unavailable even though we don't need or even want to have the CA key.
Unfortunately our NixOS test didn't catch this, because it was just
switching from a configuration with an automatically created CA to a
manual configuration without deleting the generated keys and certs.
This is done now in the tests and it's also fixed in the helper tool.
Reported-by: @jpotier
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Use xmlstarlet to update the OVMF path on each startup, like we do for
<emulator>...qemu-kvm</emulator>.
A libvirt domain using UEFI cannot start if the OVMF path is garbage
collected/missing.
Instead of grep and sed, which is brittle.
(I don't know how to preserve the comment we currently add to say that
this line is auto-updated. But I don't think it adds much value, so I'm
not spending any effort on it.)
