crypdex / blackbox

An ARM-first, pluggable framework for multi-chain deployments.
https://crypdex.github.io/blackbox
39 stars 4 forks source link

bitcoin.conf and lnd.conf not created on startup #17

Closed mikeghen closed 5 years ago

mikeghen commented 5 years ago

Here is my blackbox.yml:

version: '3.7'

services:
  lnd_bitcoin:

here is blackboxd version:

root@sparkswap:~# blackboxd version
0.1.51

here is blackboxd info:

root@sparkswap:~# blackboxd info
❯ BLACKBOX config:
services:
  bitcoin:
    command: -rpcuser=xxxx -rpcpassword=xxxx -rpcallowip=0.0.0.0/0 -zmqpubrawblock=tcp://0.0.0.0:28333
      -zmqpubrawtx=tcp://0.0.0.0:28334 -printtoconsole -txindex
    container_name: bitcoind
    environment:
      BITCOIN_NETWORK: testnet
    image: crypdex/bitcoin:0.17
    ports:
    - published: 8332
      target: 8332
    - published: 8333
      target: 8333
    - published: 18332
      target: 18332
    - published: 18333
      target: 18333
    - published: 18443
      target: 18443
    - published: 18444
      target: 18444
    restart: on-failure
    volumes:
    - /mnt/data/friendfund/bitcoin:/home/bitcoin/.bitcoin:rw
  lnd_bitcoin:
    command: --rpclisten=0.0.0.0:10009
    container_name: lnd_bitcoin
    depends_on:
    - bitcoin
    environment:
      BACKEND: bitcoind
      BITCOIN_RPCPASS: xxxx
      BITCOIN_RPCUSER: xxxx
      CHAIN: bitcoin
      NETWORK: testnet
    image: crypdex/lnd:0.6
    restart: on-failure
    volumes:
    - /mnt/data/friendfund/lnd:/home/lnd/.lnd:rw
version: '3.7'

On start the bitcoin.conf and lnd.conf are not created. I expect they would be created and would have the .env variables I've added. As a work around, I just add these files manually for now.

dmichael commented 5 years ago

When you pass variables as flags at the command line, they override anything in the .conf files. As far as I know, you don't even need have the .conf files there for bitcoind. The general strategy for all services is to parameterize the service with flags at the command line, or (newer) environment variables in the shell that are pickup up by the entrypoint. The intent is to reduce the number of places you need to check for params.

That being said, the prestart.sh script will attempt to create a blank .conf file on startup. I even see there that it is writing in the rpcuser and rpcpassword.

Is the issue that you would like to see .conf files created and they are not? Or that the service is not booting because they are not there?

mikeghen commented 5 years ago

I would like the conf file to exist, I think that'll just be easy to understand and troubleshoot in the future. Also, the service boots but WITHOUT my .env taking effect, this was noticable with trying to run on testnet so maybe try to run this service with testnet and see if you can actually get it running on the testnet

dmichael commented 5 years ago

I have run this on testnet and it does work. What does your .env look like and where is it located? Since the info command shows the flags being passed - it would seem it is picking up .env. Which vars are missing or incorrect? It might just be the name.

dmichael commented 5 years ago

Blackbox parameterizes services using flags provided to each service's daemon. These flags are defined in the default service definitions for the most part and sometimes in the entrypoint.sh for the Dockerfile (depending upon how the service is being used). This lets us reuse data directories regardless of which variant of the service definition is in use and greatly simplifies getting services setup since it requires a user to manage on only 1 config and 1 set of variables regardless of how many different services are in use (think Bitcoin, Litecoin, LND, and Sparkswap which would require managing 5 conf files in 5 different locations).

Here are the flags for LND's version of bitcoind. These are different than the default vanilla bitcoind but both can run from the same data directory without the user doing anything special. If configuration was .conf file-driven, the user would be required to modify the .conf file manually for each variation on the service - or Blackbox would need to be in the business of parsing and writing .conf files of various flavors. (This is actually being attempted in some early services like PIVX and it does not work well.)

That being said, developers are welcome to add .conf files for each service of interest, but be aware that flags will override whatever is defined there.

If there is an issue with getting env vars set or getting the services standing, we can troubleshoot those issues specifically.

dmichael commented 5 years ago

Ok. After some debate and development, blackbox now uses conf files.