I’ve been having an issue connecting to a remove node.
note: xxx is my ip for my server
[error] ** System NOT running to use fully qualified hostnames **
** Hostname xx.xxx.xxx is illegal **
I’m currently using edeliver to deploy to my server and noticed that it (“edeliver”) rewrites the vm.args on every
mix edeliver restart|start|stop
The name is set to be
I’m also noticing that I can’t find a way to set the name in vm.args via
And as one last opservation I noticed that there is a discrepancy in the
vm.args cookies vs
In this case which cookie should I be using?
It would look as if using --name when starting up my local iex addresses the error but does not address the connection problem. I get false now rather than an error + false.
I guess thats a step in the right direction.
Ok even closer, Looks like I’m fire walled.
So that being said I cant tell what port I need to open.
Feb 12 22:10:05 beffect-staging kernel: [ 4461.756735] [UFW BLOCK] IN=eth0 OUT= MAC=d6xxxx SRC=77.xxx DST=104.xxx LEN=40 TOS=0x00 PREC=0x00 TTL=246 ID=41954 PROTO=TCP SPT=57109 DPT=7516 WINDOW=1024 RES=0x00 SYN URGP=0
Source port? SPT=57109
Destination port? DPT=7516
It randomizes ports, you need to constrain it to a range. Here’s a mailing list thread about it:
The new Adopting Elixir book has an example of limiting the port and even removing epmd completely if you have that handy and want to go that far.
However, in the bigger picture, why are you
Node.connecting through a firewall? Normally this is used for multiple nodes in a cluster, and I’d generally hope they’re nearby, even on the same subnet. If you want to connect your local machine to a production machine, then you probably want a remote console or a hidden node and not a full node in the mesh.
Welp thats a bummer, I opened my ip to allow for any connection from my source and I no longer see the logs showing me being fire walled but I’m still getting false as a return
I’m really just trying to console into a production box with out shutting down the node thats running.
Is there a better way?
Ok success, sort of.
Only while on the same box and only when using 127.0.01 as per node name can I successfully connect
So does that mean if I want to connect from a different subnet do I have to set the node name to explicitly have the external ip address? if so I guess I will need to figure out how I can set the node name from edeliver
Ok I think I maybe going about this all the wrong way.
I just found remsh
Does this allow for me to interact with an already running node on a different box?
I wish I had a quick and easy solution. I’ve faced your difficulties, but I’ve not delved into the details I’ve seen in some blogs (and now books) to make it clean. You can set the nodename in distillery, which should be covered well in its hexdocs. I have settled for ssh-ing to the server in question and running
bin/myappname remote_console to use the distillery script to connect a hidden beam node to the production vm.
Well thanks for the help. I’ve narrowed it down to that I need explicitly set the node name to have an external ip rather than localhost or 127.0.0.1 if I want to remsh into from an external address. I guess I should look at ssh forwarding I think I seen a blog or two about that.
Whooohooo, ssh port-forwarding for the win!!
Thank you Erich Kist!
This is what I’ve been trying to do all day
If the name of a node is it’s IP, it will only bind to exactly this IP. So you need to be sure you can reach that IP from your current network. Things are easier when you use actual resolvable hostnames.