I've geth node running on my local and I need to find out http url and ethereum url to deploy dapp on Mix IDE. Can any one please help and tell where to find these two parameters ?
If you are in default mode probably one of those ports:
8545 TCP, used by the HTTP based JSON RPC API
8546 TCP, used by the WebSocket based JSON RPC API
Are you connecting through JSON RPC API?
$ geth attach ipc:/some/custom/path
$ geth attach http://191.168.1.1:8545
$ geth attach ws://191.168.1.1:8546
Note that by default the geth node doesn't start the http and weboscket service and not all functionality is provided over these interfaces due to security reasons. These defaults can be overridden when the --rpcapi and --wsapi arguments when the geth node is started.
Related
I am trying to send transactions via web3.py interface that is connected to a local geth node. Having read some comments on why using RPC is bad, I am still wondering if using -rpc option is unsafe when port 8545 is closed. According to this article (https://www.zdnet.com/article/hackers-ramp-up-attacks-on-mining-rigs-before-ethereum-price-crashes-into-the-gutter/) the vulnerability is just on exposed ports, but since I am basically communicating with a node on local network this shouldn't be a problem right?
The article covers an attack vector, where the attackers look for machines with opened port 8545 and try to run JSON-RPC commands (on these machines) that would benefit them. This attack only works if:
The machine has the port 8545 opened to public
The port is used by an Ethereum node (and not some arbitrary app)
The node has enabled JSON-RPC
The node hasn't enabled the user/password credentials for JSON-RPC
So as long as your node is only accessible on a local network, you are pretty much safe from this attack vector (assuming there's no port forwarding etc. that would actually allow accessing your node from a public network and that there's no attacker on your local network).
I am working on a project that requires me to have multiple network interfaces. I followed the documentation and created three interfaces. I also changed the firewall rules. But even after changing the firewall rules, I am not getting a reply for an ICMP request to the second interface's external IP.
As seen in the screenshot I have allowed all protocols from anywhere to any instance in my network enter image description here
If you look at the routing table of your VM instance, you'll see that the default route is configured on the primary network interface eth0:
vm-instance:$ ip route
default via 10.156.0.1 dev eth0
...
Whether an Ephemeral or a Static External IP address is configured, this External IP is unknown to the operating system of the VM instance. The External IP address is mapped to the VM's Internal address transparently by VPC. You can verify this with the command
vm-instance:$ ip -4 address show
You'll see that there are no External IPs bound.
Furthermore, IP packet forwarding is disabled both between the network cards of the VM instance and network interfaces of Google-provided Linux. The commands below can verify that:
CloudShell:$ gcloud compute instances describe vm-instance --zone=your-zone | grep canIpForward
vm-instance:$ sudo sysctl net.ipv4.ip_forward
Therefore when a ping packet is received by a secondary interface, it can't reply.
To explore this behavior a bit, you may launch tcpdump on the VM instance so that listen on a secondary interface, for example eth1:
vm-instance:$ sudo apt-get install tcpdump
vm-instance:$ sudo tcpdump -i eth1
then find out External IP of your Cloud Shell appliance and ping the secondary External IP of your VM instance from Cloud Shell:
CloudShell:$ curl ifconfig.me/ip
CloudShell:$ ping [secondary_ip_of_vm_instance]
You'll see in the tcpdump output on the console of your VM instance how ICMP packets are arriving to the eth1 interface from the External IP address of your workstation. But they are not replied.
Google provides explanation of this behavior in the Troubleshooting section of the VPC documentation and suggests possible workarounds:
Virtual Private Cloud > Doc > Creating instances with multiple network interfaces > Troubleshooting > I am not able to connect to secondary interface using external IP:
The DHCP server programs a default route only on the primary network
interface of the VM. If you want to connect to the secondary interface
using an external IP, there are two options. If you only need to
connect outside the network on the secondary network interface, you
can set a default route on that network interface. Otherwise, you can
use Configuring Policy
Routing
to configure a separate routing table using source-based policy
routing in your VM.
I have deployed the Spring boot app on the OCI compute and its comping up nicely. Compute is created with public ip and have the security list updated to allow connections from internet. But, I wasn't able to hit the end point from internet. For that reason, I thought of configuring the load balancer.
Created load balancer in a separate subnet(10.0.1.0/24), routing table and security list. Configured the LB's security list to send all protocol packets to compute's CIDR(10.0.0.0/24) and configured compute's security list to accept the packets from LB. I was expecting LB to make connection with back end. But, its not.
I am able to hit the LB from internet :-
Lb's routing table with all ips routed through internet gateway. There is no routing defined for compute's CIDR as its in the VCN.
LB has its own security list, which has allowed out going packets to compute and incoming from internet as below:
Compute's security list accepting packet's from LB:
Let me know, if I am missing something here.
My internet gateway :-
My backend set connection configuration from LB:
LB fails to make connection with backend, there seems to be no logging info available :
App is working fine , if I access from the compute node :
The LB has a health check that tests the connection to your service. If it fails, the LB will keep your backend out of rotation and give you the critical health like you're seeing.
You can get to it by looking at the backend set and clicking the Update Health Check button.
Edit:
Ultimately I figured it out, you should run the following commands on your backend:
sudo firewall-cmd --permanent --add-port=8080/tcp
sudo firewall-cmd --reload
Use the port that you configured your app to listen on.
I used httpd instead of spring, but I also did the following
sudo semanage fcontext -a -t httpd_sys_content_t "/var/www/html(/.*)?"
sudo restorecon -F -R -v /var/www/html
I'm not really too familiar with selinux but you may need to do something similar for your application.
Additionally, setting up a second host in the same subnet to login to and test connecting to the other host will help troubleshooting, since it will verify if your app is accessible at all outside the host that it's on. Once it is, the LB should come up fine.
TL;DR In my case it helped to switch the Security List rules from stateful to stateless on the 2 relevant subnets (where the loadbalancer was hosted and where the backends were located).
In our deployment I had a loadbalancer with public IP located on one subnet, while the backend to this loadbalancer was on another subnet. Both subnets had one ingress and one egress rule - to allow everything (i.e. 0.0.0.0/0 and all ports allowed). The backends were still not reachable from the loadbalancer and the healthchecks were failing.
Even despite the fact that in my case as per the documentation switching between stateful and stateless should not have an effect, it solved my issue.
I am trying to setup a websocket connection to the Kubernetes Pod Exec API, based on the suggestions given in this SO post: How to execute command in a pod (kubernetes) using API?.
Here's what I have done so far -
Installed Simple Web Socket Client extension in Chrome.
Started kubectl proxy --disable-filter=true to run proxy with WS connections allowed. kubectl.exe version is 1.8.
Used address ws://localhost:8001/api/v1/namespaces/default/pods/nginx-3580832997-26zcn/exec?container=nginx&stdin=1&stdout=1&stderr=1&tty=1&command=%2Fbin%2Fsh in the Chrome extension to connect to the exec api.
When I click connect, Chrome reports back an error with the message -
Error during WebSocket handshake: Response must not include 'Sec-WebSocket-Protocol' header if not present in request
Apparently, kubectl is sending back empty Sec-WebSocket-Protocol header in the response and Chrome is taking offense to that.
I tried changing the code of Simple Web Socket Client open method to send empty protocols parameter to the Websocket client creation call, like - ws = new WebSocket(url, []); to coax Chrome in sending empty header in request, but Chrome doesn't send empty header.
So what can be done to directly connect to the exec in Chrome?
This is a known issue; kubectl proxy does not support websockets. (You can verify this easily by starting up kubectl proxy and then attempting kubectl --server=http://127.0.0.1:8001 exec ...; you will receive the message error: unable to upgrade connection: <h3>Unauthorized</h3> if the filter is enabled and Error from server (BadRequest): Upgrade request required if the filter is disabled).
The confusion might come from the fact that the kube-apiserver proxy does support websockets, but that proxy is different from the kubectl proxy.
As I see you have 3 options now (in order of difficulty):
Access kube-apiserver directly. You will likely need authentication that kubectl proxy is handling for you now
Use SockJS, this is what Kubernetes Dashboard does for the exec feature
Fix #25126
After reading the code in https://github.com/kubernetes-ui/container-terminal/blob/master/container-terminal.js, found that exec uses base64.channel.k8s.io protocol. The Simple Web Socket Client code wouldn't have worked because of this and also that the stream communication is in base64, not plain text.
Leaving this as an answer for other folks trying to implement a WS based terminal emulator... as #janos-lenart mentioned, the code is pretty new and there may be issues using it in different browsers, best bet at this point is to read example code and start from there.
I signed up in Fiware and created an account for Cosmos.
I was able to ssh on the head node, but I coulnd't use the API for webhdfs or cosmos.
I used curl on my ubuntu shell like this:
curl -i
http://cosmos.lab.fi-ware.org:50070/webhdfs/v1/user/username?[user.name=username&password=*****]op=GETHOMEDIRECTORY
I wasn't able to get any response from that, though.
Can someone point me what I might be doing wrong here? Am I forgetting anything?
We have deployed a HttpFS gateway at FILAB, which listens in TCP/14000. This HttpFS hides the datanodes and only the namenode is reachable, but the WebHDFS API remains the same.
Please observe your curl's or application calls must be done from a FILAB VM as well.