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 use.
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 ch
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 inte
Message-
>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
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 autosi
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 certific
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
