Today we released Puppet agent 1.10.3.
This release only affects the Puppet component of Puppet agent. Using
ampersands (&) in custom facts was causing Puppet runs to fail in Puppet
4.10.2, although Facter would still return them correctly. This release
includes Puppet 4.10.3, which resolves that
Today we released Puppet agent 1.10.3.
This release only affects the Puppet component of Puppet agent. Using
ampersands (&) in custom facts was causing Puppet runs to fail in Puppet
4.10.2, although Facter would still return them correctly. This release
includes Puppet 4.10.3, which resolves that
I would like to setup a masterless puppet environment, where local
manifests get executed to prevent configuration drift. Where on the local
client should I be delivering the manifests to ensure Puppet picks them up
and executes them?
--
You received this message because you are subscribed
I'm running into an issue on one of our puppet4 servers where the agent
only works when run as 'puppet agent -t' but fails when run via the puppet
service 'systemctl restart puppet' results in errors as follows:
Jun 15 14:49:45 puppet21b puppet-agent[29620]: Starting Puppet client
version
Maybe I've missed something, but I don't see why your second example
doesn't work.
# Our order and notify relationships
File['patcher-client.service'] ~> Exec['systemctl daemon-reload']
File['patcher-client.service'] ~> Service['patcher-client']
# Our order only relationships
Exec['systemctl
Sounds like tags and chaining, did something similar for upstart.
file { '/usr/lib/systemd/system/patcher-client.service':
notify => Service['patcher-client'],
tag=> ['reload systemd'],
}
File <| tag == 'reload systemd' |> ~> Exec['systemctl daemon-reload']
Exec['systemctl
I'm having a problem getting some dependencies exactly right.
This is the code I originally wrote:
File['/usr/lib/systemd/system/patcher-client.service']~>Exec['systemctl
daemon-reload']~>Service['patcher-client']
It works great except... oops... if any *other* module does Exec['systemctl
Hi Steve,
I've actually been working with someone who was using the LDAP
terminus and had the same issue. In the end I took the patch
you posted in this thread and added it to a fork of the gem so it can be
just installed from Rubygems:
https://github.com/petems/jruby-ldap-patched
That worked
