After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 592017 - Firewall configuration in Puppet
Firewall configuration in Puppet
Status: RESOLVED FIXED
Product: sysadmin
Classification: Infrastructure
Component: Puppet
unspecified
Other Linux
: Normal normal
: ---
Assigned To: GNOME Sysadmins
GNOME Sysadmins
Depends on:
Blocks:
 
 
Reported: 2009-08-16 23:07 UTC by Owen Taylor
Modified: 2013-05-28 12:33 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Owen Taylor 2009-08-16 23:07:48 UTC
Currently firewalls on each machine are configured by:

 - Going to the machine
 - Editing /etc/sysconfig/iptables
 - 'service iptables restart'

This means that there is no version control on the config, no peer-reviewable trail of changes, and if we had to rebuild one of the machines from scratch, we'd have to repeat the exercise of figuring out the rules.

The config should be managed by puppet like the rest of the config. There are various recipes and examples of doing this out there, I don't have a particular recommendation.

Whatever we choose should allow:

 - Global rules in our default classes (no firewall on eth1)
 - Service-specific rules (open port 80 for httpd)
 - Machine specific rules (open port 9070 for buildbot on fixed.gnome.org to particular build slaves)

It would be nice, though not essential, if there was a defined ordering for how those got different classes of rules got written into the final iptables configuration so we could make machine specific rules that block as well as allow. (E.g., only allow access to the mysql port on drawable's eth1 to a small set of machines.)
Comment 1 Christer Edwards 2010-06-18 21:10:06 UTC
I'd like to tackle this. For starters I think simply importing the existing rules into puppet on a per-host basis would be simple enough. This way we at least get the revision control and the peer-review. Nothing complicated, just a case statement per host and an application of the appropriate file/.

After that is done we can look at global rules, etc.
Comment 2 Christer Edwards 2010-06-19 16:40:12 UTC
submitted module to infrastructure list for review.
Comment 3 Andrea Veri 2013-05-28 12:33:45 UTC
An iptables class has been introduced into Puppet already. Look into puppet/modules/iptables.