Go-ethereum: Can't create bootnode in private network

[boorac]

Following the guide at https://github.com/ethereum/go-ethereum/wiki/Private-network , I am attempting to create a bootnode in a private network.

Both the command bootnode --genkey=bootnode_keys/boot.key and bootnode --nodekey=bootnode_keys/boot.key execute indefinitely.

System information

Geth version:

Version: 1.6.0-stable
Git Commit: facc47cb5cec97b22c815a0a6118816a98f39876
Architecture: amd64
Protocol Versions: [63 62]
Network Id: 1
Go Version: go1.8.1
Operating System: linux
GOPATH=/home/matteo/.gvm/pkgsets/go1.6/global
GOROOT=/home/matteo/.gvm/gos/go1.6

OS & Version: Linux

Kernel: 4.8.0-42-generic x86_64
Distro: Linux Mint 18.1 Serena

Expected behaviour

bootnode --genkey=bootnode_keys/boot.key should generate a file boot.key with the appropriate content and finish execution.

bootnode --nodekey=bootnode_keys/boot.key should start the bootnode.

Actual behaviour

bootnode --genkey=bootnode_keys/boot.key generates a file bootnode_keys/boot.key with the content c25c3e86cddcdfd08a34784f107c3bebff67e7ce1a86d6f399c0a8836b4f7a3d but never finishes execution.

bootnode --nodekey=bootnode_keys/boot.key does not seem to startup the node and just runs indefinitely.

Steps to reproduce the behaviour

Execute any of the given commands.

Backtrace

None.

[bas-vk]

Thx for reporting this. If the bootnode is started with the nodekey flag it will start up the bootnode and waits indefinitely while serving requests. That is expected behavior. You can see what is happening with the verbosity flag. The genkey flag is a bug, in that case the bootnode will generate a key and start up the bootnode instead of stopping after creating the key.

[karalabe]

We should probably add some logging to the bootnode too so the user has a clue as to what's happening.

@boorac My best suggestion at the moment for private network scenarios is to just have a full node act as the bootnode too (a bootnode is essentially a real node with no higher level protocols running, just the P2P discovery). The reason that might be a nice choice is that it also acts as a data store for your blockchain and other nodes can sync with the bootnode too if noone else is available.

[boorac]

@bas-vk Thanks for the vebrosity flag suggestion, but the command bootnode --nodekey=bootnode_keys/boot.key -verbosity 3 does not log anything to the command line. How can I check if the node is really online, and if there is a log file, where should it be located?

@karalabe Using a full node as a bootnode is a good workaround for my use-case. Since I'm green at Etherium, is there a good online reference to set up a full node as a bootnode?

Tnx.

[karalabe]

@boorac We've added a new tool to Geth 1.6 called puppeth which could help set up smaller scale private networks (as it's new, it might have some rough edges). That's how we're hosting the Rinkeby testnet for example (https://www.rinkeby.io/). Everything you see there (apart from the block explorer) was deployed and is maintained via puppeth. If you have a spare machine/vm to deploy the bootnode/stats server/faucet etc on, it might be an easy tool to use.

If you want to roll manually, I'd suggest using puppeth to create your genesis file and save it. Then you can init a full node via geth --init genesis.json, after which just start like any normal geth node. It will print it's enode address that you can use to set as --bootnode for others. Only take care that the IP address is correct (geth tries to display your external IP, which might be wrong in a private network setting, and it might also be [::] if it can't difure it out); just change that to whatever address your machine is reachable at.

[boorac]

@karalabe - I've successfully used puppeth to create a network and have deployed an ethstats node and a bootnode. As far as I can see, it really doesn't have the blockchain explorer (a shame, it's a great tool).

Regarding this issue, a PR has been opened so I'm closing this.

Thanks again for your assisance.

[bas-vk]

@boorac for future references:

> bootnode --verbosity 5 --nodekey /tmp/bootnode.key 
DEBUG[04-24|13:07:59] UDP listener up                          self=enode://48d1cf3d51338cdecdcada3318e2933766476e02aadbda90c997e3c82147384e8fe935513150df9c9120a404bf817834401fe020d3f297394fb83d6b7032c1da@[::]:30301

Maybe we should raise the log level for this statement.