5

There is a general problem that is affecting most everyone who tries to initialize AWS hosted servers with a remote Geth instance. It would be great to have documentation to address a fix or at least a workaround.

As demonstration, I have a problem connecting to my ec2 hosted Geth node from my AWS Express server with web3. I think a critical breaking point is security groups setup. I've given lax permissions to geth options on startup geth --rpc --rpcapi eth,web3,personal --fast --rpcport 8545 --rpcaddr 0.0.0.0 --rpccorsdomain "*" --testnet. This should be ok, assuming only my server IP is whitelisted in the Geth assigned security group. I have no issues testing contract deployment from my Geth client using web3 requests from an Express server on my local machine (my local IP is also whitelisted).

Now, given the assumption that problems connecting to Geth are coming either from the AWS Express server on startup or from Geth instance security rules, here are a list of potential security questions I have that will hopefully lead to a fix.

Specifically regarding ingress rules for the Geth client:

  1. Is TCP with the Express server's public IP and port 8545 sufficient to connect?
  2. Are UDP and TCP on port 30303 from all IPs a necessary requirement? (Other ports like 30304/30301? Some confusion in forums about legacy ports.)
  3. Is ICMP required to be open? (I doubt pinging is necessary to establish an initial connection but I don't know.)
  4. Are NAT options required on Geth startup?
  5. Also, egress rules are completely open.

Regarding an AWS hosted Node/Express server:

  1. Does the instance (or load balancer) have to allow messages from the Geth client? (I've included them in my rules just in case.)
  2. An error that many users see on server spinup begins with these lines of code:

Error log-

{Error: EROFS: read-only file system, open '.node-xmlhttprequest-sync-1'
at Error (native)
at Object.fs.openSync (fs.js:641:18)
at Object.fs.writeFileSync (fs.js:1347:33)
at send (/var/task/node_modules/xmlhttprequest/lib/XMLHttpRequest.js:477:10)
at HttpProvider.send (/var/task/node_modules/web3/lib/web3/httpprovider.js:91:13)
...
...}

Perhaps some permissions require modification in the OS.

Here is my standard web3 config:

var Web3 = require('web3');
var web3 = undefined;
var fs = require('fs');

if (typeof web3 !== 'undefined') {
  web3 = new Web3(web3.currentProvider);
} else {
  // set the provider you want from Web3.providers
  web3 = new Web3(new Web3.providers.HttpProvider("http://xx.xxx.xx.xxx:8545")); //Geth node
}

exports.accounts = web3.eth.accounts;

exports.myContract = web3.eth.contract(JSON.parse(fs.readFileSync('./compiled_contracts/myContract.abi', 'utf8')));
exports.myContractCompiled = "0x" + fs.readFileSync('./compiled_contracts/myContract.bin');

exports.web3 = web3;

I'm hoping someone has some clear insight to share here.

  • Can you show your web3 code? – Vitaly Migunov Mar 30 '18 at 2:40
  • And are you accessing geth directly via IP or via an external DNS hostname? – Vitaly Migunov Mar 30 '18 at 2:45
  • @VitalyMigunov I added my code, which is standard web3 init. I am accessing directly via IP. I can get server to spinup without errors if my Geth client security rules allow for all traffic. However, if I restrict to my server VPC as TCP only before spinning up, the init fails. I can restrict Geth security AFTER server spinup and then communication is fine. Very strange. I doubt ICMP or even UDP on port 30303 is required. I'm wondering if there's a proxy issue. – GViz Mar 30 '18 at 19:03
  • The best (and probably correct) setup is to use ssh tunnels, which is what I do now with local port forwarding. – GViz Oct 8 '18 at 19:23
0
  1. Is TCP with the Express server's public IP and port 8545 sufficient to connect?

Yes, it does not require any other port open

  1. Are UDP and TCP on port 30303 from all IPs a necessary requirement? (Other ports like 30304/30301? Some confusion in forums about legacy ports.)

Yep, as far as I see those ports are not in use anymore.

  1. Is ICMP required to be open? (I doubt pinging is necessary to establish an initial connection but I don't know.)

Nop in this case, the handshake is made thought JSON-RPC on port 8545

  1. Are NAT options required on Geth startup?

None, I have a server running, although not in AWS, and I did not set up any NAT options to make it work.

As far as I can understand of your issues, it seems to be related to AWS and a filesystem default permissions.

I found this issue from a guy who suffered the same error. He sorted it out by changing the working directory to /tmp at the beginning of the node script as follow:

process.chdir('/tmp'); 

https://nodejs.org/api/process.html#process_process_chdir_directory

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.