I'm testing a fedora 17 deployment and am using puppet 2.7.x and
puppetlabs-lvm-0.1.1. I have a problem in that a filesystem in a logical volume
is continually trying to get itself created even though it already exists and
is mounted. It looks as if this might be because there is no longer a
My solution to this is a script that enumerates the signed keys that the master
server knows about and compares this with which clients have been seen in the
past 24 hours. There's probably also a way to do it with some of puppet's
reporting facilities. My script is appended if it is of any
I am starting to experiment with the firewall module and as part of a test
attempted to move a rule between two chains (INPUT and a user-defined one). The
firewall module noticed that the rule had changed but then attempted to use
iptables -R to move the rule. Because it was moving from one
Does autosign work? I have a scratch workstation that may be rebuilt frequently
and will therefore acquire a new client certificate. I was hoping that adding
its certificate name to /etc/puppet/autosign.conf on the puppetmaster would
allow just this one client to have its new certificates
-
From: Luke Bigum [mailto:luke.bi...@lmax.com]
Sent: 24 April 2012 09:42
To: puppet-users@googlegroups.com
Cc: C R Ritson
Subject: Re: [Puppet Users] autosign
Autosigning certificates work, what you're probably running into is that
autosigning does not clear off an old Agent's certificate, so
Having read the scary warnings about autosign, I need to think it through some
more. However the helpful comments about allowing a client to revoke and delete
its OWN certificate will probably useful on their own. Luke said that his
addition to auth.conf was not working. It appears that the
This happed to concern the LVM module, but I don't think that is important in
this case.
What is the difference between using - and = to enforce a requirement that
one class cannot be applied if the other fails to be asserted?
In this case I have:-
mount { /addon/work2 :
It's bound to be sub-optimal, but I too found puppet-lvm hard to get started
with. Firstly, I took a long time to discover that I needed to set pluginsync
to get the module copied to all hosts:-
augeas { puppet-pluginsync:
context = /files/etc/puppet/puppet.conf/main,
changes =
I have a home-brewed script that seems to me to answer this part of the
request. Not ruby, though...
The issue was to detect the nodes that hadn't checked in but were
defined in the manifest.
I don't try to parse the manifest in any way. Instead, I compare a list of the
signed
Fedora 15 uses a mix of init.d and systemd to start services. Our systems also
use NetworkManager. When a client machine is rebooted, NetworkManager is still
initialising (and has sometimes not yet updated /etc/resolv.conf) by the time
puppetd is started. puppetd can then not look up its master
10 matches
Mail list logo
