[Puppet Users] Re: Live session on Puppet + AWS through Google Hangout on Air

[Walter Heck - OlinData.com]

Sorry, a new hangout was started for the Puppet+AWS session:
http://www.youtube.com/watch?v=XCvK2u_bI04&feature=youtu.be

cheers,

Walter

On Sat, Sep 15, 2012 at 10:13 AM, Walter Heck - OlinData.com
 wrote:
> Hi all,
>
> just wanted to let you know that there's a community event going on in
> Kuala Lumpur right now, currently there's a talk on OpenShift, and at
> noon (GMT+8) one of our guys will do a session on Puppet+AWS. It's
> being recorded by Google Hangout on Air, so even if you're late you
> can watch it for free.
>
> http://www.youtube.com/watch?v=T2pIB1NLrrU&feature=youtu.be
>
> Hope this helps anyone,
>
> cheers,
>
> --
> Walter Heck
> CEO and Founder @ OlinData (http://olindata.com)
> Puppet training and consulting
> --
> Follow @olindata on Twitter and/or 'Like' our Facebook page at
> http://www.facebook.com/olindata



-- 
Walter Heck
CEO and Founder @ OlinData (http://olindata.com)
Puppet training and consulting
--
Follow @olindata on Twitter and/or 'Like' our Facebook page at
http://www.facebook.com/olindata

-- 
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] Live session on Puppet + AWS through Google Hangout on Air

[Walter Heck - OlinData.com]

Hi all,

just wanted to let you know that there's a community event going on in
Kuala Lumpur right now, currently there's a talk on OpenShift, and at
noon (GMT+8) one of our guys will do a session on Puppet+AWS. It's
being recorded by Google Hangout on Air, so even if you're late you
can watch it for free.

http://www.youtube.com/watch?v=T2pIB1NLrrU&feature=youtu.be

Hope this helps anyone,

cheers,

-- 
Walter Heck
CEO and Founder @ OlinData (http://olindata.com)
Puppet training and consulting
--
Follow @olindata on Twitter and/or 'Like' our Facebook page at
http://www.facebook.com/olindata

-- 
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] Arbitrary Code in plugin "lib/"

[Mitchell Hashimoto]

Hi,

I'd like to DRY up some of my Puppet lib code and wanted to put helper
classes in other parts of the "lib/" folder in my plugin.

What is the best way to access these files? I can think of various ways
that may be considered hacks but wanted to know if there was a preferred
way.

Best,
Mitchell

-- 
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] Help me name a class in the new puppetdb module!

[Chris Price]

Anyone interested in helping me name a class in the forthcoming puppetdb
module?

There are 2 major parts to the module... the part that sets up puppetdb
itself, and the part that sets up the puppet master to talk to puppetdb.
 I'm brainstorming names for the latter... a class that you would apply on
your puppet master machine to tell it how to find and use puppetdb.

Any suggestions?

-- 
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: [Puppet-dev] Do you rely on 'param=>undef' being equal to '(nothing)'?

[Stefan Schulte]

On Fri, Sep 14, 2012 at 11:31:08AM -0700, Eric Sorenson wrote:
> Hi, there's an issue that came up recently in the 3.0RCs -- Big thanks to 
> Erik Dalén for reporting it in #16221 -- that involves a behaviour change to 
> part of the DSL. In a nutshell, this code:
> 
[..]> 
> class toplevel (
>$maybe = false,
>$optional = undef ) {
>if ($maybe) {
>   class { toplevel::secondlevel: optional => undef }
>}
> }
> 
> In order to make use of the default for the `optional` parameter in 
> toplevel::secondlevel, you'd now need to either test in `toplevel` whether 
> `$optional` was passed into it, or have toplevel::secondlevel use an 
> `$optional_real` value inside it, similar to what's commonly done to append 
> to defaults that are array values. 
> 
[...]
> 
> So, I'm trying to determine whether this is a widespread pattern or an 
> edge-case. Do you expect 'param=>undef' to be the same as not specifying 
> param at all, or for the receiver to "see" the undef?
> 
> Eric Sorenson - eric.soren...@puppetlabs.com
> PuppetConf'12 - 27-28 Sep in SF - http://bit.ly/pcsig12
> 

I use this a lot to be able to have an optional parameter in a parent
class that is passed to an included class and the included class
determines the default value. Like:

class basic($puppet_cron = undef) {
  class { 'puppet::client':
cron => $puppet_cron,
  }
}

-Stefan

-- 
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: [Puppet-dev] Do you rely on 'param=>undef' being equal to '(nothing)'?

[Aaron Grewell]

I'm using the current behavior in inherited classes to unset parameters set
by the parent class.  If that no longer works it will definitely impact my
code.
On Sep 14, 2012 11:31 AM, "Eric Sorenson" 
wrote:

> Hi, there's an issue that came up recently in the 3.0RCs -- Big thanks to
> Erik Dalén for reporting it in #16221 -- that involves a behaviour change
> to part of the DSL. In a nutshell, this code:
>
> define foobar ($param='Hello world') {
>   notice($param)
> }
> foobar { 'test': param => undef }
>
> in 2.7, causes 'Hello world' in the notice. In 3.x, it's nothing. As I
> said in the bug, this seems more correct to me -- I've overriden the
> default with an explicit 'undef', taking off the default. The same thing
> goes for invoking parameterised classes with undef arguments, which is
> perhaps more ambiguous (example from matthaus):
>
> class toplevel (
>$maybe = false,
>$optional = undef ) {
>if ($maybe) {
>   class { toplevel::secondlevel: optional => undef }
>}
> }
>
> In order to make use of the default for the `optional` parameter in
> toplevel::secondlevel, you'd now need to either test in `toplevel` whether
> `$optional` was passed into it, or have toplevel::secondlevel use an
> `$optional_real` value inside it, similar to what's commonly done to append
> to defaults that are array values.
>
> The closest thing to documentation around this suggests the new behaviour
> is what's intended <
> http://docs.puppetlabs.com/puppet/2.7/reference/lang_classes.html#overriding-resource-attributes
> >:
>
> You can remove an attribute’s previous value without setting a new one
> by overriding it with the special value undef:
>
>   class base::freebsd inherits base::unix {
> File['/etc/passwd'] {
>   group => undef,
> }
>   }
>
> So, I'm trying to determine whether this is a widespread pattern or an
> edge-case. Do you expect 'param=>undef' to be the same as not specifying
> param at all, or for the receiver to "see" the undef?
>
> Eric Sorenson - eric.soren...@puppetlabs.com
> PuppetConf'12 - 27-28 Sep in SF - http://bit.ly/pcsig12
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Developers" group.
> To post to this group, send email to puppet-...@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-dev+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-dev?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.

Re: [Puppet Users] Module critique

[Alessandro Franceschi]

On Thursday, September 6, 2012 11:48:40 PM UTC+2, Andreas Ntaflos wrote:
>
> On 2012-09-04 17:26, Bai Shen wrote: 
> > class solr { 
>
> I recommend you follow best practices and not manage every aspect of 
> your Solr resource in a single class, but split it up into subclasses, 
> probably at least: solr::install (install.pp), solr::config (config.pp), 
> solr::service (service.pp). The solr class (init.pp) then includes all 
> subclasses and explicitly declares their dependencies among each other, 
> like so: 
>
> class solr { 
>   include 'solr::install' 
>   include 'solr::config' 
>   include 'solr::service' 
>
>   Class['solr::install'] 
>   -> Class['solr::config'] 
>   ~> Class['solr::service'] 
> } 
>
> This makes it easier to manage and change later on. 
>

If I may add my very personal 2 cents to this approach, I have to say that 
this is IMHO the worst "best practice" ever suggested for Puppet modules, 
even if it's written on Puppet Pro and has been originally suggested by a 
giant like R.I.P., if I remember well.

It my opinion if has 2 major defects:
- It multiplies the number of objects needed to manage the same things (at 
scale you feel it) without really giving a great advantage if not having a 
bit more comfortable dependency management.
- Most of all, it makes a real PITA any attempt to override some of the 
resources parameters using class inheritance (yes, the more you avoid class 
inheritance and the better, but if your module doesn't provide a way to 
(re)define the behaviour of most of the resources defined in these classes, 
trying to change them without changing the module becomes almost 
impossible).

No flames intended :-)

Alessandro Franceschi 

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/puppet-users/-/yp_L1yPt5_IJ.
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: [Puppet-dev] Re: Changes to allowed function calls in Puppet 3.0

[Nick Lewis]

On Friday, September 14, 2012 at 1:55 PM, Alessandro Franceschi wrote:
> Hi Andrew,
> thank you for the notice (and thanks to Ken B. for informing me about it).
> In my modules I have tons of calls to custom functions in the *arguments* of 
> my classes.
> Things like:
> class apache (
>   $my_class= params_lookup( 'my_class' ),
>   $source  = params_lookup( 'source' ),
>   $source_dir  = params_lookup( 'source_dir' ),
> [...]
> that, I guess, should be something like 
> class apache (
>   $my_class= params_lookup( [ 'my_class' ] ),
>   $source  = params_lookup( [ 'source' ] ),
>   $source_dir  = params_lookup( [ 'source_dir' ]),
> [...]
> Now, my question is:
> you wrote that this "conversion" from string to array is needed when calling 
> custom functions in templates or other functions, but not in Puppet DSL.
> Is the conversion required  also for the class/define arguments list (which 
> might be considered somehow a border case)?
> 
This code doesn't need to change. The reason for this issue in the first place 
is that Puppet's calling convention for functions is to wrap all the arguments 
in an array and pass that as a single argument to the corresponding Ruby 
method. So when calling the Ruby method directly, you need to also wrap your 
arguments in an array. This is still Puppet code, so it's fine.
 
> 
> Any info is welcomed.
> 
> Best regards
> Alessandro Franceschi
> Example42.com (http://Example42.com)
> 
> 
> On Friday, September 14, 2012 8:22:59 PM UTC+2, Andy Parker wrote:
> > This is a heads up to anyone who has written code that calls custom 
> > functions. We are making a change in Puppet 3.0 that will make the 
> > calls reject incorrect calls (see bug #15756). Calling functions from 
> > ruby code (either other functions or erb templates) was always 
> > supposed to be done by placing all of the arguments in an array and 
> > passing the array to the method call. This was using done by 
> > surrounding the arguments with square brackets. 
> > 
> > function_template( [ 'my_template.erb' ] ) 
> > 
> > Some, but not all, functions had been written in a way that would by 
> > chance work when this was not done. The template function is one such 
> > example. It would work if you were running on a 1.8 ruby if it was 
> > called as: 
> > 
> > function_template( 'my_template.erb' ) 
> > 
> > However, if you tried running on a 1.9 ruby that function call would 
> > fail with an error about not having a method named 'collect' on a 
> > String, which is caused by a change in the String class in ruby. To 
> > prevent these kinds of errors in the future, Puppet 3.0 is going to 
> > check that the arguments are passed in an array and fail if they are 
> > not. 
> > 
> > I did a quick check across the code available in the Forge and it 
> > doesn't look like it was too common that this was done wrong, but you 
> > might want to check through your code for calls of functions where the 
> > arguments are not being passed in an array, and change them to use an 
> > array. 
> > 
> > NOTE: If you have only ever called custom functions from inside the 
> > Puppet Language, then you don't need to worry about anything, this 
> > does not apply to that. 
> > 
> > Thanks, 
> > Andrew Parker 
> > Puppet Team Lead 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Puppet Developers" group.
> To view this discussion on the web visit 
> https://groups.google.com/d/msg/puppet-dev/-/Fbji-OwL4I4J.
> To post to this group, send email to puppet-...@googlegroups.com 
> (mailto:puppet-...@googlegroups.com).
> To unsubscribe from this group, send email to 
> puppet-dev+unsubscr...@googlegroups.com 
> (mailto:puppet-dev+unsubscr...@googlegroups.com).
> For more options, visit this group at 
> http://groups.google.com/group/puppet-dev?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.

Re: [Puppet Users] pe version of puppet, vmware provisioning with from template with guest customization

[Jeff McCune]

On Thu, Sep 13, 2012 at 2:36 PM, jimmy  wrote:

> Hi All,
>
> I'm using puppet enterprise and am getting a feel for the vmware
> provisioning.  I've been able to provision vms by using:
>
>  puppet node_vmware create NameOfMyTemplate
>
> That sort of works, but I basically have an identical copy of the original
> vm i created a template from. Same mac address, hostname, etc.   in
> vSphere, you can create a vm from a template and give it a guest
> customization file which will set the hostname, autogenerate the mac
> address as well as other things. I'd like to do this from puppet but there
> doesn't appear to be an option to apply a customization file.
>

This question is probably better suited for the PE Users list [1].

I'm surprised the new vm is getting the same MAC address.  Cloning a
template should result in the new VM getting a new MAC address, and we
recommend using DHCP to get an address for the instance.  What version of
vSphere are you running?  This information might have something to do with
the difference in behavior.

[1]
https://groups.google.com/a/puppetlabs.com/forum/?fromgroups#!forum/pe-users

-Jeff

-- 
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: Changes to allowed function calls in Puppet 3.0

[Alessandro Franceschi]

Hi Andrew,
thank you for the notice (and thanks to Ken B. for informing me about it).
In my modules I have tons of calls to custom functions in the *arguments* 
of my classes.
Things like:

class apache (
  $my_class= params_lookup( 'my_class' ),
  $source  = params_lookup( 'source' ),
  $source_dir  = params_lookup( 'source_dir' ),
[...]

that, I guess, should be something like 

class apache (
  $my_class= params_lookup( [ 'my_class' ] ),
  $source  = params_lookup( [ 'source' ] ),
  $source_dir  = params_lookup( [ 'source_dir' ]),
[...]
Now, my question is:
you wrote that this "conversion" from string to array is needed when 
calling custom functions in templates or other functions, but not in Puppet 
DSL.
Is the conversion required  also for the class/define arguments list (which 
might be considered somehow a border case)?

Any info is welcomed.

Best regards
Alessandro Franceschi
Example42.com


On Friday, September 14, 2012 8:22:59 PM UTC+2, Andy Parker wrote:
>
> This is a heads up to anyone who has written code that calls custom 
> functions. We are making a change in Puppet 3.0 that will make the 
> calls reject incorrect calls (see bug #15756). Calling functions from 
> ruby code (either other functions or erb templates) was always 
> supposed to be done by placing all of the arguments in an array and 
> passing the array to the method call. This was using done by 
> surrounding the arguments with square brackets. 
>
> function_template( [ 'my_template.erb' ] ) 
>
> Some, but not all, functions had been written in a way that would by 
> chance work when this was not done. The template function is one such 
> example. It would work if you were running on a 1.8 ruby if it was 
> called as: 
>
> function_template( 'my_template.erb' ) 
>
> However, if you tried running on a 1.9 ruby that function call would 
> fail with an error about not having a method named 'collect' on a 
> String, which is caused by a change in the String class in ruby. To 
> prevent these kinds of errors in the future, Puppet 3.0 is going to 
> check that the arguments are passed in an array and fail if they are 
> not. 
>
> I did a quick check across the code available in the Forge and it 
> doesn't look like it was too common that this was done wrong, but you 
> might want to check through your code for calls of functions where the 
> arguments are not being passed in an array, and change them to use an 
> array. 
>
> NOTE: If you have only ever called custom functions from inside the 
> Puppet Language, then you don't need to worry about anything, this 
> does not apply to that. 
>
> Thanks, 
> Andrew Parker 
> Puppet Team Lead 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/puppet-users/-/Fbji-OwL4I4J.
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] Why agent report is so slow?

[Daniel Pittman]

On Fri, Sep 14, 2012 at 3:16 AM, flex  wrote:
> Thanks, Daniel. We do have some recursive file copies and hundreds of other
> resources. So we'd better decrease the resources numbers?

Well, that would be the only short term path to making report output
faster - but, in general, if you are managing it you probably need to
be managing it.  :)

-- 
Daniel Pittman
⎋ Puppet Labs Developer – http://puppetlabs.com
♲ Made with 100 percent post-consumer electrons

-- 
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] Do you rely on 'param=>undef' being equal to '(nothing)'?

[Eric Sorenson]

Hi, there's an issue that came up recently in the 3.0RCs -- Big thanks to Erik 
Dalén for reporting it in #16221 -- that involves a behaviour change to part of 
the DSL. In a nutshell, this code:

define foobar ($param='Hello world') {
  notice($param)
}
foobar { 'test': param => undef }

in 2.7, causes 'Hello world' in the notice. In 3.x, it's nothing. As I said in 
the bug, this seems more correct to me -- I've overriden the default with an 
explicit 'undef', taking off the default. The same thing goes for invoking 
parameterised classes with undef arguments, which is perhaps more ambiguous 
(example from matthaus):

class toplevel (
   $maybe = false,
   $optional = undef ) {
   if ($maybe) {
  class { toplevel::secondlevel: optional => undef }
   }
}

In order to make use of the default for the `optional` parameter in 
toplevel::secondlevel, you'd now need to either test in `toplevel` whether 
`$optional` was passed into it, or have toplevel::secondlevel use an 
`$optional_real` value inside it, similar to what's commonly done to append to 
defaults that are array values. 

The closest thing to documentation around this suggests the new behaviour is 
what's intended 
:
 

You can remove an attribute’s previous value without setting a new one by 
overriding it with the special value undef:

  class base::freebsd inherits base::unix {  
File['/etc/passwd'] {
  group => undef,
}
  }

So, I'm trying to determine whether this is a widespread pattern or an 
edge-case. Do you expect 'param=>undef' to be the same as not specifying param 
at all, or for the receiver to "see" the undef?

Eric Sorenson - eric.soren...@puppetlabs.com
PuppetConf'12 - 27-28 Sep in SF - http://bit.ly/pcsig12

-- 
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] Changes to allowed function calls in Puppet 3.0

[Andy Parker]

This is a heads up to anyone who has written code that calls custom
functions. We are making a change in Puppet 3.0 that will make the
calls reject incorrect calls (see bug #15756). Calling functions from
ruby code (either other functions or erb templates) was always
supposed to be done by placing all of the arguments in an array and
passing the array to the method call. This was using done by
surrounding the arguments with square brackets.

function_template( [ 'my_template.erb' ] )

Some, but not all, functions had been written in a way that would by
chance work when this was not done. The template function is one such
example. It would work if you were running on a 1.8 ruby if it was
called as:

function_template( 'my_template.erb' )

However, if you tried running on a 1.9 ruby that function call would
fail with an error about not having a method named 'collect' on a
String, which is caused by a change in the String class in ruby. To
prevent these kinds of errors in the future, Puppet 3.0 is going to
check that the arguments are passed in an array and fail if they are
not.

I did a quick check across the code available in the Forge and it
doesn't look like it was too common that this was done wrong, but you
might want to check through your code for calls of functions where the
arguments are not being passed in an array, and change them to use an
array.

NOTE: If you have only ever called custom functions from inside the
Puppet Language, then you don't need to worry about anything, this
does not apply to that.

Thanks,
Andrew Parker
Puppet Team Lead

-- 
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] Node collecting its own exported resource

[Jon McKenzie]

I'm writing a module in which nodes export a concat::fragment, collect all 
other nodes' analogous resource, and populate a config file (in this case, 
the krb5.conf for MIT Kerberos).

It seems that nodes are not able to collect their own resource, but they 
can collect every other resource, with a given tag. I've validated that all 
of the appropriate resources exist 
in the storeconfigs database.

I've been doing some searching, and have read some things that suggest 
there might be a regression in this area, but I haven't found anything 
definitive.

I know the documentation states that nodes can in fact collect their own 
exported resources, but I haven't been able to get this working.

I've also tried it with just a plain "file" resource (rather than a 
concat::fragment), e.g. inside a given class:

   @@file { "/tmp/export-${::fqdn}": 
  tag => "testexport",
   }
   File <<| tag == "testexport" |>>

This also produces the same behavior.

Thanks!

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/puppet-users/-/huzwZYKfZs4J.
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] Complex custom type?

[Jakov Sosic]

Hi.

I've successfully written and tested three puppet custom types for
managing cobbler so far (distro, repo and profile). So far it has been
interesting week, learning ruby from zero, learning custom types etc.
But I'm really satisfied with the results so far.

Now I'm trying to figure out how to write rather complex provider, so
maybe someone can help with some thoughts or input.

What am I trying to do is write a provider for a command that looks
something like this:

cobbler add system --name=blah \
  --profile=someprofile  \
  --interface=eth0 \
--mac=SOMEMAC \
--interface-type=bond_slave \
--interface-master=bond0 \
  --interface=eth1 \
--mac=SOMEMAC \
--interface-type=bond_slave \
--interface-master=bond0 \
  --interface-name=bond0 \
--interface-type=bond
--bonding-opts="miimon=300 mode=1 primary=eth0"
--ip-address=MYIP \

As you can see, problem is that I can have multiple interfaces, and
every one of them can have some unique properties (mac, type, etc).

So, for example I don't have a clue how should a resource for something
like this look like? My first thought was:

cobblersystem { 'blah':
  profile= 'someprofile',
  interfaces = ['eth0','eth1','bond0'],
  macs   = ['SOMEMAC1','SOMEMAC2']
  iface-opts = ['-interface-type=bond_slave
--interface-master=bond0','..','']
  ...
  ...
}

But this is just a big mess - both for reading and writing resources
itself, as is for reading and writing provider :(

Another idea was to separate resources for interfaces from the main
system resource, so that I could write something like:


cobblersysiface {'eth0':
  ...
}
cobblersysiface {'eth1':
  ...
}
cobblersystem {'eth0':
  interfaces = [Cobblersysiface['eth0'], Cobblersysiface['eth1'], ],
}

But I'm still not fully satisfied with this, because provider for
interface should contact the provider for cobblersystem, beacuse it's
that provider that runs the full "cobbler system add/edit" command.

Any ideas on this one?

Or is it too complex and should I just give up and simply use Exec type :-/

-- 
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: assistance needed - err: Could not retrieve catalog from remote server: execution expired

[Jason Antman]

Commented out storeconfigs/thin_storeconfigs as we were only using them to 
get facts in a DB and for Dashboard. Also commented out the Inventory 
Service stuff. Looks like that did it. Now I just need to figure out the 
real fix...

On Friday, September 14, 2012 10:40:16 AM UTC-4, Jason Antman wrote:
>
> Hi,
>
> I have a puppet infrastructure running 2.6.14 under Passenger with about 
> 30 nodes. I'm just spinning up a new Cent 6.3, puppet 2.7.19 master. Right 
> now I have the master built and configured using the same configuration as 
> my 2.6.14 setup, with a few tweaks for the new version. Puppet on the 
> master built itself fine. I have puppetd stopped on the master. I tried 
> pointing one node at it, but I'm getting:
> err: Could not retrieve catalog from remote server: execution expired
>
> I disabled passenger and ran through the builtin webrick, and confirmed 
> that only one node is talking to the master. No change. No helpful 
> information in the master log. I'm running the master with:
> /usr/sbin/puppetmasterd --no-daemonize --debug --logdest console --verbose 
> --trace
>
> and some relevant puppet.conf portions on the master:
> storeconfigs = true
> thin_storeconfigs = true
> reports = log,puppet_dashboard
> reportfrom = root
> syslogfacility = user
> # Remote Inventory Service 
> facts_terminus = rest
> inventory_server = tv-puppetma1.techtarget.com # fqdn of master
> inventory_port = 8140
>
> The exact behavior I'm seeing is that when I run puppetd on the node, all 
> works well up to seeing "debug: catalog supports formats: marshal pson raw 
> yaml; using pson" on the node and "debug: facts supports formats: 
> b64_zlib_yaml pson raw yaml; using pson" on the master. At that point, it 
> hangs for 2 minutes (120 seconds exactly), with no output on either the 
> node or master. puppetmasterd is using ~25% CPU and ~14 memory. After that 
> time, I see the below stack trace on the master, followed by a whole slew 
> of the same for the facts, and "err: Could not retrieve catalog from remote 
> server: execution expired" on the node. 
>
> Any ideas? I'm going to try adding resources to the master VM, but I find 
> it hard to believe that this is just caused by compiling a single catalog 
> on the master... Any advice or insight would be greatly appreciated.
>
> Thanks,
> Jason Antman
>
> Trace from master:
> /usr/lib/ruby/1.8/timeout.rb:64:in `rbuf_fill'
> /usr/lib/ruby/1.8/net/protocol.rb:134:in `rbuf_fill'
> /usr/lib/ruby/1.8/net/protocol.rb:116:in `readuntil'
> /usr/lib/ruby/1.8/net/protocol.rb:126:in `readline'
> /usr/lib/ruby/1.8/net/http.rb:2028:in `read_status_line'
> /usr/lib/ruby/1.8/net/http.rb:2017:in `read_new'
> /usr/lib/ruby/1.8/net/http.rb:1051:in `request'
> /usr/lib/ruby/1.8/net/http.rb:1037:in `request'
> /usr/lib/ruby/1.8/net/http.rb:543:in `start'
> /usr/lib/ruby/1.8/net/http.rb:1035:in `request'
> /usr/lib/ruby/1.8/net/http.rb:857:in `put'
> /usr/lib/ruby/site_ruby/1.8/puppet/indirector/rest.rb:98:in `send'
> /usr/lib/ruby/site_ruby/1.8/puppet/indirector/rest.rb:98:in `http_request'
> /usr/lib/ruby/site_ruby/1.8/puppet/indirector/rest.rb:76:in `http_put'
> /usr/lib/ruby/site_ruby/1.8/puppet/indirector/rest.rb:158:in `save'
> /usr/lib/ruby/site_ruby/1.8/puppet/indirector/indirection.rb:271:in `save'
> /usr/lib/ruby/site_ruby/1.8/puppet/node/facts.rb:20:in `save'
> /usr/lib/ruby/site_ruby/1.8/puppet/indirector/catalog/compiler.rb:26:in 
> `extract_facts_from_request'
> /usr/lib/ruby/site_ruby/1.8/puppet/indirector/catalog/compiler.rb:31:in 
> `find'
> /usr/lib/ruby/site_ruby/1.8/puppet/indirector/indirection.rb:195:in `find'
> /usr/lib/ruby/site_ruby/1.8/puppet/network/http/handler.rb:109:in `do_find'
> /usr/lib/ruby/site_ruby/1.8/puppet/network/http/handler.rb:68:in `send'
> /usr/lib/ruby/site_ruby/1.8/puppet/network/http/handler.rb:68:in `process'
> /usr/lib/ruby/site_ruby/1.8/puppet/network/http/webrick/rest.rb:24:in 
> `service'
> /usr/lib/ruby/1.8/webrick/httpserver.rb:104:in `service'
> /usr/lib/ruby/1.8/webrick/httpserver.rb:65:in `run'
> /usr/lib/ruby/site_ruby/1.8/puppet/network/http/webrick.rb:45:in `listen'
> /usr/lib/ruby/1.8/webrick/server.rb:173:in `call'
> /usr/lib/ruby/1.8/webrick/server.rb:173:in `start_thread'
> /usr/lib/ruby/1.8/webrick/server.rb:162:in `start'
> /usr/lib/ruby/1.8/webrick/server.rb:162:in `start_thread'
> /usr/lib/ruby/1.8/webrick/server.rb:95:in `start'
> /usr/lib/ruby/1.8/webrick/server.rb:92:in `each'
> /usr/lib/ruby/1.8/webrick/server.rb:92:in `start'
> /usr/lib/ruby/1.8/webrick/server.rb:23:in `start'
> /usr/lib/ruby/1.8/webrick/server.rb:82:in `start'
> /usr/lib/ruby/site_ruby/1.8/puppet/network/http/webrick.rb:42:in `listen'
> /usr/lib/ruby/site_ruby/1.8/puppet/network/http/webrick.rb:41:in 
> `initialize'
> /usr/lib/ruby/site_ruby/1.8/puppet/network/http/webrick.rb:41:in `new'
> /usr/lib/ruby/site_ruby/1.8/puppet/network/http/webrick.rb:41:in `listen'
> /usr/lib/ruby/site_ruby/1.8/puppet/network/http/webrick.rb:38:in 
> `synch

[Puppet Users] Re: Puppet conventions

[Cosmin-Viorel Ilie]

^([^\.]*)(\..*)$

this regex is split into two groups based on "." delimiter. The first group 
contains the hostname while the second group is the domain name. You can 
edit this to match your needs.

On Friday, September 14, 2012 5:05:34 PM UTC+3, ureal frank wrote:
>
> Hi there,
>
> I was reading Puppet Naming Conventions and in "Node names should match 
> the hostnames of the nodes" I have a doubt.
>
> What is 'secure/better/faster' or correct way to do this
>
> a) node /^foo0\d+$/ {}
>
> b) node /^foo0\d+$\.bar$/ {}   # using FQDN
>
> I have too many servers with hostnames almost in collision :/ foo01.foo 
> and foo01.bar. but with very different FQDN's.
>
> Thanks in advance for your help :)
>
> Regards
> Frank
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/puppet-users/-/aOKH1v7DKwIJ.
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] assistance needed - err: Could not retrieve catalog from remote server: execution expired

[Jason Antman]

Hi,

I have a puppet infrastructure running 2.6.14 under Passenger with about 30 
nodes. I'm just spinning up a new Cent 6.3, puppet 2.7.19 master. Right now 
I have the master built and configured using the same configuration as my 
2.6.14 setup, with a few tweaks for the new version. Puppet on the master 
built itself fine. I have puppetd stopped on the master. I tried pointing 
one node at it, but I'm getting:
err: Could not retrieve catalog from remote server: execution expired

I disabled passenger and ran through the builtin webrick, and confirmed 
that only one node is talking to the master. No change. No helpful 
information in the master log. I'm running the master with:
/usr/sbin/puppetmasterd --no-daemonize --debug --logdest console --verbose 
--trace

and some relevant puppet.conf portions on the master:
storeconfigs = true
thin_storeconfigs = true
reports = log,puppet_dashboard
reportfrom = root
syslogfacility = user
# Remote Inventory Service 
facts_terminus = rest
inventory_server = tv-puppetma1.techtarget.com # fqdn of master
inventory_port = 8140

The exact behavior I'm seeing is that when I run puppetd on the node, all 
works well up to seeing "debug: catalog supports formats: marshal pson raw 
yaml; using pson" on the node and "debug: facts supports formats: 
b64_zlib_yaml pson raw yaml; using pson" on the master. At that point, it 
hangs for 2 minutes (120 seconds exactly), with no output on either the 
node or master. puppetmasterd is using ~25% CPU and ~14 memory. After that 
time, I see the below stack trace on the master, followed by a whole slew 
of the same for the facts, and "err: Could not retrieve catalog from remote 
server: execution expired" on the node. 

Any ideas? I'm going to try adding resources to the master VM, but I find 
it hard to believe that this is just caused by compiling a single catalog 
on the master... Any advice or insight would be greatly appreciated.

Thanks,
Jason Antman

Trace from master:
/usr/lib/ruby/1.8/timeout.rb:64:in `rbuf_fill'
/usr/lib/ruby/1.8/net/protocol.rb:134:in `rbuf_fill'
/usr/lib/ruby/1.8/net/protocol.rb:116:in `readuntil'
/usr/lib/ruby/1.8/net/protocol.rb:126:in `readline'
/usr/lib/ruby/1.8/net/http.rb:2028:in `read_status_line'
/usr/lib/ruby/1.8/net/http.rb:2017:in `read_new'
/usr/lib/ruby/1.8/net/http.rb:1051:in `request'
/usr/lib/ruby/1.8/net/http.rb:1037:in `request'
/usr/lib/ruby/1.8/net/http.rb:543:in `start'
/usr/lib/ruby/1.8/net/http.rb:1035:in `request'
/usr/lib/ruby/1.8/net/http.rb:857:in `put'
/usr/lib/ruby/site_ruby/1.8/puppet/indirector/rest.rb:98:in `send'
/usr/lib/ruby/site_ruby/1.8/puppet/indirector/rest.rb:98:in `http_request'
/usr/lib/ruby/site_ruby/1.8/puppet/indirector/rest.rb:76:in `http_put'
/usr/lib/ruby/site_ruby/1.8/puppet/indirector/rest.rb:158:in `save'
/usr/lib/ruby/site_ruby/1.8/puppet/indirector/indirection.rb:271:in `save'
/usr/lib/ruby/site_ruby/1.8/puppet/node/facts.rb:20:in `save'
/usr/lib/ruby/site_ruby/1.8/puppet/indirector/catalog/compiler.rb:26:in 
`extract_facts_from_request'
/usr/lib/ruby/site_ruby/1.8/puppet/indirector/catalog/compiler.rb:31:in 
`find'
/usr/lib/ruby/site_ruby/1.8/puppet/indirector/indirection.rb:195:in `find'
/usr/lib/ruby/site_ruby/1.8/puppet/network/http/handler.rb:109:in `do_find'
/usr/lib/ruby/site_ruby/1.8/puppet/network/http/handler.rb:68:in `send'
/usr/lib/ruby/site_ruby/1.8/puppet/network/http/handler.rb:68:in `process'
/usr/lib/ruby/site_ruby/1.8/puppet/network/http/webrick/rest.rb:24:in 
`service'
/usr/lib/ruby/1.8/webrick/httpserver.rb:104:in `service'
/usr/lib/ruby/1.8/webrick/httpserver.rb:65:in `run'
/usr/lib/ruby/site_ruby/1.8/puppet/network/http/webrick.rb:45:in `listen'
/usr/lib/ruby/1.8/webrick/server.rb:173:in `call'
/usr/lib/ruby/1.8/webrick/server.rb:173:in `start_thread'
/usr/lib/ruby/1.8/webrick/server.rb:162:in `start'
/usr/lib/ruby/1.8/webrick/server.rb:162:in `start_thread'
/usr/lib/ruby/1.8/webrick/server.rb:95:in `start'
/usr/lib/ruby/1.8/webrick/server.rb:92:in `each'
/usr/lib/ruby/1.8/webrick/server.rb:92:in `start'
/usr/lib/ruby/1.8/webrick/server.rb:23:in `start'
/usr/lib/ruby/1.8/webrick/server.rb:82:in `start'
/usr/lib/ruby/site_ruby/1.8/puppet/network/http/webrick.rb:42:in `listen'
/usr/lib/ruby/site_ruby/1.8/puppet/network/http/webrick.rb:41:in 
`initialize'
/usr/lib/ruby/site_ruby/1.8/puppet/network/http/webrick.rb:41:in `new'
/usr/lib/ruby/site_ruby/1.8/puppet/network/http/webrick.rb:41:in `listen'
/usr/lib/ruby/site_ruby/1.8/puppet/network/http/webrick.rb:38:in 
`synchronize'
/usr/lib/ruby/site_ruby/1.8/puppet/network/http/webrick.rb:38:in `listen'
/usr/lib/ruby/site_ruby/1.8/puppet/network/server.rb:126:in `listen'
/usr/lib/ruby/site_ruby/1.8/puppet/network/server.rb:141:in `start'
/usr/lib/ruby/site_ruby/1.8/puppet/daemon.rb:124:in `start'
/usr/lib/ruby/site_ruby/1.8/puppet/application/master.rb:202:in `main'
/usr/lib/ruby/site_ruby/1.8/puppet/application/master.rb:146:in 
`run_command'
/usr/lib/ruby/site_ruby/1.8/puppet/application.rb:3

[Puppet Users] Run Stages for Particular Modules

[jbrown]

Hello,

I'm new to Puppet, and I'm having some trouble getting run stages to work 
with one of my modules. The module is quite complicated and involves 
several operations where order is very important. 
In short, here are the steps
1) Install some packages
2) Create a user and home dir
3) Install Mysql-server*
4) Set mysql root pw*
5) Create databases*
6) Create db users*
7) setup grants for db users**
8) Setup firewall***
9) Create cron jobs

* Used puppetlabs-mysql
** Used puppetlabs-mysql and exec (for column-specific perms)
*** Used puppetlabs-firewall

I originally setup this module to use chaining, but it was tremendously 
complicated (one huge line). I decided to give run stages a try, and it 
seems to work, but I think that I'm doing it wrong and need some help.

Here's the init.pp for the module described above, billing.

class billing {
  include billing::install, billing::service, billing::config::main, 
billing::config::dbserver, billing::config::dbs, billing::config::dbinit, 
billing::config::dbusers, billing::config::dbgrants, billing::config::cron, 
billing::firewall, billing::firewall::sys, billing::firewall::app, 
billing::firewall::denial
}

  class {
"billing::install": stage => install;
"billing::config::main": stage => main;
"billing::config::dbserver": stage => dbserver;
"billing::config::dbs": stage => dbs;
"billing::config::dbinit": stage => dbinit;
"billing::config::dbusers": stage => dbusers;
"billing::config::dbgrants": stage => dbgrants;
"billing::config::cron": stage => cron;
"billing::firewall": stage => fwmain;
"billing::firewall::sys": stage => fwsys;
"billing::firewall::app": stage => fwapp;
"billing::firewall::denial": stage => fwdenial;
"billing::service": stage => service;
  }

  stage { install: before => Stage[main] }
  stage { main: before => Stage[dbserver] }
  stage { dbserver: before => Stage[dbs] }
  stage { dbs: before => Stage[dbinit] }
  stage { dbusers: before => Stage[dbgrants] }
  stage { dbgrants: before => Stage[cron] }
  stage { cron: before => Stage[fwmain] }
  stage { fwmain: before => Stage[fwsys] }
  stage { fwsys: before => Stage[fwapp] }
  stage { fwapp: before => Stage[fwdenial] }
  stage { fwdenial: before => Stage[service] }

  stage { service: after => Stage[fwdenial] }

Hopefully that gives a good idea of what is happening. The code for all 
those classes is too much to post here.

This module is only used on a single node. However, other nodes (that don't 
"include billing") get an error:

*Could not find stage install specified by Class[Billing::Install] at 
/etc/puppet/modules/billing/manifests/init.pp:19*

I'm guessing that is because the class and stage definitions happen outside 
"class billing { ... }." But, it was a syntax error to put them inside.

What's the recommendation here? Use chains? How do you all deal with 
modules that have lots of ordered steps?

Thanks,

Justin

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/puppet-users/-/oweGBJ8rbMYJ.
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: Where puppet store the "source" files?

[Cosmin-Viorel Ilie]

I think you need to edit the auth.conf file to allow the puppet client 
access. 

On Friday, September 14, 2012 5:12:49 PM UTC+3, itJunky wrote:
>
> I have a directive like this:
>
> file { "/etc/sudoers":
> owner => root,
> group => root,
> mode => 440, 
> source => "puppet:///modules/sudo/sudoers"
> }
>
> When i try to get this file on puppet agent, i see error:
> err: /Stage[main]/Sudo/File[/etc/sudoers]: Could not evaluate: Error 403 
> on SERVER: Forbidden request: puppet-client(192.168.200.170) access to 
> /file_metadata/modules/sudo/sudoers [find] authenticated  at line 104 Could 
> not retrieve file metadata for puppet:///modules/sudo/sudoers: Error 403 on 
> SERVER: Forbidden request: puppet-client(192.168.200.170) access to 
> /file_metadata/modules/sudo/sudoers [find] authenticated  at line 104 at 
> /etc/puppet/manifests/site.pp:12
>
> In this error message i see a path "/file_metadata/modules/sudo/sudoers"! 
> Where i can find directory "file_metadata"?
>
> I trying to change any of directives like vardir, modulepath and much 
> more, but not anyone of path not work as /file_metadata/ =(
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/puppet-users/-/Enei8SKQLjkJ.
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] Where puppet store the "source" files?

[itJunky]

I have a directive like this:

file { "/etc/sudoers":
owner => root,
group => root,
mode => 440, 
source => "puppet:///modules/sudo/sudoers"
}

When i try to get this file on puppet agent, i see error:
err: /Stage[main]/Sudo/File[/etc/sudoers]: Could not evaluate: Error 403 on 
SERVER: Forbidden request: puppet-client(192.168.200.170) access to 
/file_metadata/modules/sudo/sudoers [find] authenticated  at line 104 Could 
not retrieve file metadata for puppet:///modules/sudo/sudoers: Error 403 on 
SERVER: Forbidden request: puppet-client(192.168.200.170) access to 
/file_metadata/modules/sudo/sudoers [find] authenticated  at line 104 at 
/etc/puppet/manifests/site.pp:12

In this error message i see a path "/file_metadata/modules/sudo/sudoers"! 
Where i can find directory "file_metadata"?

I trying to change any of directives like vardir, modulepath and much more, 
but not anyone of path not work as /file_metadata/ =(

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/puppet-users/-/lkTUkWCYUBEJ.
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] Puppet conventions

[ureal frank]

Hi there,

I was reading Puppet Naming Conventions and in "Node names should match the 
hostnames of the nodes" I have a doubt.

What is 'secure/better/faster' or correct way to do this

a) node /^foo0\d+$/ {}

b) node /^foo0\d+$\.bar$/ {}   # using FQDN

I have too many servers with hostnames almost in collision :/ foo01.foo and 
foo01.bar. but with very different FQDN's.

Thanks in advance for your help :)

Regards
Frank

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/puppet-users/-/XT_nrl5van0J.
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] Automatic require in custom type?

[Jakov Sosic]

Hi.

I have 3 custom types, for example A, B, and C.

A and B are build blocks for C. So if there is no A or B, C will fail to
be added. For example:


typeA { 'A':
 ...
 ...
}


typeB { 'B':
 ...
 ...
}

typeC { 'C':
  optionA => 'A',
  optionB => 'B',
}

So, I would have to write the require in this case:

typeC { 'C':
  optionA => 'A',
  optionB => 'B',
  require => [ typeA['A'], typeB['B'] ],
}

But, if the user of my module doesn't specify correct require, typeC
will fail. Should I also write checks for this in the provider of the C
type, or just leave it to fail running extern shell command for managing C?

-- 
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] AW: Issue with large directory content

[jcbollinger]

On Friday, September 14, 2012 6:14:37 AM UTC-5, badamowicz wrote:
>
> The other questions from all of you and finally Den's question, which 
> was: "Are you trying to set any permissions inside that directory 
> elsewhere in the manifest?" made me rethink everything and pointed me to 
> the right place. A few lines down from where I thought the error was I used 
> to have this: 
>
>  file { [ 
> "${codebase_ng::repository_mount}/${sonatype_work_dir}/nexus", 
> "${codebase_ng::repository_mount}/${sonatype_work_dir}/nexus/conf"]: 
>  require => 
> File["${codebase_ng::repository_mount}/${sonatype_work_dir}"], 
>  ensure  => directory, 
>  owner   => $nexus_user_id, 
>  group   => $nexus_group_id, 
>  mode=> 0750, 
>  source  => "puppet:///modules/codebase_ng/nexus/conf", 
>  recurse => true, 
>  purge   => false, 
>  } 
>
> This file resource was just about having configuration files in place 
> below '/repository/sonatype-work/nexus/conf'. But obviously the first entry 
> in the file array which resolves to '/repository/sonatype-work/nexus' was 
> the trigger for Puppet to start recursive scanning everything. 
>
> So, the misconfiguration was on my side (nice pitfall), but I wonder if 
> this is expected behaviour. Shouldn't recursion only be done on the last 
> entry of the file array?
>


No.  Why would you suppose that?  When you write a resource declaration of 
the form

someresource { [ 'title1', 'title2']:
  param1 => value1,
  param2 => value2
}

it is shorthand for separate resource declarations, one for each title 
given, all having the specified parameters:

someresource { 'title1':
  param1 => value1,
  param2 => value2
}

someresource { 'title2':
  param1 => value1,
  param2 => value2
}

The use of an array to specify multiple titles is perhaps a bit quirky in 
itself (though useful!), but I don't see why anyone would suppose that 
resources specified that way would be assigned different parameters from 
each other.

There is nothing specific to the File resource type here, but even if there 
were, why would you expect Puppet to suppose that you only wanted recursion 
on one of the specified resources?  I don't see it.


John



-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/puppet-users/-/m7jCxW9yv2AJ.
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] AW: Issue with large directory content

[Bernd Adamowicz]

First, thanks for all the replies! And second, I found the solution. Let me 
explain:

I tried David's suggestion first (strace) and it really turned out that Puppet 
is accessing/opening every single file below '/repository/sonatype-work/'. Some 
excerpts from strace:

32124
lstat("/repository/sonatype-work/nexus/indexer/apache-snapshots-ctx/segments.gen",
 
{st_mode=S_IFREG|0644, st_size=20,...}) = 0
32124
lstat("/repository/sonatype-work/nexus/indexer/apache-snapshots-ctx/_0_1.del", 
{st_mode=S_IFREG|0750, st_size=9, ...}   ) = 0
32124
open("/repository/sonatype-work/nexus/storage/ibiblio-maven2/org/seleniumhq/selenium/selenium-support/2.25.0/selenium-support-2.25.0.jar",
O_RDONLY) = 4
32124
open("/repository/sonatype-work/nexus/storage/ibiblio-maven2/joda-time/joda-time-hibernate/1.2/joda-time-hibernate-1.2.pom",
O_RDONLY) = 4

The other questions from all of you and finally Den's question, which
was: "Are you trying to set any permissions inside that directory elsewhere in 
the manifest?" made me rethink everything and pointed me to the right place. A 
few lines down from where I thought the error was I used to have this:

 file { [
"${codebase_ng::repository_mount}/${sonatype_work_dir}/nexus",
"${codebase_ng::repository_mount}/${sonatype_work_dir}/nexus/conf"]:
 require =>
File["${codebase_ng::repository_mount}/${sonatype_work_dir}"],
 ensure  => directory,
 owner   => $nexus_user_id,
 group   => $nexus_group_id,
 mode=> 0750,
 source  => "puppet:///modules/codebase_ng/nexus/conf",
 recurse => true,
 purge   => false,
 }

This file resource was just about having configuration files in place below 
'/repository/sonatype-work/nexus/conf'. But obviously the first entry in the 
file array which resolves to '/repository/sonatype-work/nexus' was the trigger 
for Puppet to start recursive scanning everything.

So, the misconfiguration was on my side (nice pitfall), but I wonder if this is 
expected behaviour. Shouldn't recursion only be done on the last entry of the 
file array? I'm not sure. Maybe the PuppetLabs guys might think about it.

However, thanks again to all who helped and pointed me to the solution!

Bernd




On 09/14/2012 09:07 AM, David Schmitt wrote:
> Re: AW: [Puppet Users] AW: Issue with large directory content
>
> Use strace to take a look at what's really happening. That should make 
> it much easier to pinpoint the culprit:
>
>
>strace -e file -f puppet agent --test
>
>
>
> Best Regards, David
>
> On 13.09.2012 14:44, Bernd Adamowicz wrote:
> > This keeps being weird. Simply thought to wait until Puppet 
> > finishes, but had to quit after one and a half hour. Also tried 
> > 'ensure  => present' instead of 'ensure  => directory' with no 
> > success. No log output at all. Still investigating. But any ideas 
> > still highly
> appreciated!
> >
> > Bernd

-- 
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] Embedding Puppet / using it as a library / api

[robert.gstoehl]

>
>
>
> I don't know how you can use defined types from pure ruby there might be 
> a way but for native ones you can use them: 
>
>   pkg = Puppet::Type.type(:package).new(:name => "bash").provider 
>   pkg.update 
>
> updates bash. 
>

Fiddled with something like that - it even worked with a custom type "repo" 
in ruby as in the book "pro puppet":

  Puppet::Type.newtype(:repo) do
@doc = "Manage repos"  
ensurable  

newparam(:source) do
...

  Puppet::Type.type(:repo).provide(:git) do
desc "Provides Git support for the repo provider"
commands :gitcmd => "git"
def create
...
  repo = Puppet::Resource.new( 
:repo, "puppet",
:parameters => {
  :source => "git://github.com/puppetlabs/puppet.git",
  :path => "/tmp/puppet",
...

  catalog = Puppet::Resource::Catalog.new("localhost")
  catalog.add_resource(repo)
  transaction = catalog.apply
  transaction.report

I'm doing something wrong with the catalog (it doesn't apply anything) but 
I'll get that sorted out probably, need to look at 
lib/puppet/application/resource.rb.
Still having the impression that I'm using internal apis -> probably just 
have to live with the fact, that they might break some day.

Thanks,

Robert

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/puppet-users/-/MWdfKsAfJQ8J.
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] Embedding Puppet / using it as a library / api

[Robert Gstoehl]

On Fri, Sep 14, 2012 at 12:21 PM, R.I.Pienaar  wrote:
>
>
> - Original Message -
>> From: "Robert Gstoehl" 
>> To: puppet-users@googlegroups.com
>> Sent: Friday, September 14, 2012 11:12:14 AM
>> Subject: Re: [Puppet Users] Embedding Puppet / using it as a library / api
>>
>> On Fri, Sep 14, 2012 at 11:59 AM, Robert Gstoehl
>>  wrote:
>> > On Fri, Sep 14, 2012 at 11:52 AM, R.I.Pienaar 
>> > wrote:
>> >>
>> >>
>> >> - Original Message -
>> >>> From: "robert.gstoehl" 
>> >>> To: puppet-users@googlegroups.com
>> >>> Sent: Friday, September 14, 2012 10:25:51 AM
>> >>> Subject: [Puppet Users] Embedding Puppet / using it as a library
>> >>> / api
>> >>>
>> >>> Hey there,
>> >>>
>> >>> I'm thinking about reusing custom types from existing puppet
>> >>> infrastructure in standalone (ruby)
>> >>> applications.
>> >>>
>> >>> Example -> Custom Type for a "storage pool" consisting of volume
>> >>> groups,
>> >>> logical volumes, drbd resources, filesystems, nfs export... you
>> >>> get
>> >>> the idea.
>> >>>
>> >>> Suppose that we have already defined this type in the form of a
>> >>> puppet module / custom type.
>> >>
>> >> do you mean a type written in ruby or a defined type like 'define
>> >> foo' in
>> >> a .pp file?
>> >
>> > Thinking about a custom .pp type currently. Although does it make
>> > that
>> > much of a difference?
>> >
>> > I mean code wise, both are Puppet::Resource - thingys at the end of
>> > the day, aren't they?
>>
>> Fingers faster then brainz -> .rb types of course. Need to have some
>> coffee, sorry ;)
>
> I don't know how you can use defined types from pure ruby there might be
> a way but for native ones you can use them:
>
>   pkg = Puppet::Type.type(:package).new(:name => "bash").provider
>   pkg.update
>
> updates bash.

Fiddled with something like that but got the impression that I was
using internal apis (which might break some day).
Than I read about the new "faces" and tried that one:



Currently I'm a bit confused about

-- 
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] Puppet ignoring ENC classes

[Cosmin-Viorel Ilie]

If i try to emulate what puppet is doing and call the script with the node 
name i get:

[root@v-test-mng-01 puppet-dashboard]# /usr/bin/env 
PUPPET_DASHBOARD_URL=http://v-test-mng-01:3000 
/usr/share/puppet-dashboard/bin/external_node v-test-tst-01.domain.net
---
name: v-test-tst-01.domain.net
parameters: {}

classes:
- test



On Friday, September 14, 2012 12:54:45 PM UTC+3, R.I. Pienaar wrote:
>
>
>
> - Original Message - 
> > From: "Cosmin-Viorel Ilie" > 
> > To: puppet...@googlegroups.com  
> > Sent: Friday, September 14, 2012 10:43:48 AM 
> > Subject: [Puppet Users] Puppet ignoring ENC classes 
> > 
> > Hi everyone, 
> > 
> > I've been bashing my head in the wall for several days now trying to 
> > find out why puppet isn't loading the class from enc. I've setup the 
> > enc from puppet-dashboard which returns: 
> > 
> > [root@v-test-mng-01 puppet-dashboard]# /usr/bin/env 
> > PUPPET_DASHBOARD_URL=http://v-test-mng-01:3000 
> > /usr/share/puppet-dashboard/bin/external_node 
> > 
> > 
> > 
> > --- 
> > - name: v-test-tst-01.domain.net 
> > parameters: {} 
> > 
> > classes: 
> > - test 
> > - name: v-test-mng-01.domain.net 
> > parameters: {} 
> > 
> > classes: [] 
>
>
> When puppet calls your script it will pass in the node name information 
> as arguments to your script. 
>
> Your script must then return information for just the one node requested 
> so your result should be something like: 
>
> parameters: {} 
> classes: 
>   - test 
>
> without node name etc 
>
> see http://docs.puppetlabs.com/guides/external_nodes.html 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/puppet-users/-/BgnTUHf3KoMJ.
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] Embedding Puppet / using it as a library / api

[R.I.Pienaar]

- Original Message -
> From: "Robert Gstoehl" 
> To: puppet-users@googlegroups.com
> Sent: Friday, September 14, 2012 11:12:14 AM
> Subject: Re: [Puppet Users] Embedding Puppet / using it as a library / api
> 
> On Fri, Sep 14, 2012 at 11:59 AM, Robert Gstoehl
>  wrote:
> > On Fri, Sep 14, 2012 at 11:52 AM, R.I.Pienaar 
> > wrote:
> >>
> >>
> >> - Original Message -
> >>> From: "robert.gstoehl" 
> >>> To: puppet-users@googlegroups.com
> >>> Sent: Friday, September 14, 2012 10:25:51 AM
> >>> Subject: [Puppet Users] Embedding Puppet / using it as a library
> >>> / api
> >>>
> >>> Hey there,
> >>>
> >>> I'm thinking about reusing custom types from existing puppet
> >>> infrastructure in standalone (ruby)
> >>> applications.
> >>>
> >>> Example -> Custom Type for a "storage pool" consisting of volume
> >>> groups,
> >>> logical volumes, drbd resources, filesystems, nfs export... you
> >>> get
> >>> the idea.
> >>>
> >>> Suppose that we have already defined this type in the form of a
> >>> puppet module / custom type.
> >>
> >> do you mean a type written in ruby or a defined type like 'define
> >> foo' in
> >> a .pp file?
> >
> > Thinking about a custom .pp type currently. Although does it make
> > that
> > much of a difference?
> >
> > I mean code wise, both are Puppet::Resource - thingys at the end of
> > the day, aren't they?
> 
> Fingers faster then brainz -> .rb types of course. Need to have some
> coffee, sorry ;)

I don't know how you can use defined types from pure ruby there might be
a way but for native ones you can use them:

  pkg = Puppet::Type.type(:package).new(:name => "bash").provider 
  pkg.update

updates bash.

-- 
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] Why agent report is so slow?

[flex]

Thanks, Daniel. We do have some recursive file copies and hundreds of other
resources. So we'd better decrease the resources numbers?

On Fri, Sep 14, 2012 at 2:44 AM, Daniel Pittman wrote:

> On Thu, Sep 13, 2012 at 12:31 AM, flex  wrote:
> >
> > I use cron to run puppet agent, but recently i found the script takes too
> > long time. After using '--debug', i got this log:
> >
> > 2012-09-13 15:19:53.928744500 debug: Finishing transaction 69941650538440
> > 2012-09-13 15:19:53.928988500 debug: Storing state
> > 2012-09-13 15:19:54.930995500 debug: Stored state in 1.00 seconds
> > 2012-09-13 15:19:54.931145500 notice: Finished catalog run in 48.21
> seconds
> > 2012-09-13 15:20:03.721411500 debug: Value of
> > 'preferred_serialization_format' (pson) is invalid for report, using
> default
> > (b64_zlib_yaml)
> > 2012-09-13 15:20:03.721578500 debug: report supports formats:
> b64_zlib_yaml
> > raw yaml; using b64_zlib_yaml
> > 2012-09-13 15:21:10.805932500 Puppet run done.
> >
> > The last 'Puppet run done' is a bash echo after puppet agent. So we can
> see
> > it took 1 minute and more before the echo line. But if i set 'report =
> > false' in puppet.conf, there is no such long time. Does puppet use this
> time
> > to generate and send reports?
>
> In essence, yes: we build the report structure as we go, but
> transforming it for submission, and sending it over the wire,
> certainly take time.  That is proportional to the number of resources
> you have in your catalog, including things like recursive file copies
> or tidies.
>
> >How can i tune this?
>
> There really isn't any way to improve performance: there isn't (much)
> you can do to improve YAML output performance - although Telly, Puppet
> 3.0.0, will be a bit faster at building YAML when it is released.
>
> You could check to see if the performance problem comes from network
> transmission problems, but really there isn't much you can do to
> improve a single HTTPS request, which is how we submit the report back
> to the the master.
>
> --
> Daniel Pittman
> ⎋ Puppet Labs Developer – http://puppetlabs.com
> ♲ Made with 100 percent post-consumer electrons
>
> --
> 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.
>
>

-- 
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] Embedding Puppet / using it as a library / api

[Robert Gstoehl]

On Fri, Sep 14, 2012 at 11:59 AM, Robert Gstoehl
 wrote:
> On Fri, Sep 14, 2012 at 11:52 AM, R.I.Pienaar  wrote:
>>
>>
>> - Original Message -
>>> From: "robert.gstoehl" 
>>> To: puppet-users@googlegroups.com
>>> Sent: Friday, September 14, 2012 10:25:51 AM
>>> Subject: [Puppet Users] Embedding Puppet / using it as a library / api
>>>
>>> Hey there,
>>>
>>> I'm thinking about reusing custom types from existing puppet
>>> infrastructure in standalone (ruby)
>>> applications.
>>>
>>> Example -> Custom Type for a "storage pool" consisting of volume groups,
>>> logical volumes, drbd resources, filesystems, nfs export... you get
>>> the idea.
>>>
>>> Suppose that we have already defined this type in the form of a
>>> puppet module / custom type.
>>
>> do you mean a type written in ruby or a defined type like 'define foo' in
>> a .pp file?
>
> Thinking about a custom .pp type currently. Although does it make that
> much of a difference?
>
> I mean code wise, both are Puppet::Resource - thingys at the end of
> the day, aren't they?

Fingers faster then brainz -> .rb types of course. Need to have some
coffee, sorry ;)

-- 
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] Embedding Puppet / using it as a library / api

[Robert Gstoehl]

On Fri, Sep 14, 2012 at 11:52 AM, R.I.Pienaar  wrote:
>
>
> - Original Message -
>> From: "robert.gstoehl" 
>> To: puppet-users@googlegroups.com
>> Sent: Friday, September 14, 2012 10:25:51 AM
>> Subject: [Puppet Users] Embedding Puppet / using it as a library / api
>>
>> Hey there,
>>
>> I'm thinking about reusing custom types from existing puppet
>> infrastructure in standalone (ruby)
>> applications.
>>
>> Example -> Custom Type for a "storage pool" consisting of volume groups,
>> logical volumes, drbd resources, filesystems, nfs export... you get
>> the idea.
>>
>> Suppose that we have already defined this type in the form of a
>> puppet module / custom type.
>
> do you mean a type written in ruby or a defined type like 'define foo' in
> a .pp file?

Thinking about a custom .pp type currently. Although does it make that
much of a difference?

I mean code wise, both are Puppet::Resource - thingys at the end of
the day, aren't they?

-- 
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] Puppet ignoring ENC classes

[R.I.Pienaar]

- Original Message -
> From: "Cosmin-Viorel Ilie" 
> To: puppet-users@googlegroups.com
> Sent: Friday, September 14, 2012 10:43:48 AM
> Subject: [Puppet Users] Puppet ignoring ENC classes
> 
> Hi everyone,
> 
> I've been bashing my head in the wall for several days now trying to
> find out why puppet isn't loading the class from enc. I've setup the
> enc from puppet-dashboard which returns:
> 
> [root@v-test-mng-01 puppet-dashboard]# /usr/bin/env
> PUPPET_DASHBOARD_URL=http://v-test-mng-01:3000
> /usr/share/puppet-dashboard/bin/external_node
> 
> 
> 
> ---
> - name: v-test-tst-01.domain.net
> parameters: {}
> 
> classes:
> - test
> - name: v-test-mng-01.domain.net
> parameters: {}
> 
> classes: []


When puppet calls your script it will pass in the node name information
as arguments to your script.

Your script must then return information for just the one node requested
so your result should be something like:

parameters: {}
classes:
  - test

without node name etc

see http://docs.puppetlabs.com/guides/external_nodes.html

-- 
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] Embedding Puppet / using it as a library / api

[R.I.Pienaar]

- Original Message -
> From: "robert.gstoehl" 
> To: puppet-users@googlegroups.com
> Sent: Friday, September 14, 2012 10:25:51 AM
> Subject: [Puppet Users] Embedding Puppet / using it as a library / api
> 
> Hey there,
> 
> I'm thinking about reusing custom types from existing puppet
> infrastructure in standalone (ruby)
> applications.
> 
> Example -> Custom Type for a "storage pool" consisting of volume groups,
> logical volumes, drbd resources, filesystems, nfs export... you get
> the idea.
> 
> Suppose that we have already defined this type in the form of a
> puppet module / custom type.

do you mean a type written in ruby or a defined type like 'define foo' in
a .pp file?

-- 
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] Puppet ignoring ENC classes

[Cosmin-Viorel Ilie]

Hi everyone,

I've been bashing my head in the wall for several days now trying to find 
out why puppet isn't loading the class from enc. I've setup the enc from 
puppet-dashboard which returns:

[root@v-test-mng-01 puppet-dashboard]# /usr/bin/env 
PUPPET_DASHBOARD_URL=http://v-test-mng-01:3000 
/usr/share/puppet-dashboard/bin/external_node

---
- name: v-test-tst-01.domain.net
  parameters: {}

  classes:
  - test
- name: v-test-mng-01.domain.net
  parameters: {}

  classes: []


however when i run  puppet agent --test --debug --no-daemonize -v on 
v-test-tst-01 the class is not loaded. If a look in the 
/var/lib/puppet/classes.txt on the agent i only see an entry for settings, 
but not the test class. Permissions to the 
/usr/share/puppet-dashboard/bin/external_node are [-rwxr-xr-x 1 puppet 
puppet 1453 Sep 12 04:43 /usr/share/puppet-dashboard/bin/external_node]. 

The test module is as fallows:

test/manifests/init.pp
   class test ($var='default') {
notify {$var:}
 }


The puppet config file is :

[main]

# The Puppet log directory.
# The default value is '$vardir/log'.
logdir = /var/log/puppet

server= v-test-mng-01.domain.net
# Where Puppet PID files are kept.
# The default value is '$vardir/run'.
rundir = /var/run/puppet

# Where SSL certificates are kept.
# The default value is '$confdir/ssl'.
ssldir = $vardir/ssl
autosign=true
environment = production

[agent]
# The file in which puppetd stores a list of the classes
# associated with the retrieved configuratiion.  Can be loaded in
# the separate ``puppet`` executable using the ``--loadclasses``
# option.
# The default value is '$confdir/classes.txt'.
classfile = $vardir/classes.txt

# Where puppetd caches the local configuration.  An
# extension indicating the cache format is added automatically.
# The default value is '$confdir/localconfig'.
localconfig = $vardir/localconfig
report = true

[master]
node_terminus = exec
external_nodes = /usr/bin/env 
PUPPET_DASHBOARD_URL=http://v-test-mng-01:3000 
/usr/share/puppet-dashboard/bin/external_node

ssl_client_header = SSL_CLIENT_S_D
ssl_client_verify_header = SSL_CLIENT_VERIFY
storeconfigs = true
dbadapter = mysql
dbname = puppet
dbuser = puppet
dbpassword = 
dbserver = localhost
dbsocket = /var/lib/mysql/mysql.sock
reports = http,store,log
reporturl = http://localhost:3000/reports/upload


If i create the *site.pp *and add the node definition there everything 
works fine. 

The dashboard is on the same machine as the puppet master (v-test-mng-01 in 
my case).  If i run: *puppet master --configprint external_nodes*
/usr/bin/env PUPPET_DASHBOARD_URL=http://v-test-mng-01:3000 
/usr/share/puppet-dashboard/bin/external_node

I'm using puppet 3.0 RC6 and dashboard 1.2.11 with Ruby 1.8.7 (2011-06-30 
patchlevel 352) [x86_64-linux]


I'm running out of ideas on how to get this working so any idea or help 
would be appreciated.

The output from the agent run is attached.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/puppet-users/-/sFphxgIZIycJ.
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.

[root@v-test-tst-01 puppet]# puppet agent --test --debug --no-daemonize -v
Debug: Using settings: adding file resource 'confdir': 
'File[/etc/puppet]{:links=>:follow, :backup=>false, :loglevel=>:debug, 
:path=>"/etc/puppet", :ensure=>:directory}'
Debug: Using settings: adding file resource 'lastrunreport': 
'File[/var/lib/puppet/state/last_run_report.yaml]{:links=>:follow, 
:backup=>false, :mode=>"640", :loglevel=>:debug, 
:path=>"/var/lib/puppet/state/last_run_report.yaml", :ensure=>:file}'
Debug: Puppet::Type::User::ProviderDirectoryservice: file /usr/bin/dscl does 
not exist
Debug: Puppet::Type::User::ProviderLdap: true value when expecting false
Debug: Puppet::Type::User::ProviderPw: file pw does not exist
Debug: Puppet::Type::User::ProviderUser_role_add: file roleadd does not exist
Debug: Using settings: adding file resource 'publickeydir': 
'File[/var/lib/puppet/ssl/public_keys]{:links=>:follow, :backup=>false, 
:owner=>"puppet", :loglevel=>:debug, :path=>"/var/lib/puppet/ssl/public_keys", 
:ensure=>:directory}'
Debug: Using settings: adding file resource 'privatedir': 
'File[/var/lib/puppet/ssl/private]{:links=>:follow, :backup=>false, 
:owner=>"puppet", :mode=>"750", :loglevel=>:debug, 
:path=>"/var/lib/puppet/ssl/private", :ensure=>:directory}'
Debug: Using settings: adding file resource 'hostcert': 
'File[/var/lib/puppet/ssl/certs/v-test-tst-01.domain.net.pem]{:links=>:follow, 
:backup=>f

[Puppet Users] Embedding Puppet / using it as a library / api

[robert.gstoehl]

Hey there,

I'm thinking about reusing custom types from existing puppet infrastructure in 
standalone (ruby)
applications.

Example -> Custom Type for a "storage pool" consisting of volume groups,
logical volumes, drbd resources, filesystems, nfs export... you get the idea.

Suppose that we have already defined this type in the form of a puppet module / 
custom type.

Instead of reimplementing this stuff in an external library / script I'd
rather reuse the puppet module, and as an additional goody, use some of the
puppet datatypes / features (reporting differences in system state, noop, 
transaction, ...)

So far I stumbled upon some different concepts in puppet land which might make
this possible:

puppet internal dsl

puppet faces

rest api

One requirement would be the "standalone" aspect. While interacting with this
hypthetical storage pool, I'd rather not do network roundtrips to the puppet
master, as I prefer robustness over freshness in this case.

I looked somewhat into the faces variant but coldn't find a way to construct a
catalog without talking to the master.

And by using just the Faces[:resource, ..] - stuff I'm missing some
other nice features of the catalog.

Any ideas / snippets / tips / tutorials to get me started?

Thanks alot in advance

Cheers

Robert


-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/puppet-users/-/CaaCOxX_UK4J.
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] Managing classes of machines

[Luke Bigum]

A very popular design is the "module per package/service" approach. Your 
modules become building blocks and your node definitions pull all the 
building blocks in to describe a certain machine. So if you've got web 
and database server types, your modules might be "apache" and "mysql".


If you are just starting out you might want a "dev_apache" and 
"prod_apache" module, but once you get more confident in your Puppet 
skills you will want to start coding your modules with a bit of 
flexibility, so you can use the same apache module for your development 
and production servers. After all, Puppet is about not repeating yourself.


The Pro Puppet book is a very good place to start - it starts simple and 
then goes into the apache::install, apache::config and apache::service 
sub-class design which I'm a big fan of.


Hope that helps,

-Luke

On 14/09/12 07:23, Gregory Orange wrote:

Hi everyone,
We've got a fairly small set of machines (perhaps 30) soon to be 
managed with puppet. We're looking for a good way to define which 
machines get which packages, and how those packages are configured on 
certain sets of machines.


e.g. Apache on devel and production-webserver machines, but not on 
producation-db machines. Apache should be configured differently on 
devel machines compared to production-webserver machines.


I've read a couple of conflicting opinions on this from mailing list 
archives (I think) pages on the puppetlabs website, and the Pro Puppet 
book, so I'm ignoring it all for the moment and asking for opinions here.


TIA,
Greg.




--
Luke Bigum
Senior Systems Engineer

Information Systems
Ph: +44 (0) 20 3192 2520
luke.bi...@lmax.com | http://www.lmax.com
LMAX, Yellow Building, 1A Nicholas Road, London W11 4AN


FX and CFDs are leveraged products that can result in losses exceeding
your deposit.  They are not suitable for everyone so please ensure you
fully understand the risks involved.  The information in this email is not
directed at residents of the United States of America or any other
jurisdiction where trading in CFDs and/or FX is restricted or prohibited
by local laws or regulations.

The information in this email and any attachment is confidential and is
intended only for the named recipient(s). The email may not be disclosed
or used by any person other than the addressee, nor may it be copied in
any way. If you are not the intended recipient please notify the sender
immediately and delete any copies of this message. Any unauthorised
copying, disclosure or distribution of the material in this e-mail is
strictly forbidden.

LMAX operates a multilateral trading facility.  Authorised and regulated 
by the Financial Services Authority (firm registration number 509778) and
is registered in England and Wales (number 06505809). 
Our registered address is Yellow Building, 1A Nicholas Road, London, W11

4AN.

--
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] puppet master replica in different data center and subnet

[Myra Haubrich]

Any suggestions on the best way to configure a puppet master replica/puppet 
HA/failover in different data center and subnet? Thought about masterless 
puppet, but seems like it is only good for some number of puppet agents. 

Thanks,
Myra

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/puppet-users/-/e8mMk9SG9VQJ.
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: I am trying to copy over a authorized_key file over to all the servers using puppet but it doe snot see to work. can any one help?

[Luke Bigum]

Can you show us the full file structure of your sshkey module as it 
appears on your puppet master, as well as the puppet master's puppet.conf.


On 14/09/12 02:18, JGonza1 wrote:

this is my init.pp file.
node "ct-eng-pats02-devint"
 inherits default {
 include patshosts
 include users
 include patslocalhost
 include patsj2ee
 include tomcat-prod
 include ntp
 include webmanager
 include webapps
 include setjava
 include physjava
 include weblib
 include physbasecat
 include patscommsvcpts
 include patslinks
 include patskey
 include webapps
 include sharedfiles
 include patscache
 include setclassfile
 include sshkey
}

On Thursday, September 13, 2012 5:23:50 PM UTC-7, JGonza1 wrote:

This is how my init.pp files looks below and I get this error err:
Could not retrieve catalog from remote server: Error 400 on
SERVER: Could not find class sshkey for
ct-eng-pats02-devint.caretools.ent at
/etc/puppet/manifests/nodes/pats02.pp:22 on node
ct-eng-pats02-devint.caretools.ent
warning: Not using cache on failed catalog
err: Could not retrieve catalog; skipping run
class sshkey {
# file { "/root/.ssh":
#  ensure => "directory",
#  owner => "root",
#  group => "root",
#  mode => 600,
# }
exec {'mkdir -p /root/.ssh':
unless => 'test -d /root/.ssh',
  }
  file {
"/root/.ssh/authorized_keys":
  ensure => file,
  source => "puppet:///sshkey/authorized_keys",
  owner => "root",
  group => "root",
  mode => 600;
  }
}

--
You received this message because you are subscribed to the Google 
Groups "Puppet Users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/puppet-users/-/xcaKUI7GRRAJ.

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.



--
Luke Bigum
Senior Systems Engineer

Information Systems
Ph: +44 (0) 20 3192 2520
luke.bi...@lmax.com | http://www.lmax.com
LMAX, Yellow Building, 1A Nicholas Road, London W11 4AN



FX and CFDs are leveraged products that can result in losses exceeding
your deposit.  They are not suitable for everyone so please ensure you
fully understand the risks involved.  The information in this email is not
directed at residents of the United States of America or any other
jurisdiction where trading in CFDs and/or FX is restricted or prohibited
by local laws or regulations.

The information in this email and any attachment is confidential and is
intended only for the named recipient(s). The email may not be disclosed
or used by any person other than the addressee, nor may it be copied in
any way. If you are not the intended recipient please notify the sender
immediately and delete any copies of this message. Any unauthorised
copying, disclosure or distribution of the material in this e-mail is
strictly forbidden.

LMAX operates a multilateral trading facility.  Authorised and regulated 
by the Financial Services Authority (firm registration number 509778) and
is registered in England and Wales (number 06505809). 
Our registered address is Yellow Building, 1A Nicholas Road, London, W11

4AN.

--
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] Announce: Puppet Dashboard 1.2.11 Available

[Antidot SAS]

Hi,


Apparently the /etc/puppet-dashboard/setting.yml needed to be modify by the
one from the package sorry for the disturbance.


Regards,
JM

My bad, forget

On Fri, Sep 14, 2012 at 10:13 AM, Antidot SAS  wrote:

> Hi,
>
>
> I just update my debian with the new dashboard and I am encountering the
> following error:
> Processing PagesController#home (for 10.63.1.64 at 2012-09-14 10:12:08)
> [GET]
>   Parameters: {"action"=>"home", "controller"=>"pages"}
> Rendering template within layouts/application
> Rendering pages/home
>
> ActionView::TemplateError (`per_page` setting cannot be less than 1 (0
> given)) on line #2 of app/views/nodes/_nodes.html.haml:
> 1: - node_count  = local_assigns[:nodes].count
> 2: - nodes   = paginate_scope(local_assigns[:nodes])
> 3: - container   = local_assigns[:container]
> 4: - selected_status = local_assigns[:selected_status]
> 5: - more_link   = local_assigns[:more_link]
>
> vendor/gems/will_paginate-2.3.15/lib/will_paginate/collection.rb:51:in
> `initialize'
> vendor/gems/will_paginate-2.3.15/lib/will_paginate/collection.rb:84:in
> `new'
> vendor/gems/will_paginate-2.3.15/lib/will_paginate/collection.rb:84:in
> `create'
> vendor/gems/will_paginate-2.3.15/lib/will_paginate/finder.rb:76:in
> `paginate'
> app/helpers/paginate_scope_helper.rb:5:in `paginate_scope'
> app/views/nodes/_nodes.html.haml:2:in
> `_run_haml_app47views47nodes47_nodes46html46haml_locals_more_link_nodes_object_selected_status'
> haml (3.1.2) [v] rails/./lib/haml/helpers/action_view_mods.rb:11:in
> `render'
> haml (3.1.2) [v] lib/haml/helpers.rb:90:in `non_haml'
> haml (3.1.2) [v] rails/./lib/haml/helpers/action_view_mods.rb:11:in
> `render'
> app/views/pages/home.html.haml:17:in
> `_run_haml_app47views47pages47home46html46haml'
> app/views/pages/home.html.haml:16:in `each'
> app/views/pages/home.html.haml:16:in
> `_run_haml_app47views47pages47home46html46haml'
> haml (3.1.2) [v] rails/./lib/haml/helpers/action_view_mods.rb:13:in
> `render'
> haml (3.1.2) [v] rails/./lib/haml/helpers/action_view_mods.rb:13:in
> `render'
> sass (3.1.2) [v] rails/./lib/sass/plugin/rack.rb:54:in `call'
> /usr/lib/ruby/1.8/webrick/httpserver.rb:104:in `service'
> /usr/lib/ruby/1.8/webrick/httpserver.rb:65:in `run'
> /usr/lib/ruby/1.8/webrick/server.rb:173:in `start_thread'
> /usr/lib/ruby/1.8/webrick/server.rb:162:in `start'
> /usr/lib/ruby/1.8/webrick/server.rb:162:in `start_thread'
> /usr/lib/ruby/1.8/webrick/server.rb:95:in `start'
> /usr/lib/ruby/1.8/webrick/server.rb:92:in `each'
> /usr/lib/ruby/1.8/webrick/server.rb:92:in `start'
> /usr/lib/ruby/1.8/webrick/server.rb:23:in `start'
> /usr/lib/ruby/1.8/webrick/server.rb:82:in `start'
>
> Rendering /usr/share/puppet-dashboard/public/500.html (500 Internal Server
> Error)
>
>
> On debian squeeze.
>
> gem list
>
> *** LOCAL GEMS ***
>
> rack (1.1.2)
> rake (0.9.2.2)
>
>
> Any idea what could be the issue?
>
>
> Regards,
> JM
>
>
>
>
>
> On Fri, Sep 14, 2012 at 12:14 AM, Matthaus Owens 
> wrote:
>
>> Puppet Dashboard 1.2.11 is a maintenance and bugfix release of Puppet
>> Dashboard.
>>
>> This release is available for download at:
>> https://downloads.puppetlabs.com/dashboard/puppet-dashboard-1.2.11.tar.gz
>>
>> Debian packages are available at
>> https://apt.puppetlabs.com
>>
>> RPM packages are available at
>> https://yum.puppetlabs.com
>>
>> See the Verifying Puppet Download section at:
>> http://projects.puppetlabs.com/projects/puppet/wiki/Downloading_Puppet
>>
>> Please report feedback via the Puppet Labs Redmine site, using an
>> affected version of 1.2.11:
>> http://projects.puppetlabs.com/projects/dashboard
>>
>> Documentation is available at:
>> http://docs.puppetlabs.com/dashboard/index.html
>>
>> Puppet Dashboard 1.2.11 Highlights
>> 
>> (#15196) Make items per page configurable
>> This commit adds the ability to specify the number of specific items
>> per page displayed by dashboard in the settings.yml file, including
>> nodes, classes, groups and reports per page.
>>
>> Autorefresh link gen fixed to work under passenger
>> Autorefresh link generation did not take root_path for the
>> application into consideration. Using File.join() to try and avoid
>> multiple /'s getting into generated url which would cause routing
>> problems.
>>
>> Shift to using packaging repo for packaging tasks
>> This release introduces Dashboard's use of the packaging repo at
>> https://github.com/puppetlabs/packaging for packaging automation.
>> From
>> source, doing a rake package:bootstrap clones packaging tasks into
>> ext/packaging and adds rake tasks for packaging of tar, srpm, rpm, and
>> deb using tools such as rpmbuild and debuild, as well as
>> puppetlabs-namespaced tasks that use chroot environment tools and are
>> keyed to specifically interacting with the puppetlabs enviro

Re: [Puppet Users] Announce: Puppet Dashboard 1.2.11 Available

[Antidot SAS]

Hi,


I just update my debian with the new dashboard and I am encountering the
following error:
Processing PagesController#home (for 10.63.1.64 at 2012-09-14 10:12:08)
[GET]
  Parameters: {"action"=>"home", "controller"=>"pages"}
Rendering template within layouts/application
Rendering pages/home

ActionView::TemplateError (`per_page` setting cannot be less than 1 (0
given)) on line #2 of app/views/nodes/_nodes.html.haml:
1: - node_count  = local_assigns[:nodes].count
2: - nodes   = paginate_scope(local_assigns[:nodes])
3: - container   = local_assigns[:container]
4: - selected_status = local_assigns[:selected_status]
5: - more_link   = local_assigns[:more_link]

vendor/gems/will_paginate-2.3.15/lib/will_paginate/collection.rb:51:in
`initialize'
vendor/gems/will_paginate-2.3.15/lib/will_paginate/collection.rb:84:in
`new'
vendor/gems/will_paginate-2.3.15/lib/will_paginate/collection.rb:84:in
`create'
vendor/gems/will_paginate-2.3.15/lib/will_paginate/finder.rb:76:in
`paginate'
app/helpers/paginate_scope_helper.rb:5:in `paginate_scope'
app/views/nodes/_nodes.html.haml:2:in
`_run_haml_app47views47nodes47_nodes46html46haml_locals_more_link_nodes_object_selected_status'
haml (3.1.2) [v] rails/./lib/haml/helpers/action_view_mods.rb:11:in
`render'
haml (3.1.2) [v] lib/haml/helpers.rb:90:in `non_haml'
haml (3.1.2) [v] rails/./lib/haml/helpers/action_view_mods.rb:11:in
`render'
app/views/pages/home.html.haml:17:in
`_run_haml_app47views47pages47home46html46haml'
app/views/pages/home.html.haml:16:in `each'
app/views/pages/home.html.haml:16:in
`_run_haml_app47views47pages47home46html46haml'
haml (3.1.2) [v] rails/./lib/haml/helpers/action_view_mods.rb:13:in
`render'
haml (3.1.2) [v] rails/./lib/haml/helpers/action_view_mods.rb:13:in
`render'
sass (3.1.2) [v] rails/./lib/sass/plugin/rack.rb:54:in `call'
/usr/lib/ruby/1.8/webrick/httpserver.rb:104:in `service'
/usr/lib/ruby/1.8/webrick/httpserver.rb:65:in `run'
/usr/lib/ruby/1.8/webrick/server.rb:173:in `start_thread'
/usr/lib/ruby/1.8/webrick/server.rb:162:in `start'
/usr/lib/ruby/1.8/webrick/server.rb:162:in `start_thread'
/usr/lib/ruby/1.8/webrick/server.rb:95:in `start'
/usr/lib/ruby/1.8/webrick/server.rb:92:in `each'
/usr/lib/ruby/1.8/webrick/server.rb:92:in `start'
/usr/lib/ruby/1.8/webrick/server.rb:23:in `start'
/usr/lib/ruby/1.8/webrick/server.rb:82:in `start'

Rendering /usr/share/puppet-dashboard/public/500.html (500 Internal Server
Error)


On debian squeeze.

gem list

*** LOCAL GEMS ***

rack (1.1.2)
rake (0.9.2.2)


Any idea what could be the issue?


Regards,
JM





On Fri, Sep 14, 2012 at 12:14 AM, Matthaus Owens wrote:

> Puppet Dashboard 1.2.11 is a maintenance and bugfix release of Puppet
> Dashboard.
>
> This release is available for download at:
> https://downloads.puppetlabs.com/dashboard/puppet-dashboard-1.2.11.tar.gz
>
> Debian packages are available at
> https://apt.puppetlabs.com
>
> RPM packages are available at
> https://yum.puppetlabs.com
>
> See the Verifying Puppet Download section at:
> http://projects.puppetlabs.com/projects/puppet/wiki/Downloading_Puppet
>
> Please report feedback via the Puppet Labs Redmine site, using an
> affected version of 1.2.11:
> http://projects.puppetlabs.com/projects/dashboard
>
> Documentation is available at:
> http://docs.puppetlabs.com/dashboard/index.html
>
> Puppet Dashboard 1.2.11 Highlights
> 
> (#15196) Make items per page configurable
> This commit adds the ability to specify the number of specific items
> per page displayed by dashboard in the settings.yml file, including
> nodes, classes, groups and reports per page.
>
> Autorefresh link gen fixed to work under passenger
> Autorefresh link generation did not take root_path for the
> application into consideration. Using File.join() to try and avoid
> multiple /'s getting into generated url which would cause routing
> problems.
>
> Shift to using packaging repo for packaging tasks
> This release introduces Dashboard's use of the packaging repo at
> https://github.com/puppetlabs/packaging for packaging automation. From
> source, doing a rake package:bootstrap clones packaging tasks into
> ext/packaging and adds rake tasks for packaging of tar, srpm, rpm, and
> deb using tools such as rpmbuild and debuild, as well as
> puppetlabs-namespaced tasks that use chroot environment tools and are
> keyed to specifically interacting with the puppetlabs environment. The
> packaging repo works in tandem with the new package-builder modules
> designed to set up hosts for packaging,
> https://github.com/puppetlabs/puppetlabs-rpmbuilder, and
> https://github.com/puppetlabs/puppetlabs-debbuilder. This is very much
> a work in progress, but a model for how packaging automation could
> improve across many Puppet Labs projects.
>
> Puppet Dashbo

Re: [Puppet Users] AW: Issue with large directory content

[Andrew Stangl]

I had a similar issue some time back, and it was pointed out by the very 
helpful people in this group that puppet does an MD5 sum (or other hash 
check) on each file in the directory structure (probably something the 
strace mentioned would show you)

This post gives a suggested solution to managing a large directory 
structure: 
https://groups.google.com/forum/?fromgroups=#!topic/puppet-users/mnkHU09FcZI

So, the best approach is to exec find(1) or something similar, with an 
unless to limit the run if it's not going to need to make any changes.

The only thing puzzling me, is that you're specifying recurse => false... 
so I'd expect there may be something else going on.
Is the directory on the same files-system as the OS? or is it a mounted 
(NFS?) volume? 
Your code specify's "mountpoint" .. so this may be the source of your 
issue, not the recurse/managment.
If this is the case, you would possibly be better off managing the 
mountpoint with the mount directive, in which case, you 
may be experiencing something similar to what we dealt with here: 
https://groups.google.com/forum/?fromgroups=#!topic/puppet-users/xig1zZzoIpM
 
Hope this helps,
Andrew



On Thursday, September 13, 2012 1:46:14 PM UTC+1, badamowicz wrote:
>
> This keeps being weird. Simply thought to wait until Puppet finishes, but 
> had to quit after one and a half hour. Also tried ‘ensure  => present’ 
> instead of ‘ensure  => directory‘ with no success. No log output at all. 
> Still investigating. But any ideas still highly appreciated!
>
>  
>
> Bernd
>
>  
>
> *Von:* puppet...@googlegroups.com  [mailto:
> puppet...@googlegroups.com ] *Im Auftrag von *Bernd Adamowicz
> *Gesendet:* Donnerstag, 13. September 2012 10:46
> *An:* puppet...@googlegroups.com 
> *Betreff:* Re: [Puppet Users] AW: Issue with large directory content
>
>  
>
> Thanks for your answers so far.
>
> But beware that the huge artifacts are *not* managed by Puppet (see recurse 
> => false). Actually it's a Maven repository filled by Nexus. Only the top 
> directory is managed by Puppet to have it in place and have correct access 
> rights. This worked well until I initially filled the repository with the 
> artifacts manually. That slowed down Puppet. Seems to me as Puppet will do 
> some recursive scanning, but that's just an assumption, since Puppet is 
> running with almost 100% CPU load.
>
> I turned debug on in Puppet but will not see anything even after a few 
> minutes. Presumably I would see something if I let Puppet run just long 
> enough. However, it's a strange behaviour I've never experienced. And I 
> think my configuration is OK. 
>
> Bernd
>
> On 09/13/2012 01:24 AM, Peter Brown wrote:
>
> On 13 September 2012 00:12, Christopher Wood 
> wrote:
> > I don't have enough information to say. You might want to run the master 
> and agent in debug mode to get more output, though.
> >
> > puppet agent --debug --verbose --no-daemonize
> >
> > Also, 100 GB? Any particular reason why you're not installing this using 
> a content distribution system or a large number of RPMs?
>
> Recursing through A 100Gb directory will definitely slow down your puppet 
> run.
> If the contents of the directory are reasonably static an RPM would be
> the best idea.
> If it's not static a git or svn repo would be a better idea.
> If you are tricky you can manage the checkouts of git or svn with
> puppet as well.
> I wrote a few tricky resources for this a while ago and they are
> infinitely handy.
>
> >
> > On Wed, Sep 12, 2012 at 04:08:13PM +0200, Bernd Adamowicz wrote:
> >> No ideas at all?
> >>
> >> > -Ursprüngliche Nachricht-
> >> > Von: Bernd Adamowicz
> >> > Gesendet: Dienstag, 11. September 2012 16:16
> >> > An: puppet...@googlegroups.com 
> >> > Betreff: Issue with large directory content
> >> >
> >> > Hi all,
> >> >
> >> > I got this directory configuration:
> >> >
> >> >
> >> >  file {
> >> > "${codebase_ng::repository_mount}/${sonatype_work_dir}":
> >> >  ensure  => directory,
> >> >  owner   => $nexus_user,
> >> >  group   => $nexus_group,
> >> >  mode=> 0755,
> >> >  recurse => false,
> >> >  backup  => false,
> >> >  }
> >> >
> >> > Today I added some 100GB of artifacts to a subdirectory of
> >> > "${codebase_ng::repository_mount}/${sonatype_work_dir}". Now the 
> result
> >> > is that the Puppet seems to run "forever". If I uncomment this code,
> >> > Puppet finishes in 15 seconds. So I presume Puppet is doing some
> >> > recursive scanning of this directory. Could this be true? Is there a
> >> > know issue with large content of directories?
> >> >
> >> > Thanks in advance!
> >> > Bernd
>
>  
>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Puppet Users" group.
> To post to this group, send email to puppet...@googlegroups.com
> .
> To unsubscribe from this group, send email to 
> puppet-users...@googlegroups.com .
> For more option

Re: [Puppet Users] RHEL Kickstart and Puppet certificates

[David Schmitt]

I interpreted that as using hostnames as hardware names and cnames as 
service names, pointing to the h/w the service is running on.



D.

On 13.09.2012 15:58, Nielsen, Steve wrote:

Mike -

Just curious, what do you mean by "using cnames as the maker intended" ? Are 
you suggesting a CNAME per hostname mapping?

Thanks,
Steve



Steve Nielsen  VP, Open Source Engineering  | comScore, Inc.(NASDAQ:SCOR)
o +1 (312) 775-6473 | f +1 (312) 775-6495 | mailto:sniel...@comscore.com
.

Introducing Mobile Metrix 2.0 - The next generation of mobile behavioral 
measurement
www.comscore.com/MobileMetrix
-Original Message-
From: puppet-users@googlegroups.com [mailto:puppet-users@googlegroups.com] On 
Behalf Of Michael Stahnke
Sent: Thursday, September 13, 2012 12:33 AM
To: puppet-users@googlegroups.com
Subject: Re: [Puppet Users] RHEL Kickstart and Puppet certificates

I used to just institute policy that hostnames could not be re-used.
It had a few benefits beyond puppet, like application people not hard-coding 
hostnames and using cnames as the maker intended.

Mike

--
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.



--
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: AW: [Puppet Users] AW: Issue with large directory content

[David Schmitt]

Use strace to take a look at what's really happening. That should make 
it much easier to pinpoint the culprit:



  strace -e file -f puppet agent --test



Best Regards, David

On 13.09.2012 14:44, Bernd Adamowicz wrote:

This keeps being weird. Simply thought to wait until Puppet finishes,
but had to quit after one and a half hour. Also tried ‘ensure  =>
present’ instead of ‘ensure  => directory‘ with no success. No log
output at all. Still investigating. But any ideas still highly appreciated!

Bernd

*Von:*puppet-users@googlegroups.com
[mailto:puppet-users@googlegroups.com] *Im Auftrag von *Bernd Adamowicz
*Gesendet:* Donnerstag, 13. September 2012 10:46
*An:* puppet-users@googlegroups.com
*Betreff:* Re: [Puppet Users] AW: Issue with large directory content

Thanks for your answers so far.

But beware that the huge artifacts are *not* managed by Puppet (see
recurse => false). Actually it's a Maven repository filled by Nexus.
Only the top directory is managed by Puppet to have it in place and have
correct access rights. This worked well until I initially filled the
repository with the artifacts manually. That slowed down Puppet. Seems
to me as Puppet will do some recursive scanning, but that's just an
assumption, since Puppet is running with almost 100% CPU load.

I turned debug on in Puppet but will not see anything even after a few
minutes. Presumably I would see something if I let Puppet run just long
enough. However, it's a strange behaviour I've never experienced. And I
think my configuration is OK.

Bernd

On 09/13/2012 01:24 AM, Peter Brown wrote:

On 13 September 2012 00:12, Christopher Wood
  wrote:
> I don't have enough information to say. You might want to run the master 
and agent in debug mode to get more output, though.
>
> puppet agent --debug --verbose --no-daemonize
>
> Also, 100 GB? Any particular reason why you're not installing this using 
a content distribution system or a large number of RPMs?

Recursing through A 100Gb directory will definitely slow down your
puppet run.
If the contents of the directory are reasonably static an RPM would be
the best idea.
If it's not static a git or svn repo would be a better idea.
If you are tricky you can manage the checkouts of git or svn with
puppet as well.
I wrote a few tricky resources for this a while ago and they are
infinitely handy.

>
> On Wed, Sep 12, 2012 at 04:08:13PM +0200, Bernd Adamowicz wrote:
>> No ideas at all?
>>
>> > -Ursprüngliche Nachricht-
>> > Von: Bernd Adamowicz
>> > Gesendet: Dienstag, 11. September 2012 16:16
>> > An:puppet-users@googlegroups.com 
>> > Betreff: Issue with large directory content
>> >
>> > Hi all,
>> >
>> > I got this directory configuration:
>> >
>> >
>> >  file {
>> > "${codebase_ng::repository_mount}/${sonatype_work_dir}":
>> >  ensure  => directory,
>> >  owner   => $nexus_user,
>> >  group   => $nexus_group,
>> >  mode=> 0755,
>> >  recurse => false,
>> >  backup  => false,
>> >  }
>> >
>> > Today I added some 100GB of artifacts to a subdirectory of
>> > "${codebase_ng::repository_mount}/${sonatype_work_dir}". Now the result
>> > is that the Puppet seems to run "forever". If I uncomment this code,
>> > Puppet finishes in 15 seconds. So I presume Puppet is doing some
>> > recursive scanning of this directory. Could this be true? Is there a
>> > know issue with large content of directories?
>> >
>> > Thanks in advance!
>> > Bernd

--
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.

--
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.


--
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.