You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Aug 31, 2019. It is now read-only.
First off, I should say that I am really excited about the fact that Puppetlabs is providing blessed images that can serve as a common development environment for module authors everywhere.
I also understand that the desire is not to deviate far from the veewee-provided templates, and to default to requesting changes upstream to the veewee project. In this instance, however, I'd like to make the case that it makes more sense for this change to occur only for these specific definitions.
The problem: on CentOS and Fedora, the firewall is enabled in the kickstart config, and subsequently the iptables service is still enabled after install, but the definitions for Ubuntu, Debian, and SLES do not enable the firewall (and in the case of SLES, it even explicitly disables it). Since these boxes are intended for puppet module development and testing, the goal of them should be to provide a default "base OS" experience. I think we can agree that managing host-based firewall rules can no longer be considered an industry standard practice, and that most shops disable the firewall even in production environments.
The larger point, though, is that we should not force module developers to require things like puppetlabs-firewall within their own modules, but only on RedHat-based systems.
The text was updated successfully, but these errors were encountered:
I think we can agree that managing host-based firewall rules can no longer be considered an industry standard practice, and that most shops disable the firewall even in production environments.
Not necessarily true - as the maintainer of puppetlabs/firewall I speak to a few people who do this. It was just monumentally hard to maintain it in the past, without something like Puppet or some other global tool to maintain it. I still consider it to be a good idea as a last line of defence - as long as I don't have to do it manually :-).
The larger point, though, is that we should not force module developers to require things like puppetlabs-firewall within their own modules, but only on RedHat-based systems.
Agreed. And yes, I can see the gist of this requirement is that 'most other distros don't do it, why is rhel special'. And I can understand your point. Its a tricky one, because sometimes people do want to test with an OS set of defaults. Take selinux for example, I believe the veewee template for centos 5 has it switched on.
Another point towards your argument is about support. I park in #vagrant all the time, and if I here another person say 'Check your firewall' I'll go nuts :-). So there is probably some value in doing it from a support perspective.
Hmm. On the surface this seems reasonable. I'll be re-rolling a new batch of images soon, I'll put this into the consideration mix @justinclayton .... thanks for your patch :-).
Thanks for your consideration! I know it seems a bit nitpicky, but we love the idea of having a curated set of default images that can be used to help automate the functional testing of modules, which is actually something I'm starting to work on myself called pinocchio (<-- shameless plug). :-D
First off, I should say that I am really excited about the fact that Puppetlabs is providing blessed images that can serve as a common development environment for module authors everywhere.
I also understand that the desire is not to deviate far from the veewee-provided templates, and to default to requesting changes upstream to the veewee project. In this instance, however, I'd like to make the case that it makes more sense for this change to occur only for these specific definitions.
The problem: on CentOS and Fedora, the firewall is enabled in the kickstart config, and subsequently the iptables service is still enabled after install, but the definitions for Ubuntu, Debian, and SLES do not enable the firewall (and in the case of SLES, it even explicitly disables it). Since these boxes are intended for puppet module development and testing, the goal of them should be to provide a default "base OS" experience. I think we can agree that managing host-based firewall rules can no longer be considered an industry standard practice, and that most shops disable the firewall even in production environments.
The larger point, though, is that we should not force module developers to require things like puppetlabs-firewall within their own modules, but only on RedHat-based systems.
The text was updated successfully, but these errors were encountered: