stevage
commented
11 years ago Interesting - I wasn't aware of this (or hadn't realised the implications). A few thoughts:
- this Chef cookbook should be targeted at the most general case, and particularly the "getting started" scenario
- many people will be running it either on NeCTAR or in a local Vagrant instance, where IPTables is probably not being used.
- if the iptables recipe is naively rebuilding firewall rules (ie, whatever you had set before, now you have exactly three ports open: 80, 443, 22), then that's just as likely to break other services.
- rewriting firewall rules is unexpected behaviour. Managing your firewall yourself is expected.
Bottom line: I think scrapping the IPTables rules is the right thing to do.
SEE https://github.com/mytardis/mytardis/issues/132 for discussion.
I discovered this issue with my own in-house fork of the mytardis chef cookbook. Basically, I'm using the recipes in the context of a Chef installation for a large number of our servers, and (naturally) we want the firewall settings to be configurable according to the specific requirements of each node.
When I tried integrating our local firewall stuff into a machine using my mytardis cookbooks, I discovered that the nginx.rb recipe is unilaterally updating the firewall rules to allow universal SSH, HTTP and HTTPS access. Now this might be OK on a cloud virtual running a non-production MyTardis instance. But it is NOT OK on a production MyTardis system. And it is certainly not OK that the nginx.rb recipe is messing with the SSH access settings.
The fix is simple ... just remove the last 3 lines of the recipe. But it might cause you to need to make other changes elsewhere to compensate (in the cloud use-case) so I'm hesitant to submit a pull request.
The real problem here is that the Chef various iptables recipes (all of them I've been able to find!) work on the basis that they are creating an "iptables" file from scratch, rather than updating existing firewall settings. So basically if the "nginx.rb" file is going to create rules to allow HTTP and HTTPS, then >>something<< has to be creating a rule for SSH ... or else Chef is going to "brick" SSH access. Somebody took a pragmatic decision that "nginx.rb" should add the SSH rule, but that has bad consequences. In fact, the better solution is for the core mytardis recipes to NOT mess with this.