MySQL Replication and myAppExample, which IP to point the app to? To the Master, Router, one of the slaves?
I setup a typical lamp stack and also a MySQL InnoDB cluster.
myAppExample: 10.3.1.9
mysql-0 : 10.3.1.10
mysql-1 : 10.3.1.11
mysql-2 : 10.3.1.12
mysql-router: 10.3.1.13
What is the norm, best practice, or intended use of the replication method?
Should I point my myAppExample to the mysql-0 (master), or to the Router? Or to one of the slaves?
I would think to point it to the router, so the cluster will route traffic to read or write accordingly for performance.
Do I point it to the router or to the master?
Thank you.
I've never done this, and I can't find documentation anywhere where to point the app after you set it up.
Solved.
There are a few questions here, let me address each of them.
You must point your myAppExample to the Router, not to node 0(master), nor other nodes 1,2,3,etc(slaves).
Yes, the app will refuse the connection to the mysql router, say it's at 10.3.1.12.
Connection works to the master(node-0), 10.3.1.9, since it looks for port 3306 by default.
You must specify which port to connect to the router, it's not port 3306, it's port 6446,
So in your app, you connect to your mysql server(actually the router), like this, 10.3.1.12:6446
Related
I created a Postgres DB on RDS from my home in country X, currently I am in Y and I can not access the DB. I get a connection timed out response. The DB is set to be publicly accessible. I guess it has something to do with subnets / ACL or something similar. Since I am new to AWS I would love to get help for a quick fix. I need the DB to evaluate a project, later on I plan to dive deeper into AWS.
Thanks for your help.
If you have not modified the default ACL then that should not be the problem.
Since it worked when you were at home, I believe your already have the correct route set in your VPC route table (0.0.0.0/0 to internet gateway).
I would start pinging the RDS connection endpoint to make sure you are able to resolve the hostname and there is no typo (I made this mistake before).
My first guess is that the issue lies in the RDS instance security group inbound setting. You need to make sure you are allowing port 5432 (Postgres default port) connection from either 0.0.0.0/0 (Anywhere in the world) or your location Y IP address (Checkout whatismyip.com if you are unsure).
If you have a multi-az deployment, another unlikely scenarios might be that the RDS instance in subnet A failed over to the secondary RDS instance in subnet B, which has a different subnet / route table setting.
(I've searched SO, AWS support and more widely without success.)
I've just successfully deployed a MEANjs application to a Bitnami MEAN instance on EC2, following Ahmed Haque's excellent tutorial on scotch.io. As part of the tutorial/deployment I altered the AWS Security Group to include port 27017 for MongoDB traffic. The CIDR notation for the port 27017 was 0.0.0.0/0 - which AFAIK means 'allow access from any IP address'.
Question: Why does MongoDB port 27017 need to be opened in AWS EC2
Security Group for a 'production' type environment? Surely this is directly exposing the DB to the
Internet. The only thing that should be talking to Mongo is the
"/server/api" code, which is running on the same instance -
and so shouldn't need the port opening.
If I change the Security Group rule for port 27017 by closing off 27017, changing the source to: localhost, the internal IP address, the public IP address, or hack a CIDR to be equivalent to any of those - then the web app hangs (static content returns but no responses to db backed api calls). Changing the SG rule back to 0.0.0.0/0 almost immediately 'fixes' the hang.
All is otherwise sweet with my install. I've closed port 3000 (the node app) in the Security Group and am using Apache to proxy port 80 traffic to port 3000. Set up like this, port 3000 does not need to be open in the Security Group; to me this implies that on-instance traffic doesn't need ports to be externally exposed - so how come that's not true of the Mongo port?
I cant see anything in the '/client' code which is talking direct to Mongo.
What am I missing?
Thanks in advance - John
OK, after further investigation and overnight/red wine reflection I think I have an answer for those learners like me following the above tutorial (or similar). Following the Agile principle that 'done' means 'working code in a production environment' I was trying to understand the last 5 meters as a developer trying to get code working in a representative production environment (which wouldn't have unnecessary ports open) - this answer is written from that perspective. (Builds welcome from wiser readers.)
What's Happening
The step in the tutorial which (a) changed the Mongo bind IP address from 127.0.0.1 to 0.0.0.0, and (b) specifies a connection URL which uses the external IP address of the same instance, appears to have two effects:
It makes the MongoDB on the instance you're configuring potentially available to other instances (0.0.0.0 tells Mongo to "listen on all available network interfaces".)
It means that the IP traffic from your MEAN app /server component on the same instance will talk to Mongo as though it was coming from off-instance (even though it's on the same instance). Hence the Security Group needs to make port 27017 open to allow this traffic to flow. (This is the nub of the issue in terms of MEANjs stack component interaction.)
Fix
On a single instance MEANjs server, if you change the Mongo bind IP address back to 127.0.0.1 and the Mongo connection url to be 127.0.0.1:27017 then you can close off port 27017 in the EC2 Security Group and the app still works.
To share one MongoDB across more than one MEANjs app server (without wanting to stray into serverfault territory):
Change the Mongo bind IP address to 0.0.0.0,
Use the private IP address of the Mongo server in other app/instance connection strings
Add a EC2 Security Group CIDR rule of private IP address/24, or private IP address/16 to allow access across instances in the specified internal IP address range.
The above is developer 'hack', not a recommendation for good practice.
I have two servers on Linode that can connect to each other through the local Linode regional network. The problem is that any other Linode in the region can also connect using that IP. One server hosts the python application and the other hosts the MongoDB.
Would it be a good idea to connect to the database using an SSH Tunnel? What happens if the tunnel fails? Are SSH tunnels known to fail at all?
Or am I approaching the problem the wrong way? Another alternative I can think of is setting up iptables to only accept connections from a particular source IP.
I'm thinking in a more hypothetical situation, perhaps a DB password is all I need. I've been taking an computer security course and it makes everything seem more vulnerable than it really is.
I have a web server running out of my home. I have assigned it an address such as 192.168.1.123 on port 80.
I understand that this is running on my local network. If I go to another computer on my network and type in the server's ip address, I can see the server.
Is there a way to access this server from outside my LAN?
Yes, you need to set your router to forward connections to port 80 to your internal IP address (192.168.1.123). Look for Port Forwarding on your router admin screen which I would imagine you access by going to http://192.168.1.1
Keep in mind that your ISP may block port 80 completely in which case you can run your web server on a different port (for example por 8180) and have your router forward connections to port 8180 to your internal IP.
To access your server from outside, you just need to point your browser to your external IP address which you can find out by going to http://www.ipchicken.com
Assuming you have a connection to the internet:
https://github.com/progrium/localtunnel
is a quick way to access your local server from the internet. There might be similar implementations in other languages/platforms. This is just the one I know about.
Remember that security issues need to be carefully considered when opening your local network to the world.
If you use a PHP Webserver you can set it this way:
php -S <YourIPAdresse>:<SomePortNumber> <StartPHPpage>
Example: „php -S 192.168.1.123:9000 index.php"
I want to connect to a system which is behind a router. I know the public address of the router as well as the private ip (fixed always) of the system. How do i establish socket connection with the private ip?
This is why some people say that they are behind a "firewall", when they are behind a router. The Evil Viruses Of The Internet are not able to exploit any software on a computer behind a router (provided that the router admin didn't configure it in the funny way, for example by enabling DMZ).
You still have some options:
Talk to the router admin and make him forward a port for You
Take the router out and put Your "target" computer where Your router was, or enable DMZ (this only makes sense if there was only one computer behind the router). Warrning: install a firewall on the target computer first!
Turn the socket 180 degrees. Make the computer behind a router establish the connection to the server that has a public IP address
Use something like UPnP, if Your router supports it
Get a dedicated IP address for Your computer and configure router to switch all traffic to this IP address to Your computer (this is similar to DMZ, but would work if You have more than one computer behind the router). Warrning: install a firewall on the target computer first!
Use NAT traversal. There is a very good article on the subject here. Simplified version is that client establishes connection to some remote server. The server can see the opened port number on the client's router and this port is assigned to the client's machine, so it (or some another computer sharing this information) may establish connection to that port and reach the client's application. Warrning: this doesn't work with all routers. Some routers just won't let this happen.
The simplest thing is probably to forward the port from the system you want to connect to through the router.
This is more a question of configuration of the router as opposed to your actual program. If the router isn't configured to forward traffic to the private system, there's no way to force it to connect you - rather, the private system would have to open the connection on its own.
Strictly speaking, the answer to your question is "you can't". You can however enable DNAT (Destination Network Address Translation) on your router. You connect to a certain port on the router, and it forwards the connection to the internal ip. The internal ip (and port) are configured in the router settings and are not known by the connecting client.