Boot fails when a keyfile is configured for all encrypted filesystems
and no other luks devices are configured. This is because luks support is only
enabled in the initrd, when boot.initrd.luks.devices has entries. When a
fileystem has a keyfile configured though, it is setup by a custom
command, not by boot.initrd.luks.
This commit adds an internal config flag to enable luks support in the
initrd file, even if there are no luks devices configured.
`qtkeyring` can use `gnome-keyring`, but it needs some help to find it.
I have not enabled this by default because not everyone who uses this will want
to pull in GNOME dependencies.
This is a rebased version of the pull request with small fixes due to
changes in recent master.
Original description from the pull request:
Currently this is only a very basic test which gets certificates via
the enableACME option of the nginx module.
However the main reason why I'm not directly merging and putting this
up for review is that the complexity here lies in the support-modules
needed for the test. The support modules are for running a Boulder
instance along with a DNS resolver (as a separate module).
For details about the implementation, see the commit messages and the
comments at the start of the respective support modules.
I'm merging this first of all because other than @abbradar, none of the
other requested reviewers did comment on the changes and second because
the change here is adding a test, so even if the implementation would be
so disgusting and crappy it's better than having no test at all.
The comment of @abbradar was:
Can't we factor Boulder into a proper package and a NixOS service?
Maybe not very general purpose for now but still -- putting everything
into one test seems painful to me.
My objection to this is that the components are heavily patched and some
of them don't even have a release, so I'm not sure whether infesting
pkgs/ with them is really a good idea.
Nevertheless, we can still do that later.
Cc: @fpletz, @domenkozar, @bjornfor
Since 67651d80bc the requests package now
depends on certifi, which in turn provides the CA root certificates that
we need to replace.
It might also be a good idea to actually patch certifi with our version
of cacert by default so that if we want to override and/or add something
we only need to do it once.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @fpletz, @k0ral, @FRidh
Bastian Köcher