-
Notifications
You must be signed in to change notification settings - Fork 101
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
allow defining parameters in hiera #248
Comments
Hey @lschierer, that should already be possible. As far as I am aware, everything, that is specified as a parameter in For a list of parameters see: puppet-os-hardening/manifests/init.pp Lines 80 to 81 in ee1851a
|
I have tried both
and
in data/Ubuntu/18.04.yaml |
I can confirm that I use os_hardening in combination with hiera:
|
Signed-off-by: Michael Geiger <info@mgeiger.de>
Also confirmed here |
Is your feature request related to a problem? Please describe.
os hardening is something that you will want to customize for different types of servers, and yet each will have more overlap than not. Since you cannot declare the class more than once, this is hard to do. Ideally I can declare os hardening as part of a base profile that all nodes get, but declare use variables in different other classes to override the base values.
The most obvious example is that as I move through an inheritance tree, I start with a base set of packages in the wanted_packages and unwanted_packages arrays, then I have a webserver node group that adds a couple of packages that did not fit cleanly anywhere else, but then I have a specific webserver that needs one extra package that isn't worth an entire class, and I want to extend wanted_packages yet again.
With hiera and a merge type of deep or deeper, this would happen fairly easily, because each level of inheritance would cause it to look at additional hiera data sources, which could define additional parameters that would then get merged to gether to form the final array of wanted and unwanted packages.
Describe the solution you'd like
Describe alternatives you've considered
The alternative is to only declare the os_hardening class at leaf nodes of the inheritance tree, with the risk that if I need to update a parameter that is common to a large set of nodes, I have to change the class definition in a large number of files.
The text was updated successfully, but these errors were encountered: