bucket and @bucket are two different variables.
The main change in ERB templates between 2.7 and 3.x was deprecating the
use of non-class variables to pass information from the calling scope into
the template. Perhaps you got a little over-zealous prepending '@' to
variable names while fixing depr
Was your Puppet Master previously running an older version of Puppet as
well? If so, has Apache been restarted since you upgraded the RPM?
On Tue, Feb 18, 2014 at 11:32 AM, jmp242 wrote:
> I've got a working puppet on apache / passenger on EL6.4. However, ever
> since updating the puppet client
On the client, the list of classes applied in the last successful puppet
run should be written to $vardir/state/classes.txt
On Fri, Dec 13, 2013 at 2:29 PM, Paul Archer wrote:
> I'm trying to get my classes setup in hiera, but I'm having some issues,
> and having problems troubleshooting them.
On Wed, Oct 2, 2013 at 4:15 AM, Björn wrote:
> exec{'ensure password policy for pci':
> cwd => '/bin/',
> command => "/bin/sed -i 's/^password.*cracklib.so.*/password
> requisite pam_cracklib.so retry=3 minlen=8 difok=5
> dcredit=-1 lcredit=-1 ucredit=-1 ocredi
The redhat provider for the service type does indeed use chkconfig to
disable the service when
enable is false. If that's not happening for you, there's something wrong.
Some possibilities:
* facter is misidentifying the OS, causing puppet to pick a different
default provider. Does
'facter o
Hi Stefan,
I believe for the general case, the best practice is to encapsulate the
logic that can't
be expressed directly in the PuppetDSL in custom functions called from the
DSL.
Some of the features in the new experimental parser like iteration are
aimed at
reducing the need to write trivial, on
If you're assigning $role inside the role::nameserver class, then its scope
is limited to just role::nameserver (and any classes
that inherit from role::nameserver)[1]. So, hiera lookups from inside
role::nameserver will see that level of your hierarchy, but
it will be invisible almost everywhere
