Re: [Puppet Users] NRPE configuration with Augeas
You probably want your onlyif to look like
match command[./${name}='${value}'] size == 0
I would probably do something like this (https://gist.github.com/1619400). The
reason for the two augeas resources is one will create the command if it
doesn't exist at all, the other will update the named command if it exists but
has the wrong command string.
On Sunday, 15 January 2012 at 8:27 AM, Jared Curtis wrote:
> I'm trying to build a NRPE management module that has the ability to
> add or modify existing commands. I think Augeas would be the best
> method to handle this but I'm running into a few issues. Here's what I
> have so far
>
> define nrpe::command($value) {
> include augeas
> augeas{ "${fqdn}_NRPE_${name}":
> context => "/files/${nrpe::params::conf}",
> changes => "set command[last()+1]/${name} ${value}",
> onlyif => "get command[*]/${name} != ${value}",
> require => Class['augeas'],
> }
> }
>
> The problem is this will add duplicate commands.
>
> What I want is something like this
> nrpe::command { 'check_users': value=> 'check users command';
> 'check_something': value => 'check something command'; }
>
> Which will produce this
> command[check_users]=check users command
> command[check_something]=check something command
>
> Any suggestions on how to correct this?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To post to this group, send email to puppet-users@googlegroups.com
> (mailto:puppet-users@googlegroups.com).
> To unsubscribe from this group, send email to
> puppet-users+unsubscr...@googlegroups.com
> (mailto:puppet-users+unsubscr...@googlegroups.com).
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
>
>
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Staging environment for infra with 20+ unique servers
Hello, one of my clients has a server infrastructure with 20+ servers that are all unique. Currently it runs without a puppet staging environment which makes me sleep badly at night :) The problem is: the client doesn't have the resources to run 20 staging servers as well, and the overhead of setting up 20 virtualboxes is quite sizable (worth it to me, but I'm not teh decision maker). I was wondering if anyone is doing anything smart for instance with vagrant and passing a different --fqdn param to puppet? I could for instance have 20 different snapshots in a single virtualbox image, one for each server they have? outside the box thinking welcome :) -- Walter Heck -- follow @walterheck on twitter to see what I'm up to! -- Check out my new startup: Server Monitoring as a Service @ http://tribily.com Follow @tribily on Twitter and/or 'Like' our Facebook page at http://www.facebook.com/tribily -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: Exec depends on ressources that are several different types
On Sun, Jan 15, 2012 at 4:17 PM, Patrick Viet wrote: > On Jan 11, 9:07 am, Aaron Grewell wrote: > > require accepts an array, so you should be able to do this: > > require => [File['foo'],Exec['bar']] > > It worked. Thanks so much. I should submit this as an addition in one > of the wiki examples on the puppet website. > > Ideally submit it as a bug against this page: http://docs.puppetlabs.com/guides/language_guide.html here: http://projects.puppetlabs.com/projects/puppet-docs/issues/new -- Nigel Kersten Product Manager, Puppet Labs -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: Exec depends on ressources that are several different types
On Jan 11, 9:07 am, Aaron Grewell wrote: > require accepts an array, so you should be able to do this: > require => [File['foo'],Exec['bar']] It worked. Thanks so much. I should submit this as an addition in one of the wiki examples on the puppet website. Patrick -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: Using foo::params, inheritance, and parameterized classes simultaneously?
On Sun, Jan 15, 2012 at 16:48, R.I.Pienaar wrote: > > > sounds like you want to use hiera > > http://www.devco.net/archives/2011/06/06/puppet_backend_for_hiera.php Ah, I didn't see before that it actually gets it's data from mutliple backends. That's pretty sweet! -- Walter Heck -- follow @walterheck on twitter to see what I'm up to! -- Check out my new startup: Server Monitoring as a Service @ http://tribily.com Follow @tribily on Twitter and/or 'Like' our Facebook page at http://www.facebook.com/tribily -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: Using foo::params, inheritance, and parameterized classes simultaneously?
On Sun, Jan 15, 2012 at 12:42 AM, Alessandro Franceschi wrote:
>
> So, to reply to your question, Nigel, something like a hiera backend or a
> Puppet function that does what is written before in any Puppet setup would
> be what I need.
>
> The ideal, maybe, would be a simple function that does the above and then
> if Hiera is in place, uses Hiera without requiring it: I really would like
> to reach a scenario where a person picks a single module and eventually the
> dependent modules (stdlib and so on), and can use it on his Puppetmaster
> without the need to introduce Hiera on it, if it's not already there.
> This, at least, until most of the people will have a PuppetMaster with
> integrated Hiera ... till that moment I would like to have modules usable
> in the widest range of Puppet setups possible.
>
>
So here's the rough idea we have in place.
Parameterized class lookups are automatically consulted in a Hiera backend.
The lookup order would be as follows:
1. directly supplied value in the declaration of the class:
class { "foo": param => "value" }
2. Hiera backend
3. Default value supplied in the definition of the class:
class foo ($param = "value") { ... }
This would happen automatically, without requiring the use of a hiera()
like function in the class definition.
It's clear that we need to have a way for module authors to specify values
in the definition of the class.
Is this satisfied well by having the values in the manifests themselves as
in (3) above?
Or should we be encouraging authors to put a Hiera-style backend inside
their modules and have that be consulted for default values?
I'm not particularly fond of the work we're making people do around
polluting the global namespace with class-specific data.
That's something I think we should probably remove entirely, but open to
suggestions.
The primary goal here is to finally enable seamless module reuse. We've
made people jump through far too many hoops in the past.
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: Using foo::params, inheritance, and parameterized classes simultaneously?
- Original Message - > I would be very happy to see a seamless/lazy/magic approach to using > variables. Something similar to what Al quoted seems nice: I'd like > to > be able to have the option to feed values to variables in different > places (of which one will take precedence over the other, and you > preferrably add a value only in one place) and then use that variable > in the module itself. That would make reuse of modules by others so > much nicer as they wouldn't be tied to using whatever your > environment > looks like that you developed the modules for. > > I guess it would look much like facter: it just provides values, but > hides where it got the values for those variables from. As Nigel > pointed out, data needs to be moved to outside manifests, and hiera > seems like a good tool for it. sounds like you want to use hiera http://www.devco.net/archives/2011/06/06/puppet_backend_for_hiera.php -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: Using foo::params, inheritance, and parameterized classes simultaneously?
I would be very happy to see a seamless/lazy/magic approach to using
variables. Something similar to what Al quoted seems nice: I'd like to
be able to have the option to feed values to variables in different
places (of which one will take precedence over the other, and you
preferrably add a value only in one place) and then use that variable
in the module itself. That would make reuse of modules by others so
much nicer as they wouldn't be tied to using whatever your environment
looks like that you developed the modules for.
I guess it would look much like facter: it just provides values, but
hides where it got the values for those variables from. As Nigel
pointed out, data needs to be moved to outside manifests, and hiera
seems like a good tool for it.
Walter
On Sun, Jan 15, 2012 at 10:42, Alessandro Franceschi wrote:
>
>
> On Sunday, January 15, 2012 12:41:50 AM UTC+1, Nigel Kersten wrote:
>>
>>
>>
>> What would it take for you to just have one source of truth for data
>> Alessandro?
>>
>> e.g. what would we have to change about Puppet for us to simply use Hiera
>> ?
>>
>> We're looking to integrate Hiera into Puppet for Telly, and in general
>> moving data outside of manifests has a lot of benefits, but I'm interested
>> to know whether you're of a similar mind with regard to the data you're
>> considering.
>
>
> Nigel,
> first of all do consider that I don't exclude Hiera's use in this approach.
> It's a choice, you can use Hiera to assign values to top scope variables or
> directly when you call parametrized classes, actually where and how you give
> values to variables is not forced by the module.
> The reason why I didn't place hiera lookups directly in the module is that
> these "nextgen" modules are supposed to work for Puppet > 2.6 and not
> everybody might want to use it or have integrated Hiera in their setup, but
> if the same modules can provide out of the box whatever is needed to work
> seamlessly, I've no problems with that. (see third point).
>
> Second point is that some variables, which are typically module's internal
> variables (names, paths and so on), should be IMHO provided by the module
> itself (the typical stuff for params class), to give some extra value (cross
> operating system support) to the module and preserve the user from providing
> this kind of common and preset data.
> I do present also these variables as class parameters because I need a quick
> way to pour all the modules variables (both "internal like these and the
> ones the module's users is likely to provide) to some place on the target
> system (for the puppi stuff, but actually once you have them in a yaml file
> you can use them in other ways). To do this I use Ken's neat get_class_vars
> () function.
> At the same time there are some rare cases when a user may need to supply
> these variables (for example paths and names for a custom package), so it's
> not bad to have them as parameters available in the class.
>
> Third point is that actually I would love to use Hiera directly in the
> module (or better something that fallbacks to Hiera... see below) if there
> would be a backend that permits something like what Dan has suggested me
> (sorry for public quoting Dan, but I think your suggestions deserves wider
> attention):
>
> ---QUOTE
>
> Instead of having to code all of the logic for how to perform the lookups
> for all of the data in the params namespace(this is a lot of code!), I
> would recommend using hiera (or another function) and coding the class
> inclusion, and data lookup precedence in a custom backend.
>
> I have a feeling that if you do a good enough job on the backend, it could
> just become the default puppet hiera backend.
>
> I imagine it working something like this:
>
> when looking up a variable $var
>
> class foo::bar (
> $var = als_hiera($var)
> ) {
>
> }
>
> It does the followins:
> - if the parameter was set in the class declaration, that always wins
> (this is just how Puppet works)
> - if an explicit class parameter was not set, the hiera function is
> called, and does the following:
> 1. Look for a variable called $::foo_var ($::${module_name}_var)
> 2. Look for a variable called $::var
>
> I like this capability of being able to set common behaviors across modules
> with a single topscope variable, I do think this needs to be configurable
> somehow:
>
> $var = als_hiera($var, {'topscope_lookup' => false})
>
> since this pattern may not be desirable for certain parameters
>
> 3. If the class params::foo (::params::${module_name} exists, include it and
> look for the variable:
>
> ::params::foo::var
>
> 4. if the class ::foo::params (:$module_name::params) exists, include it and
> lookup the value of the variable:
>
> ::foo::params::var
>
> --- QUOTE
>
> To this I might add that it would be nice to have the option to set a
> default value if none is provided in the above sources:
> var = als_hiera($var, {'default' => "mydefault"})
>
>
> So, to reply to you
Re: [Puppet Users] Re: Using foo::params, inheritance, and parameterized classes simultaneously?
On Sunday, January 15, 2012 12:41:50 AM UTC+1, Nigel Kersten wrote:
>
>
>
> What would it take for you to just have one source of truth for data
> Alessandro?
>
> e.g. what would we have to change about Puppet for us to simply use Hiera
> ?
>
> We're looking to integrate Hiera into Puppet for Telly, and in general
> moving data outside of manifests has a lot of benefits, but I'm interested
> to know whether you're of a similar mind with regard to the data you're
> considering.
>
Nigel,
first of all do consider that I don't exclude Hiera's use in this approach.
It's a choice, you can use Hiera to assign values to top scope variables
or directly when you call parametrized classes, actually where and how you
give values to variables is not forced by the module.
The reason why I didn't place hiera lookups directly in the module is that
these "nextgen" modules are supposed to work for Puppet > 2.6 and not
everybody might want to use it or have integrated Hiera in their setup, but
if the same modules can provide out of the box whatever is needed to work
seamlessly, I've no problems with that. (see third point).
Second point is that some variables, which are typically module's internal
variables (names, paths and so on), should be IMHO provided by the module
itself (the typical stuff for params class), to give some extra value
(cross operating system support) to the module and preserve the user from
providing this kind of common and preset data.
I do present also these variables as class parameters because I need a
quick way to pour all the modules variables (both "internal like these and
the ones the module's users is likely to provide) to some place on the
target system (for the puppi stuff, but actually once you have them in a
yaml file you can use them in other ways). To do this I use Ken's neat
get_class_vars () function.
At the same time there are some rare cases when a user may need to supply
these variables (for example paths and names for a custom package), so it's
not bad to have them as parameters available in the class.
Third point is that actually I would love to use Hiera directly in the
module (or better something that fallbacks to Hiera... see below) if there
would be a backend that permits something like what Dan has suggested me
(sorry for public quoting Dan, but I think your suggestions deserves wider
attention):
---QUOTE
Instead of having to code all of the logic for how to perform the lookups
for all of the data in the params namespace(this is a lot of code!), I
would recommend using hiera (or another function) and coding the class
inclusion, and data lookup precedence in a custom backend.
I have a feeling that if you do a good enough job on the backend, it could
just become the default puppet hiera backend.
I imagine it working something like this:
when looking up a variable $var
class foo::bar (
$var = als_hiera($var)
) {
}
It does the followins:
- if the parameter was set in the class declaration, that always wins
(this is just how Puppet works)
- if an explicit class parameter was not set, the hiera function is
called, and does the following:
1. Look for a variable called $::foo_var ($::${module_name}_var)
2. Look for a variable called $::var
I like this capability of being able to set common behaviors across modules
with a single topscope variable, I do think this needs to be configurable
somehow:
$var = als_hiera($var, {'topscope_lookup' => false})
since this pattern may not be desirable for certain parameters
3. If the class params::foo (::params::${module_name} exists, include it
and look for the variable:
::params::foo::var
4. if the class ::foo::params (:$module_name::params) exists, include it
and lookup the value of the variable:
::foo::params::var
--- QUOTE
To this I might add that it would be nice to have the option to set a
default value if none is provided in the above sources:
var = als_hiera($var, {'default' => "mydefault"})
So, to reply to your question, Nigel, something like a hiera backend or a
Puppet function that does what is written before in any Puppet setup would
be what I need.
The ideal, maybe, would be a simple function that does the above and then
if Hiera is in place, uses Hiera without requiring it: I really would like
to reach a scenario where a person picks a single module and eventually the
dependent modules (stdlib and so on), and can use it on his Puppetmaster
without the need to introduce Hiera on it, if it's not already there.
This, at least, until most of the people will have a PuppetMaster with
integrated Hiera ... till that moment I would like to have modules usable
in the widest range of Puppet setups possible.
A similar function would be more than enough for me to throw happily away
80% of the code that is
in https://github.com/example42/puppet-openssh/blob/master/manifests/params.pp
All the best
al
--
You received this message because you are s
