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.
An executable is more robust to use than shell aliases.
This is also a preparation for commit 'add module test' because the
NixOS testing framework makes interactive aliases hard to use: It
unsets 'PS1' which is used by programs/bash/bash.nix to detect
interactive shells.
43507a7ce5 Update assumevalid to block 605181 (Jonas Nick)
Pull request description:
Top commit has no ACKs.
Tree-SHA512: 717b4885aad72b5ac86e1d7c9644732e6559055cef138f1a8adad0414760886ef58593fe24717cd070ce86728df9e738613f26c7f08a7c711088226f04f394f3
Not polluting the main pkgs namespace with internal pkgs makes it
easier to integrate the nix-bitcoin modules into a larger config.
Also, by overriding the nix-bitcoin namespace, users can now easily set the
packages used by services that offer no explicit `package` option, like `clightning`.
Remove use of nixops-specific 'keys' group and key services.
Instead:
- Add nix-bitcoin-secrets.target, which should be required by all
units that depend on secrets. (To keep it simple, it's okay to meet
the secrets dependency indirectly by e.g. depending on bitcoind.)
Various secret deployment methods can use this target by
setting up the secrets before activating the target.
In case of nixops we just specify that nixops' keys.target comes
before nix-bitcoin-secrets.target.
If the target is left undefined in the case of manual secrets
deployment, systemd will simply ignore unit dependencies on
the target.
- Allow all users to access the secrets dir.
The access protection for the individual secret files is unchanged.
This allows us to drop the unit dependency on the nixops 'keys' group.
c36c496507 banlist: fail on unexpected errors (Erik Arvstedt)
e0276503ed fixup! ignore banlist errors (like in master) (Erik Arvstedt)
d64156e485 banlist: don't wait in preStart until bitcoind is ready (Erik Arvstedt)
d87c50a305 banlist: simplify unit, bind to bitcoind, fix wantedBy (Erik Arvstedt)
39885d37c1 banlist: simplify script, remove package (Erik Arvstedt)
55e73f32e3 bitcoind: add cli option (Erik Arvstedt)
8807b9f6b2 bitcoind: remove 'StateDirectory' (Erik Arvstedt)
Pull request description:
Please see the individual commit messages for more infos.
This time I've used commit msg titles starting with lower-case letters.
I think this style is the simplest and cleanest, especially with
`topic:` prefixes. Let me know if I should reformat this.
Regarding commit `banlist: simplify script, remove package`:
I've added the current version of Greg's banlist, but it has 5600 entries instead of the previous 739. Is this ok?
Rationale for commit `bitcoind: add cli option`:
For some cases it can be useful when bitcoin-cli is an executable instead of a shell alias.
- non-interactive ssh commands like `ssh mynode 'bitcoin-cli getnetworkinfo'`.
This can also be achieved with shell aliases in `environment.shellInit`, but it's good
practice to avoid aliases in noninteractive shells.
- Scripts that call `bitcoin-cli`. The banlist importer which uses this is a good example.
ACKs for top commit:
jonasnick:
ACK c36c496507
Tree-SHA512: 31dacf5e5b051ada24151c9884a97cfd83883c2b48e3d25e16f228fb575cb915e1093d12d171a44d25064fda7d7b98a27c897cc4bdace527c52fdf652033a160
