Add ProtectSystem=strict, remove PermissionStartOnly.
Extract the section of postStart that needs secrets dir write
access into a separate script with full privileges.
Simplify preStart and fix dataDir quoting.
Previously, the sessions contained only explicitly exported variables
and functions.
This was fragile and in part buggy due to lacking exports.
Interactive features like user-defined aliases and functions are still
working as before.
It doesn't make sense for bitcoind users to completely redefine their
config file. Also, it's poorly named and the description is faulty.
This is a breaking change, but this option has probably no actual users.
This fixes these flaws in `copy-root-authorized-keys`:
- When `.vbox-nixops-client-key` is missing, operator's authorized_keys
file is always appended to, growing the file indefinitely.
- Service is always added and not restricted to nixops-vbox deployments.
This avoids an extra delay and the unexpected creation of secrets when
run in another dir.
Needed for the 'fetch-release' script introduced in a later commit.
Disabling upnp via compilation brings no substantial security benefits.
There's no way to inadvertently enable upnp, it must be set explicitly
via bitcoind.extraConfig.
But it's a huge hassle for new users who have to recompile bitcoind
before being able to use nix-bitcoin.
Also, elementsd is currently built with upnp support by default.
Electrs allows defining settings multiple times via cmdline args, but
not via config files.
So 'extraArgs' is the only way to implement overridable settings,
'extraOptions' wouldn't work.
Use buildRustPackage instead of buildRustCrate (via crate2nix).
buildRustPackage builds the whole executable and its libraries in a
single `cargo build` process.
With the create2nix approach each library is built in a separate derivation,
directly using rustc instead of the cargo wrapper.
Benefits of buildRustPackage:
- Much simpler to maintain
- Package derivation evaluates much faster
Benefits of crate2nix:
- Build can be distributed over multiple build hosts
- Better sharing of common dependencies between different builds
- More fine-grained rebuilding on build failures
In nixpkgs buildRustPackage is used for almost all Rust pkgs, it's
also a better fit for our use case.
ProtectSystem=full disables writing to /etc which is the default
secrets location.
Besides that, hardening is pointless for {generate,setup}-secrets which
don't read external input and are fully under our control.
Each secret file to be deployed is now backed by one local file.
This simplifies 'setup-secrets' and the secret definitions.
Also, with the old format it was not possible to add new secrets
to secrets.nix in a simple way.
Old secrets are automatically converted to the new format when running
nix-shell.
Using the new option 'nix-bitcoin.secrets', secrets are now directly
defined by the services that use them.
This further speeds up builds, in particular the modules test in the
next commit. By checking if the expected final build output has already
been cached, we can even skip the download of cached builds.
Advantages:
- The build fails if a statement fails.
Previously, errors in all but the last statement were silently
ignored.
- The Travis log gives a fine-grained view of the output of each
statement.
Add if statements because the '[…] &&' prefix results in YAML syntax
errors.
- set -e is implicit
- coreutils are in PATH and don't have to be explicitly referenced (echo is a shell builtin anyways)
- exit 0 is unneeded ('if' statements never fail)
This better fits the semantics of this unit and allows for easier
automated testing whether the service is active.
wantedBy = bindsTo = after = tor.service is the simplest way to ensure
that this unit is always running/restarted in lockstep with tor.
Previously, onion-chef would have stayed inactive in the case
that tor was stopped and then later restarted.
Erik Arvstedt