account password? about geth-dev HOT 13 CLOSED

my workaround was to not even try to unlock, but that meant to switch off the unlocking in my own code.

but would be better if personal.unlockAccount() would just be working.

from geth-dev.

perhaps this is the reason?

modules: eth:1.0 net:1.0 rpc:1.0 web3:1.0

might mean that not all rpc apis are accessible, right?

please by default open all those apis; this setup is not for production but for development only anyways, right?

from geth-dev.

You do not need to unlock the account, as it is already unlocked by default in the Images. Geth is started with the --unlock flag.

from geth-dev.

As I understand that it is not ideal to have all nodes automatically unlocked, would it help if the first node was unlocked by default and the other nodes needed to be unlocked via RPC?

from geth-dev.

You do not need to unlock the account

Yes, looks like case by case this differs. And in this case not.

What if my standard chainhammer code always does that, at the beginning?

Looks like I really have to include all kind of situation specific exceptions, have a look = that is prone to future problems, though.

from geth-dev.

was unlocked by default and the other nodes needed to be unlocked via RPC

IMHO account unlocking should be done by the client, i.e. my chainhammer. Simply for not to seduce a coder into assuming any account is wide open. There is a personal.unlockAccount() call for that, and it works well (and even in parity with parity --geth switch).

BUT I think for this great dev tool that you are supplying us with .... I think all RPC APIs could be made accessible, not only eth:1.0 net:1.0 rpc:1.0 web3:1.0

from geth-dev.

I think you are right. Being auto unlocked is almost never a use case which is useful. I will change this.

I am happy that the tool is helpful! I will create another task to enable all RPC API, and try to update it asap.

from geth-dev.

Changes merged in; accounts are no longer unlocked permanently.

from geth-dev.

Unfortunately, for the clique consensus protocol the nodes need to be unlocked in order to start mining. I enabled the unlocking again for the miner-1 and miner-2, the node behind miner-3 is not mining anyways and can be used for all applications which need to unlock manually.

from geth-dev.

for the clique consensus protocol the nodes need to be unlocked in order to start mining.

Oh, oops ;-)

which need to unlock manually.

All good as long as the personal.unlockAccount() function call is working. More a "which want to unlock manually" instead of "which need to unlock manually".

from geth-dev.

one more "oops":

https://github.com/javahippie/geth-dev/blob/master/miner/Dockerfile#L27

your 32c5455 is not part of master yet?

because I get this:

geth-miner-1             | INFO [08-28|08:53:54.162] Commit new mining work                   number=1 uncles=0 txs=0 gas=0 fees=0 elapsed=72.186µs
geth-miner-1             | WARN [08-28|08:53:54.162] Block sealing failed                     err="authentication needed: password or unlock"

and

geth attach http://localhost:8545
Welcome to the Geth JavaScript console!

instance: Geth/v1.8.14-stable-316fc7ec/linux-amd64/go1.10.3
coinbase: 0x8cc5a1a0802db41db826c2fcb72423744338dcb0
at block: 0 (Thu, 22 Feb 2018 17:25:57 GMT)
 datadir: /root/.ethereum
 modules: admin:1.0 debug:1.0 eth:1.0 miner:1.0 net:1.0 personal:1.0 rpc:1.0 web3:1.0

> eth.blockNumber
0
> eth.blockNumber
0

from geth-dev.

You are right. I am not sure what happened there, I committed the changes and merged to master

from geth-dev.

perhaps forgot to git push ?

from geth-dev.