Hi everyone,
I'm trying to automate the nagios configuration of new host through
Puppet. For this I define a nagios module with the generic
configuration of my Nagios host definition. The module look like
this:
class nagios {
$packagelist=[nagios]
package { $packagelist:
Hello,
Maybe have a look at our nagios module:
https://github.com/camptocamp/puppet-nagios
Your problem is that resources with same name are exported from multiple hosts,
and that make puppet crash with duplicated definition (as it's exported
resources, the error message is different ;) ).
You
Randall Hansen wrote:
Is the resources type primarily useful for purging? Is it also
commonly used for metaparameters? The documentation[1] says this, but
I haven't used it much myself, and I don't know what common use is.
I get the impression you are confused about what the part about
On Mon, Apr 25, 2011 at 10:40 PM, Trevor Vaughan tvaug...@onyxpoint.com wrote:
I haven't found the magic flag combination yet...
Trevor,
I don't believe Puppet Doc supports this feature for custom functions
yet. Could you please file a ticket about this if one doesn't already
exist?
Thanks,
After a very serious discussion with myself :)
I found a solution/workaround which my colleagues are satisfied with.
Because we want to use puppet in push only mode, every admin has to login to
the puppetmaster anyway.
So instead of trying to get a post commit hook working from our subversion
OK, thenks for your help. I solved the trouble using the $hostname fact in
front of services definitions.
But I have another question about this:
Is it possible to define the directory where the file are created in the
nagios server?
Now the files are stored in the /etc/nagios.
2011/4/26
Hello again,
Yes, of course you can change the directory.
Check out the mentioned module, we put all the nagios stuff in /etc/nagios.d
directory, keeping clean a /etc/nagios3 directory. For what I've seen, it seems
to do exactly what you're trying to do.
For the basic:
nagios accept different
Added as #7239.
Is there any other way to pull the docs from the custom functions
programatically?
Thanks,
Trevor
On Tue, Apr 26, 2011 at 5:37 AM, Jeff McCune j...@puppetlabs.com wrote:
On Mon, Apr 25, 2011 at 10:40 PM, Trevor Vaughan tvaug...@onyxpoint.com
wrote:
I haven't found the magic
Hi,
On 04/22/2011 06:48 PM, Tony G. wrote:
Hi all,
Found a situation on which all classes inside a directory are ignored,
this when the directory name is the same as a module name.
err: Could not retrieve catalog from remote server: Error 400 on SERVER:
Could not find class bar at
:) This is most definitely a hack. The issue is that once you start using
Puppet to push out secure-data that HostA might need, but HostB should never be
able to get — you run into this problem. If HostB is broken into and its 'node
type' is changed (whether by hostname, or editing a custom
Hello,
On 11-04-26 05:48 AM, Juan-Francisco Diez wrote:
OK, thenks for your help. I solved the trouble using the $hostname fact
in front of services definitions.
But I have another question about this:
Is it possible to define the directory where the file are created in the
nagios
Ok, spoke with Jeff a bit on IRC about this. Part of this problem is easy it
turns out. You can add '+ExportCertData' to the SSLOptions in Apache which will
pass the CERT in PEM format to Puppet for each client when they connect. You
can then do a custom node classifier that reads this data and
Why embed this in the cert, rather than custom facts? Your second
requirement is interesting, on one hand the client can set the class
info as part of the certificate, on the other hand you doesn't want
the client to change it afterwards.
I would suggest client submit the list of classes as a
On Tue, Apr 26, 2011 at 6:52 AM, Tony G. tony...@gmail.com wrote:
On Tue, Apr 26, 2011 at 8:22 AM, Felix Frank
felix.fr...@alumni.tu-berlin.de wrote:
Hi,
On 04/22/2011 06:48 PM, Tony G. wrote:
Hi all,
Found a situation on which all classes inside a directory are ignored,
this when
Nan,
You're going down the same line of thought I had as an alternative to
embedding it in the Cert itself. The reason to embed it in the cert is that you
avoid having all of the if its not here, go check there code. You don't need
to maintain a database with this data either. In our case we
On Tue, Apr 26, 2011 at 11:35 AM, Nan Liu n...@puppetlabs.com wrote:
On Tue, Apr 26, 2011 at 6:52 AM, Tony G. tony...@gmail.com wrote:
On Tue, Apr 26, 2011 at 8:22 AM, Felix Frank
felix.fr...@alumni.tu-berlin.de wrote:
Hi,
On 04/22/2011 06:48 PM, Tony G. wrote:
Hi all,
On Mon, 25 Apr 2011 19:10:35 -0700, Matt Wise wrote:
I'm working out some security issues here and wanted to throw
something out there... I'll be digging in tonight to see whether
something like this is possible, so I'd appreciate feedback quickly if
anyone happens to know if this is
On Tue, Apr 26, 2011 at 9:54 AM, Tony G. tony...@gmail.com wrote:
On Tue, Apr 26, 2011 at 11:35 AM, Nan Liu n...@puppetlabs.com wrote:
On Tue, Apr 26, 2011 at 6:52 AM, Tony G. tony...@gmail.com wrote:
On Tue, Apr 26, 2011 at 8:22 AM, Felix Frank
felix.fr...@alumni.tu-berlin.de wrote:
On Tue, Apr 26, 2011 at 4:10 AM, Matt Wise w...@wiredgeek.net wrote:
I'd like to have our nodes able to do this ONCE ... only when they generate
their CSR. After that, I'd like their 'base_class' to be embedded in the CSR
(And subsequently the CERT), so that a client cannot later change its
I was referring to the RPMs that ship with Enterprise Puppet -- I
haven't poked through the code, but if they get installed into the
system, then that would pretty much negate (or make more difficult)
creating an NFS-deployed Puppet for use.
On Apr 25, 9:43 pm, Mohamed Lrhazi lrh...@gmail.com
hey all, I am running puppet and running into a conflict with nis when
trying to add a local group to this particular server.
[root@old-neon]$ ${PUPPET_TREE}/scripts/run-puppet
err: /Stage[main]/Disco::Group/Group[mygroup]/ensure: change from
absent to present failed: Could not create group
On Tue, Apr 26, 2011 at 12:39 PM, Matt Wise w...@wiredgeek.net wrote:
FWIW, its because we leverage puppet over the internet to manage cloud
systems that we really care about this. Had we just been managing internal
networked systems, this may not be such a big deal. The benefits here though
[snip]
The hard part it turns out is getting some custom data into the SSL cert to
begin with. The CSR thats generated does not get generated with
'certdnsnames' embedded in it, thats done purely on the Signing side (aka,
your puppet ca). I had hoped I could set 'certdnsnames' on the client
[snip]
Below the relevant parts of my openssl.conf:
x509_extensions = usr_cert
[ usr_cert ]
basicConstraints= critical, CA:FALSE
keyUsage= digitalSignature, keyEncipherment
extendedKeyUsage= serverAuth, clientAuth, emailProtection
Hello,
On 4/25/11 2:13 PM, Forrie wrote:
How do you handle the *.rpm prerequisites of puppet itself. If one
installs (deploys) puppet on an NFS mount, presumably you would also
include enterprise-ruby (or standard) with those dependencies there.
Enterprise Ruby seems to have rolled their own
25 matches
Mail list logo
