This enables generating module option documentation.
This commit was genereated by running the following script inside the
repo root dir:
def add_default_text(file)
src = File.read(file)
src2 = src.gsub(/( = mkOption\s+\{[^{]*?)(\n\s+default = )(.*?);$(.*?\})/m) do |str|
pre, defaultVar, default, post = Regexp.last_match.captures
replacement =
if !post.include?('defaultText =')
if default =~ /\bpkgs\b/
defaultText = default.lines.length == 1 ? default : "(See source)"
"#{pre}#{defaultVar}#{default};#{defaultVar.sub('default', 'defaultText')}#{defaultText.inspect};#{post}"
end
end
replacement or str
end
File.write(file, src2) if src2 != src
end
Dir["modules/**/*.nix"].each do |f|
next if File.basename(f) == "nix-bitcoin.nix"
add_default_text f
end
Split `enforceTor` into `tor.proxy` and `tor.enforce`.
By enabling `tor.proxy` without `tor.enforce`, a service can accept
incoming clearnet connections.
E.g., this allows setting up a Tor-proxied bitcoind node that accepts
RPC connections from LAN.
- README: add matrix room
- examples/configuration.nix: explain why bitcoind is enabled by default
- btcpayserver: group lnd service settings
- clightning:
Use public onion port only when the onion service is public
This allows users to enable the onion service while announcing a
non-onion public address.
- netns-isolation: move `readOnly` attr to the top
- tests: use mkDefault to allow for easier overriding
- tests/btcpayserver: test web server response
This allows whitelisting local services without implicitly
whitelisting all inbound onion connections, which would happen when
setting bitcoind/liquidd option `whitelist=localhost`.
Used by electrs and nbxplorer, which requires the unsafe `mempool`
permission.
Whitelisting localhost implicitly whitelists all inbound onion
connections. This prevents banning misbehaving inbound onion peers
and enables message `mempool` which can cause privacy leaks.
Instead, grant `download` as the single bitcoind whitelist permission, which
should be safe for onion peers.
Remove liquidd whitelisting because it doesn't support fine-grained permissions.
After a cursory glance at the nbxplorer code I think that nbxplorer
requires none of the other default whitelist permissions (noban, mempool,
relay).
Details: https://github.com/dgarage/NBXplorer/issues/344
- Add nbxplorer to whitelists.
This is recommended by the nbxplorer docs and guarantees that nbxplorer
can always p2p-connect to bitcoind/liquidd.
- Enable bitcoind/liquidd p2p servers via `listen`.
Benefits of adding top-level variables for used services:
- Makes it obvious which other services are referenced by a service
- Less code
We already do this in many other places.
These are insignificant, generic options; place them above readonly options.
We already do this in other services.
Also move user/group config to bottom in spark-wallet.
This greatly improves readability and makes it easier to discover options.
This commit was genereated by running the following script inside the
repo root dir:
#!/usr/bin/env ruby
def transform(src)
return false if src.include?('inherit options;')
success = false
options = nil
src.sub!(/^ options.*?^ }.*?;/m) do |match|
options = match
" inherit options;"
end
return false if !options
src.sub!(/^with lib;\s*let\n+/m) do |match|
success = true
<<~EOF
with lib;
let
#{options}
EOF
end
success
end
Dir['modules/**/*.nix'].each do |f|
src = File.read(f)
if transform(src)
puts "Changed file #{f}"
File.write(f, src)
end
end
`generate-secrets` is no longer a monolithic script. Instead, it's
composed of the values of option `nix-bitcoin.generateSecretsCmds`.
This has the following advantages:
- generate-secrets is now extensible by users
- Only secrets of enabled services are generated
- RPC IPs in the `lnd` and `loop` certs are no longer hardcoded.
Secrets are no longer automatically generated when entering nix-shell.
Instead, they are generated before deployment (via `krops-deploy`)
because secrets generation is now dependant on the node configuration.
- btcpayserver: remove unneeded trailing semicolons
- krops/get-sha256:
`tail` is unneeded because `nix-prefetch-url` just outputs a single
line containing the hash.
Use the following order of definitions for all services:
- assertions
- configuration of other services
- environment.systemPackages
- tmpfiles
- own service
- users
- secrets
Systemd's `Description` option is a misnomer (as confessed by `man systemd.unit`):
Its value is used by user-facing tools in place of the unit file name, so this option
could have been more aptly named `label` or `name`.
`Description` should only be set if the unit file name is not sufficient for naming a unit.
This is not the case for our services, except for `systemd.services.nb-netns-bridge`
whose description has been kept.
As an example how this affects users, weird journal lines like
```
nb-test systemd[1]: Starting Run clightningd...
```
are now replaced by
```
nb-test systemd[1]: Starting clightning.service...
```
