search

openethereum / parity-deploy

Parity deployment script.
Apache License 2.0
81 stars 52 forks source link

unable to find user parity: no matching entries in passwd file #92

Closed drandreaskrueger closed 5 years ago

drandreaskrueger commented 5 years ago

found a new one:

git clone https://github.com/paritytech/parity-deploy.git paritytech_parity-deploy
cd paritytech_parity-deploy/
git log | head -n 5
commit 11b64e11cc9403101aa1e0db0bfbc72997e01a74
Merge: 80a0fd8 c1dc457
Author: ddorgan <david@peersystems.co.uk>
Date:   Wed Dec 12 21:29:02 2018 +0000
which parity
sudo rm /usr/bin/parity
./parity-deploy.sh -r v1.11.11 --nodes 4 --config aura --name myaura --geth --gasprice 0 --tx-queue-mem-limit 0
sed -i 's/parity:stable/parity:v1.11.11/g' docker-compose.yml
jq ".engine.authorityRound.params.stepDuration = 5" deployment/chain/spec.json > tmp; mv tmp deployment/chain/spec.json
docker-compose up
ERROR: for host4  Cannot start service host4: b'linux spec user: unable to find user parity: no matching entries in passwd file'
...
drandreaskrueger commented 5 years ago

quick'n'dirty fix:

sed -i 's/user:\ parity/user:\ root/g' docker-compose.yml
ddorgan commented 5 years ago

@drandreaskrueger version v.11.11 is actually before we introduced the parity user to the containers and we do not backport these changes to existing versions in case it breaks something. Also parity v1.x is no longer supported.

However I know you're using this version due to the performance you see there vs later versions.

But on a point of the testing, would I be right in saying you pre-sign geth transactions because you cannot do this directly? If so then shouldn't you also pre-sign the parity transactions and use a later version of the software to get an apples to apples comparison of both platforms.

ddorgan commented 5 years ago

Closing this as we won't be updating the v1.11.11 image, however please feel free to open another issue for any outstanding questions on this.

drandreaskrueger commented 5 years ago

Hello @ddorgan

First the misunderstanding:

would I be right in saying you pre-sign geth transactions because you cannot do this directly?

No, I don't.
Where does this misunderstanding come from?

I am either using this call or I am using this call.

But neither is pre-signing.

I dimly remember that misunderstanding had happened already, a while ago. So then I wrote this page here for you. Please read this now: FAQ ... send via ...

to get an apples to apples comparison of both platforms.

yes, both geth and parity --geth are treated exactly identical. Already.

What I also tried out was to start parity without the --geth switch, and unlock the account per CLI; it did not give speed-up.

drandreaskrueger commented 5 years ago

But:

Also parity v1.x is no longer supported.

Then I must introduce an artificial difference between parity and geth (which would forever give a disadvantage to parity):

Mentioning that here, because v1.11.11. did NOT have that issue, back then I could fire at the node from many parallel threads at once.

So ... I suggest you keep on supporting v1.11.11 somehow (see e.g. my quick fix above, that should be easy for you to implement, depending on user-chosen version number. And without "updating the v1.11.11 image").

Then I could report numbers for

What do you think?

drandreaskrueger commented 5 years ago

feel free to open another issue for any outstanding questions on this.

@ddorgan (even with this #92 closed now) are my above 2 comments of today covered sufficiently, or do I have to open yet another issue?

ddorgan commented 5 years ago

@drandreaskrueger no that's fine. I'll send you a follow up later today with some findings...

drandreaskrueger commented 5 years ago

simple patch for

v1.11.11 instantseal https://github.com/paritytech/parity-deploy/issues/76#issuecomment-456473262

v1.11.11 aura https://github.com/paritytech/parity-deploy/issues/76#issuecomment-456479049