By using the `default` flake module for tests, `pkgsUnstable` in
`pkgs/default.nix` gets passed the `nixpkgs-unstable` flake input
instead of falling back to importing `nixpkgsPinned.nixpkgs-unstable`.
For some use cases this prevents importing `nixpkgs-unstable` twice
(once via the `nixpkgs-unstable` flake input, once via
`import nixpkgsPinned.nixpkgs-unstable`).
- Add `doCheck = false` and `pythonImportsCheck` where appropriate.
This is good practice in general, but specifically works around a
`buildPythonPackage` bug where the test phase fails due to a
requirements check that is unrelated to testing.
- Enable tests for `jmbitcoin`.
- Patch some requirements. I've checked the release notes of the
required deps for backwards compatibility.
Without this, the `npm ci` command in `fetchNodeModules` hangs.
It seems that npm didn't check certs previously, because these are
not availble in Nix build environments by default.
Since PostgreSQL 15, DB users need to be DB owners to be able to create tables.
We can't use the new `ensureDBOwnerhip` NixOS option [1] to set this up,
because it requires the PostgreSQL user name and the database name to be
identical, which is not the case for btcpayserver.
Instead, we manually issue a PostgreSQL admin statement similar to the one
used by `ensureDBOwnerhip`.
This method of setting up the user is also compatible with older
PostgreSQL versions that come with older NixOS `system.stateVersion`s.
[1] https://github.com/NixOS/nixpkgs/pull/266270
Now all services that access secrets only run after the secrets setup
has finished.
Previously, we assumed that the systemd `after` dependency is
transitive, i.e. that adding an `after = [ "bitcoind.service" ]`
to a service implicitly pulled in the `after` dependency to
`nix-bitcoin-secrets.target` (which is defined for `bitcoind`).
This is not the case. Services could start before secrets setup
had finished, leading to service failure.
1. This simplifies the setup
2. Fixes a bug where a user skipped step 4.6 (run `nix-shell`) which
he deemed superfluous because a Nix shell was already active.
This caused an error during deployment.
By disabling `trustedcoin.tor.proxy` and enabling `clightning.tor.proxy`,
`trustedcoin` can be used without Tor proxying, while clighting still
uses Tor for lightning layer connections.
Previously, disabling Tor for `trustedcoin` required to also disable
Tor for clightning.
Also fix the workaround in the docs for the trustedcoin Tor connection issues:
The previous config snippet only affected systemd hardening settings,
but didn't disable Tor for trustedcoin.
This decouples modules `clightning` and `trustedcoin`.
`clightning` no longer depends on `trustedcoin`, which restores
the acyclic dependency graph described in `modules.nix`
lnd and lightning-loop resolve `localhost` to an IPv4 address when
creating RPC sockets.
Since NixOS 23.05, RTL (nodejs) resolves `localhost` to an IPv6
address when connecting to lnd and lightning-loop, which leads to
connection errors.
To fix these and other potential errors, replace all instances
of `localhost` with `127.0.0.1`.
A convenience helper which allows running most `sudo` cmds while
`doas` is enabled.
This is safe because all args supported by both `sudo` and
`doas` that lead to command execution (like `-u <user>`)
have identical semantics.
Best practice for flakes containing NixOS modules.
`push-release` now pushes to an extra branch named `nixos-<version>`,
alongside branch `release`.
This allows users to track a specific NixOS release, so that their
config doesn't break when nix-bitcoin switches to a new NixOS
release.
- Generate lndconnect URLs with protocol `c-lightning-rest` for clightning.
(Zeus now auto-detects the lightning implementation by the URL protocol.)
- Use improved QR code format (via qrencode) .
For both lnd and clightning-rest, `lndconnectOnion` is replaced by
options `lndconnect.enable` and `lndconnect.onion`.
This allows using lndconnect without Tor.
Erik Arvstedt