arunoda / meteor-up-legacy

Production Quality Meteor Deployments
MIT License
2.26k stars 394 forks source link

Mupx bypasses ufw firewall rules. Can I config in mup.json? #996

Open jcheroske opened 8 years ago

jcheroske commented 8 years ago

When deploying with mupx, it seems to open up the firewall, regardless of how I have ufw setup. The issue is really that I don't want the meteor server reachable on both network interfaces of the machine. Can I configure the firewall or port binding options within the mup.json file? Since I'm already using ufw, I would prefer all of the firewall config to be done there.

Thanks,

Jay

jcheroske commented 8 years ago

Just tried adding BIND_IP="private_ip" to the mup.json file, but mupx could not verify the deployment.

MasterJames commented 8 years ago

I think the new version at kadirahq/meteor-up is already or going to have hooks, which might be a good way to make that happen?

jcheroske commented 8 years ago

Ok, I fixed this, but for mupx to be truly "production quality" something needs to change. This issue with docker publishing services in such a way that existing iptables rules are bypassed is a known problem that's been plaguing sysadmins for some time now. The easiest fix, from a mupx standpoint, would be for the /etc/default/docker file to be automatically edited and the following configuration added:

DOCKER_OPTS="--iptables=false"

This of course would mean that, if there is a firewall in place, a rule would need to be added to allow traffic to the meteor server's port. With ufw, it's simply something like:

ufw allow to <ip_address> port <meteor_port>

Because mupx binds the meteor port to all interfaces, and because the "Verifying deployment" step uses the loopback interface to do the verification, a mupx install will succeed without the firewall rule in place (which is a good thing I think). Therefore, all that's needed is to disable docker's iptables editing and to possibly inform the user that they might need to add a firewall rule to allow traffic.

MasterJames commented 8 years ago

You should make this optional feature request over at the new version where the development developers reside and monitor such comments kadirahq. I'm sure PRs are welcome as long as its none breaking and optional or at least optional to make a breaking change default at their discretion. Thanks for the insights either way. Glad to hear you resolved your issue.