Automatic firewall integration with firewalld on EL7 ?

[Sean Alderman]

Hi Al,
  Have you looked into firewalld yet?  I've just started to setup our foreman system to provision EL7 and quickly noticed these systems need to be reverted to use iptables-service instead of firewalld.  Just curious what your future plans are in this area.  Thanks.

[Alessandro Franceschi]

hi Sean

no specific plans on this.

i would like to implement firewalling, and more, in Tiny Puppet with an open and easily expandable way.

I have stopped active development on most of the current ex42 modules , most of their functionalities can be reproduced by tiny puppet now, in a much more compact and consistent way.

My future is there, on the tiny thing, but ex42 modules are not dead, some of them are going to keep maintained, others will be discontinued, if no volunteer offers for maintenance.

the list is here https://github.com/example42/tp-playground/blob/master/bin/example42modules.txt

I am truly interested in hearing your, any anybody else's opinion on this .

Al

On Wednesday, March 4, 2015, Sean Alderman <salde...@udayton.edu> wrote:

Hi Al,
  Have you looked into firewalld yet?  I've just started to setup our foreman system to provision EL7 and quickly noticed these systems need to be reverted to use iptables-service instead of firewalld.  Just curious what your future plans are in this area.  Thanks.

--
You received this message because you are subscribed to the Google Groups "Example42 Puppet Modules" group.
To unsubscribe from this group and stop receiving emails from it, send an email to example42-puppet-m...@googlegroups.com.
To post to this group, send email to example42-pu...@googlegroups.com.
Visit this group at http://groups.google.com/group/example42-puppet-modules.
For more options, visit https://groups.google.com/d/optout.

--

book { 'Extending Puppet':

  author   => 'Alessandro Franceschi',

  url      => 'http://amzn.to/1nenFti',

  comments => 'Potentially the best and most important book on Puppet yet.',

}

[Sean Alderman]

Al,

Thanks for the reply!  I don't have enough experience to figure out if our path should be to revert to iptables on EL7 (and remove firewalld which works with your ex42 modules) or try and update the automatic firewalling to handle firewalld as a firewall_tool.  Right now, I can't see us needing "zones" for host firewalls, even though we do have a number of hosts in the public ip space.  But perhaps I'm stuck in looking at it from the wrong perspective, so I'm going to spend a little time getting to know firewalld before I make a proposal for a go-forward standard on our systems.

Overall TP is interesting, but I think for us it's not easier, instead it becomes more work for me...and the fruits of that work become less visible in the ENC.

We're focused around using TheForeman as a Puppet ENC, basically for provisioning purposes and a nice pretty wrapper around puppet.  From what I understand of your TP implementation, its all resource definition based.  So what was a parameter driven class in the ex42 modules which we use the ENC to define and provide data for, now becomes a bunch of resource definitions that the ENC can not see or manipulate.  So unless I'm wrong about that, instead of using hierarchical host groups and config groups through Foreman to manage core system configurations, I'll have to write wrapper classes which define the resources that control those services and supply parameters for the resources.  Foreman will just see that a host has wrapper class called site applied to it.

We use Foreman's infrastructure objects like Locations, Organizations, Subnets, Domains, and Host Groups to organize and supply parameter data to hosts.  For example: Our disaster datacenter has it's own dns/ntp/dhcp, domains, subnets, etc. hosts that are in DR site get data from Foreman in the form of parameters supplied to the ex42 modules like resolver, ntp, monitor/nrpe, timezone, etc.  It seems like I could still do that using TP, but I'd have to write a class around TP resources that supplies that data to the hosts...and maybe that class could be parametrized and receive data from Foreman.

I don't know what Foreman's future is, I think there's been some questions about what will happen when Puppet 4 further reduces the ENC capabilities.  But overall, we like that we can use it, with your modules, and a little information from a new machine and go from turning the power on to fully operational system, completely hands off in about than 30 minutes.  Your modules and the glue they've got built in for the monitoring and firewall management are a great foundation for us and because of that our systems become more stable, more predictable, and less specific to the tastes of the individual who installed them.

We also use Foreman and Facter for organizational and inventory management, patching status, and other details that management folks like to see reported every so often.  I'm looking at expanding it for use with more of the Windows infrastructure (provisioning is lacking here, but inventory and other reporting is a plus) and possibly for the academic class/lab systems related to our multidisciplinary cyber security programs.  Having the ability to use a set of manifests to define the entire life cycle of a complete datacenter infrastructure which serves a classroom lab and could be reproduced from scratch every semester or even every day seems like a real winner.

On Wednesday, March 4, 2015 at 2:26:24 PM UTC-5, Alessandro Franceschi wrote:

hi Sean

no specific plans on this.

i would like to implement firewalling, and more, in Tiny Puppet with an open and easily expandable way.

I have stopped active development on most of the current ex42 modules , most of their functionalities can be reproduced by tiny puppet now, in a much more compact and consistent way.

My future is there, on the tiny thing, but ex42 modules are not dead, some of them are going to keep maintained, others will be discontinued, if no volunteer offers for maintenance.

the list is here https://github.com/example42/tp-playground/blob/master/bin/example42modules.txt

I am truly interested in hearing your, any anybody else's opinion on this .

Al

On Wednesday, March 4, 2015, Sean Alderman <salde...@udayton.edu> wrote:

Hi Al,
  Have you looked into firewalld yet?  I've just started to setup our foreman system to provision EL7 and quickly noticed these systems need to be reverted to use iptables-service instead of firewalld.  Just curious what your future plans are in this area.  Thanks.

--
You received this message because you are subscribed to the Google Groups "Example42 Puppet Modules" group.

To unsubscribe from this group and stop receiving emails from it, send an email to example42-puppet-modules+unsub...@googlegroups.com.
To post to this group, send email to example42-puppet-modules@googlegroups.com.

Visit this group at http://groups.google.com/group/example42-puppet-modules.
For more options, visit https://groups.google.com/d/optout.

[Alessandro Franceschi]

On Wednesday, March 4, 2015 at 9:55:08 PM UTC+1, Sean Alderman wrote:

Al,

Thanks for the reply!  I don't have enough experience to figure out if our path should be to revert to iptables on EL7 (and remove firewalld which works with your ex42 modules) or try and update the automatic firewalling to handle firewalld as a firewall_tool.  Right now, I can't see us needing "zones" for host firewalls, even though we do have a number of hosts in the public ip space.  But perhaps I'm stuck in looking at it from the wrong perspective, so I'm going to spend a little time getting to know firewalld before I make a proposal for a go-forward standard on our systems.

Overall TP is interesting, but I think for us it's not easier, instead it becomes more work for me...and the fruits of that work become less visible in the ENC.

For sure it's not a tool for every need. I see as a quick and handy replacement to the usage of whole modules, and the place where I use it is the "grouping" classes that work at higher abstraction.

According to the code layout and organisation they may role classes (when used without profiles), profiles, standard common baselines classes and so on (a simple example: https://github.com/example42/tp-playground/blob/master/vagrant/modules/local/site/manifests/general.pp )

ENC visibility then depends on the internal logic and where are grouped the used classes. 

 

We're focused around using TheForeman as a Puppet ENC, basically for provisioning purposes and a nice pretty wrapper around puppet.  From what I understand of your TP implementation, its all resource definition based.  So what was a parameter driven class in the ex42 modules which we use the ENC to define and provide data for, now becomes a bunch of resource definitions that the ENC can not see or manipulate.  So unless I'm wrong about that, instead of using hierarchical host groups and config groups through Foreman to manage core system configurations, I'll have to write wrapper classes which define the resources that control those services and supply parameters for the resources.  Foreman will just see that a host has wrapper class called site applied to it.

Actually I'm my vision you use tp inside highe abstraction classes that DO expose parameters that can be managed via the ENC.

So you are right, you need to have some kind of wrapper classes, which in many situations already exist anyway.

Again, it's mostly a matter of how code is organised, where you want to manage class groupings and parameters and other very site specific and personal variables.

 

We use Foreman's infrastructure objects like Locations, Organizations, Subnets, Domains, and Host Groups to organize and supply parameter data to hosts.  For example: Our disaster datacenter has it's own dns/ntp/dhcp, domains, subnets, etc. hosts that are in DR site get data from Foreman in the form of parameters supplied to the ex42 modules like resolver, ntp, monitor/nrpe, timezone, etc.  It seems like I could still do that using TP, but I'd have to write a class around TP resources that supplies that data to the hosts...and maybe that class could be parametrized and receive data from Foreman.

Exactly

 

I don't know what Foreman's future is, I think there's been some questions about what will happen when Puppet 4 further reduces the ENC capabilities.  But overall, we like that we can use it, with your modules, and a little information from a new machine and go from turning the power on to fully operational system, completely hands off in about than 30 minutes.  Your modules and the glue they've got built in for the monitoring and firewall management are a great foundation for us and because of that our systems become more stable, more predictable, and less specific to the tastes of the individual who installed them.

I don't expect people to switch overnight from ex42 modules to Tiny Puppet, especially if they are working well for them.

I see a lot of potential in how quickly you can use it to refactor and / or prototype an infrastructure, and also I see a lot potential in more or less reusable profile classes, where you have to cope di dependencies and have to manage the logic of your files by yourself.

For such cases using existing modules can be a pain, sysadmins know how their files should be populated, they need a quick way to manage them with Puppet, IMHO, rather a module that installs an app for them configuring it according to the module's logic.

 

We also use Foreman and Facter for organizational and inventory management, patching status, and other details that management folks like to see reported every so often.  I'm looking at expanding it for use with more of the Windows infrastructure (provisioning is lacking here, but inventory and other reporting is a plus) and possibly for the academic class/lab systems related to our multidisciplinary cyber security programs.  Having the ability to use a set of manifests to define the entire life cycle of a complete datacenter infrastructure which serves a classroom lab and could be reproduced from scratch every semester or even every day seems like a real winner.

Oh yes, these are great use cases for Puppet.

Thank you for the useful feedback, always appreciated

al