Another option worth mentioning, and this may not be suitable for your
environment, is to allow host overrides of configuration files within your
module using file precedence like the below.
file { '/etc/security/limits.conf' :
ensure => file,
mode => 755,
owner => root,
group => root,
source => [
"puppet:///modules/modulename/limits.conf.$::hostname" ,
"puppet:///modules/modulename/limits.conf",
],
}
By default, all nodes get the standard limits.conf file that is served out
from your module, however, if you create a limits.conf.oracleserver1 file
that contains the required settings, the server oracleserver1 will get
the overridden limits.conf file when it checks in.
This has been extremely useful in my environment when importing the odd
'unique snowflake' type server quickly without having to make any
code/logic changes or introduce large numbers of ENC values to disable
certain functionality or alter the flow of your puppet code.
Cheers,
K
On Monday, August 20, 2012 9:19:45 PM UTC+1, Sean wrote:
>
> > It's not really the cleanest-looking thing, but the easiest option for
> > your particular case is to wrap the file resource in an if statement
> > like this:
> > if (! $::security_limits_disabled) {
> > file { '/etc/security/limits.conf':
> > ...
> > }
> > }
>
> Thanks, this is just what I was looking for.
>
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/M1aiScBQy4UJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
