The install_collectd_debian.sh script reads user input to obtain the
onion address. However, when you pipe the output of curl into the shell
you're making the script text be standard input of the shell, which
takes it in as commands to run. After that, there's nothing left to
read. Even if it were to try, it wouldn't get anything from the terminal
input, because it's not connected to it. The pipe has replaced standard
input for the shell process.
Instead, create a pipe for bash to read the output of curl from and
provide it as the script file argument. In this case, the standard input
of the script is still connected to the terminal, and read will work.
* Add seednode service option to enable dumping Bisq Markets data
* Add seednode service setting for DAO fullnode true/false
* Add seednode installer feature to use existing btcnode P2P/RPC config
* Rename to generic "bisq" service, set entrypoint as conf variable
* Split seednode systemd service ExecStart command into multiple lines
* Add setting in seednode configuration to specify btcnode host/port
* Tweak seednode torrc configuration options to improve P2P connectivity
* Require bitcoin.service from bisq-seednode.service via systemd binding
* Make seednode installer run from master and build bisq from release tag
* Seednode must be shutdown using `kill -9` until #3884 is fixed
* Fix seednode uninstall script to use correct service names
* Disable CircuitBuildTimeout in seednode Tor configuration
* Disable seednode torrc advanced configuration options for now
Option handling is now the responsibility of the Config class. JOpt's
OptionParser is no longer passed down to BisqExecutable subclasses'
doExecute method, as they can now rely on the Config abstraction.
In previous commits, BisqEnvironment functionality has been fully ported
to the new, simpler and more type-safe Config class. This change removes
BisqEnvironment and all dependencies on the Spring Framework Environment
interface that it implements.
The one exception is the pricenode module, which is separate and apart
from the rest of the codebase in that it is a standalone, Spring-based
HTTP service.
Note that the default value of 600 advertised in BisqExecutable's option
handling was incorrect. The actual value had since become 1200 MB. This
correct default is now reflected in Config's option handling.
