[Puppet Users] MCollective in Puppet 6 via the Choria Project

[R.I.Pienaar]

hello,

As you might be aware from messages posted here Puppet Inc have deprecated 
MCollective and it is no longer included in Puppet 6.

For the last 2 years I have been working on a project called The Choria 
Orchestrator that provided an easy to use MCollective build as well as a number 
of additional features and related projects.

We have today released the first release that supports Puppet 6 and I thought 
I'd send a update to the Puppet Users list as it's of specific interest.

This release provides a compatible service that supports most of your old 
MCollective code under a much lighter weight server and broker setup. 
Personally I operate a Choria network of several 100 000 nodes around the 
globe, the Choria technology is much more salable and performant than 
MCollective ever was and it's worth a look if you are a MCollective user. A 
single $40 / month linode can support 10s of thousands of nodes.

Further information about the project can be found on the https://choria.io 
website.  We have a #choria channel on the Puppet Slack and always happy to 
hear from you.

A note about the MCollective code, Puppet Inc have donated the legacy code to 
the Choria Project and we are using this to provide a compatibility layer. To 
have a nice clean break we are preserving archived versions of everything in a 
dedicated GitHub project @ https://github.com/choria-legacy. Thanks a lot to 
the folks at Puppet Inc who worked hard to get this done.

-- 
R.I.Pienaar / www.devco.net / @ripienaar

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/1543670054.1612739.1595307152.7228ACE9%40webmail.messagingengine.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] MCollective security

[R.I.Pienaar]

On Fri, 7 Sep 2018, at 10:58, Sergey Arlashin wrote:
> Hi! 
> 
> Not long ago we started using MCollective to trigger Puppet runs and 
> execute maintenance shell commands on our servers. Everything looks good 
> so far. But I'm concerned about MC security model. 
> 
> For the middleware we are using RabbitMQ. We authenticate MCollective 
> servers against RabbitMQ with username/password pair. Also we have 
> Stunnel for middleware SSL termination. We use Puppet CA signed 
> certificates to verify MCollective servers. 
> 
> However I noticed that an attacker can easily change a hostname on a 
> compromised server. And after that the server will get registered with 
> that hostname. When I execute 
> 
> mco find 
> 
> I see it displayed with the hostname that was recently set. And the 
> hostname can be equal to any of the existing servers.
> 
> That means that if I execute a shell command via 
> 
> mco shell run -I "/existinghostnamemask/" "command" 
> 
> it will be also executed on the compromised server. The server can get 
> sensitive data that it is not supposed to have.
> 
> I hope I explained everything correctly :) 
> 
> So my question is - is there a way to avoid situations like the one I 
> described? For example if I use SSH to connect to a host, I get its 
> public key, and if the host changes, I receive an error. But probably 
> there is something like this for MCollective? 

You should use choria.io to deploy mcollective, mcollective as you deployed do 
have ways to restrict access and harden the security model - but its a LOT of 
work to setup.

Choria does all of this for you, nodes use their puppet certificates.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/1536311776.908972.1499976648.3FEAE11E%40webmail.messagingengine.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: New Deferred type and agent data lookups in Puppet 6

[R.I.Pienaar]

On Fri, 31 Aug 2018, at 17:41, Chadwick Banning wrote:
> So for this example, there are some sort of limitations as to what the
> 'vault_lookup' function is able to do internally? I had just assumed that
> as long as the function returned a simple value, what the function does
> internally was open.
> 
> As an example, could Deferred be used to read and extract a value from a
> file agent-side?
> 

The function can do whatever it wants but needs to return a value and that 
value has to be used by a resource and not mixed in with some other strings 
etc. In my example deferred as the entire value to a resource property is good, 
deferred and then any derived data from it wont work.

You cant for example, as far as I understand it, have the function lookup a 
piece of data and then use that data in a template via template() and epp().  
Those are processed entirely on the master.


> On Fri, Aug 31, 2018 at 9:12 AM R.I.Pienaar  wrote:
> 
> >
> >
> > On Fri, 31 Aug 2018, at 15:03, Chadwick Banning wrote:
> > > Would it be safe to consider this in a general context i.e. as enabling
> > > agent-side function execution?
> >
> > I dont think so - for general function calls to be usable you want to get
> > the value and then do some conditional logic on it.  or put it in a
> > variable and use it in another resource etc.
> >
> > That is not what this is for, this is a based placeholder to later be
> > replaced by the value - you cannot do any conditionals etc with it.
> >
> > Imagine something like:
> >
> > mysql::user{"bob":
> >   password => Deferred(vault_lookup, "bob_pass")
> > }
> >
> > (I am just making this syntax up, this is presumably not how it will look)
> >
> > Here its fine because its a simple interpolation into a value, you cant do
> > more complex things with this design.
> >
> > Anyway thats my understanding, Henrik might chime in too
> >
> > --
> > You received this message because you are subscribed to a topic in the
> > Google Groups "Puppet Users" group.
> > To unsubscribe from this topic, visit
> > https://groups.google.com/d/topic/puppet-users/DurqiLnVWMk/unsubscribe.
> > To unsubscribe from this group and all its topics, send an email to
> > puppet-users+unsubscr...@googlegroups.com.
> > To view this discussion on the web visit
> > https://groups.google.com/d/msgid/puppet-users/1535721137.3301091.1492516568.3EB7087A%40webmail.messagingengine.com
> > .
> > For more options, visit https://groups.google.com/d/optout.
> >
> 
> 
> -- 
> Chadwick Banning
> 
> -- 
> You received this message because you are subscribed to the Google 
> Groups "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send 
> an email to puppet-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/puppet-users/CAPwwW9GmasAV7Yz98Nq4YawYoehCuxK_JpH5iTj7sAKMRXeHXw%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.


-- 
R.I.Pienaar / www.devco.net / @ripienaar

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/1535732928.73238.1492735792.074DDD75%40webmail.messagingengine.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: New Deferred type and agent data lookups in Puppet 6

[R.I.Pienaar]

On Fri, 31 Aug 2018, at 15:03, Chadwick Banning wrote:
> Would it be safe to consider this in a general context i.e. as enabling 
> agent-side function execution?

I dont think so - for general function calls to be usable you want to get the 
value and then do some conditional logic on it.  or put it in a variable and 
use it in another resource etc.

That is not what this is for, this is a based placeholder to later be replaced 
by the value - you cannot do any conditionals etc with it.

Imagine something like:

mysql::user{"bob":
  password => Deferred(vault_lookup, "bob_pass")
}

(I am just making this syntax up, this is presumably not how it will look)

Here its fine because its a simple interpolation into a value, you cant do more 
complex things with this design.

Anyway thats my understanding, Henrik might chime in too

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/1535721137.3301091.1492516568.3EB7087A%40webmail.messagingengine.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Style (syntax?) question

[R.I.Pienaar]

On Tue, 5 Jun 2018, at 15:01, jcbollinger wrote:
> 
> 
> On Monday, June 4, 2018 at 1:06:52 PM UTC-5, Ramin K wrote:
> >
> > On 6/4/18 8:25 AM, Peter Berghold wrote: 
> > > I was looking at someone else's code one day last week and saw a pattern 
> > > I've not seen before. Maybe that's what I get for developing Puppet code 
> > > in a vacuum. :-) 
> > > 
> > > class someclass ( 
> > >  $parm1 = $::someclass::params::parm1, 
> > >  $parm2 = $::someclass::params::parm2   # so far I get it. 
> > > ) inherits someclass::params { # ok, I get it 
> > > 
> > >   class{'someclass::package': }# OK 
> > >   -> class('someclass::configure':}# right... 
> > >   -> Class{'someclass':}#  HUH?  What does that 
> > do? 
> > > } 
> > > 
> > > Is that last step necessary and why? 
> >
> >
> > The last step was fairly common in Puppet 2.7 code before Anchors.
> 
> 
> 
> Are you sure about that, Ramin?  I've been around Puppet since well before 
> v2.7, and to the best of my knowledge, Class{'someclass':} (with capital 
> 'C') is and always has been syntactically invalid.  I'm prepared to learn 
> something new today, but you'll need to point me to some docs to support 
> your assertion.
> 
> Myself, I'm inclined to guess that it's a simple typo, that an ordinary 
> resource-style class declaration (with lowercase 'c') is what was intended.
> 

class{'someclass::package': } 
-> class('someclass::configure':}
-> Class["someclass"] # or -> Class[$name]

Is the correct version of this.  It's a "soft" version of the anchor pattern, 
because:

   package{"foo": require => Class["someclass"]}

will have the inner classes completed before it without any crazy extra 
resources and stuff and it handles the case most people actually care for - but 
this is not a full contained class like contain() makes, you should probably 
use contain() today.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/1528204221.2225351.1397064328.7404B769%40webmail.messagingengine.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] agent_catalog_run.lock

[R.I.Pienaar]

On Wed, 23 May 2018, at 15:16, Jason McMahan wrote:
> Has anyone else run into the problem where an agent run gets stuck per say?
> We have found at times the agent runs could be stuck for multiple days.
> 
> I was trying to come up with an option that would automatically stop the 
> agent run if it lasted over 24 hrs per say so we dont have to go back to 
> servers and remove the lock file.
> 
> Anyone else have ideas or suggestions?
> 
> Usually when it occurs we remove the lock file perform a run and all is 
> well, it is just getting to however many that are affected in a timely 
> manner and clearing the lock.

try setting runtimeout=1000 where 1000 is seconds you want to give it as a max 
run

-- 
R.I.Pienaar / www.devco.net / @ripienaar

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/1527083182.4012028.1382092312.1771D51F%40webmail.messagingengine.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Puppet 5 requires stdlib for templates?

[R.I.Pienaar]

On Fri, 4 May 2018, at 21:21, Joaquin Menchaca wrote:
> Playing catch-up from Puppet 3 days to Puppet 5.
> 
> I noticed that I can no longer to templates w/o puppet-stdlib installed?  
>  Was this a design decision (feature) or a bug?

it's not required. what is the problem you're having?



-- 
R.I.Pienaar / www.devco.net / @ripienaar

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/1525462218.3384994.1361260320.06E1019E%40webmail.messagingengine.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: How to Orchestrate State, such as use IPs of new systems for config other systems

[R.I.Pienaar]

 > puppetdb? hiera?  The docs are not all that intuitive (had to step 
> >> > through gem source code to discern how to use ssh transport for my 
> >> > environment). 
> >>
> >> Have a look at https://choria.io/docs/playbooks/basics/ . Like Bolt it 
> >> can run puppet tasks, but you can also write whole plans in the puppet 
> >> language to orchestrate a cluster. 
> >>
> >> It is super easy to setup with the modules provided and is based on 
> >> mcollective which already comes with the puppet AIO package. 
> >>
> >> Regards 
> >> Andreas 
> >>
> > -- 
> > You received this message because you are subscribed to the Google Groups 
> > "Puppet Users" group.
> > To unsubscribe from this group and stop receiving emails from it, send an 
> > email to puppet-users...@googlegroups.com .
> > To view this discussion on the web visit 
> > https://groups.google.com/d/msgid/puppet-users/f5610774-cdd4-4dc6-ab7d-31839f945943%40googlegroups.com
> >  
> > <https://groups.google.com/d/msgid/puppet-users/f5610774-cdd4-4dc6-ab7d-31839f945943%40googlegroups.com?utm_medium=email_source=footer>
> > .
> > For more options, visit https://groups.google.com/d/optout.
> >
> >
> 
> -- 
> You received this message because you are subscribed to the Google 
> Groups "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send 
> an email to puppet-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/puppet-users/361ecaa7-8122-492a-8347-faf117d930ca%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.


-- 
R.I.Pienaar / www.devco.net / @ripienaar

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/1525208664.2484405.1357390408.1A9D3385%40webmail.messagingengine.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: How to Orchestrate State, such as use IPs of new systems for config other systems

[R.I.Pienaar]

On Tue, 1 May 2018, at 17:18, John Gelnaw wrote:
> On Friday, April 27, 2018 at 9:31:24 PM UTC-4, Joaquin Menchaca wrote:
> >
> > Hello Puppeteers,
> >
> > Relearning Puppet (converting Ansible, Chef knowledge), not sure best 
> > approach for this.  How can I configure systems based on state of another 
> > system?   Essentially, I would use a tool like Terraform to bring up 
> > systems.  When their IP addresses are available, I would then use that 
> > information (their IP address) to configure other systems.
> >
> > I have two simple use cases:
> >
> >1. local repository, and if up and available, want to configure all 
> >clients, e.g. java clients, to use this system (such as /etc/hosts with 
> >download.oracle.com)
> >2. elastic search cluster where the elasticsearch.yml has ip addresses 
> >of all nodes within the cluster.
> >
> >
> An ENC that queries puppetdb would work.  In theory, you could also query 
> something like mcollective-- but as the devs say, that's in kind of a shaky 
> state.
> 
> What *is* the status of choria?  I've been using mcollective for a long 
> time-- it's auto-deployed on all of my puppet nodes and in my environment 
> "just works", so I've been reluctant to yank out a system that works and 
> replace it with something that's under heavy development, but obviously, I 
> can't stay on the mcollective path forever (btw - this is the first I've 
> heard it's been dropped from Puppet 6, although I haven't been following 
> puppet 6 development closely). 
> 

see the other mail I posted on this thread about choria, happy to answer 
questions.

short version you'll be able to continue as you were.

I don't think there's been official at-length communications about this in 
Puppet 6 but see mails from Eric recently on this list mentioning it etc

> -- 
> You received this message because you are subscribed to the Google 
> Groups "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send 
> an email to puppet-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/puppet-users/61e82c03-327b-4b8e-adeb-8c764dde64d0%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.


-- 
R.I.Pienaar / www.devco.net / @ripienaar

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/1525192541.2386290.1357096032.771AB7B4%40webmail.messagingengine.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] converting Hiera v3 to v5 - :merge_behavior: deeper option?

[R.I.Pienaar]

On Fri, 27 Apr 2018, at 17:34, du wrote:
> 
> 
> Hi
> 
> I am in the process of migrating v3 hiera.yaml to v5 and I would like all 
> hash merges to merge 'deep' by default, the same way :merge_behavior: 
> deeper in v3 parameter provides.
> 
> 
> I can't seem to find an easy way to do this after reading the docs - I 
> understand lookup_options: need to be set, however it requires class 
> parameter to be specified. I tried using regex as below and adding it to 
> common.yaml however it does not produce the desired result (it works ok if 
> I specify the hash name explicitly, however I am looking to expand this 
> behaviour to all lookups, if possible).
> 
> 
> Is there an easy way to just migrate :merge_behavior: deeper to v5?

It's not there because its the way it works, there's no other option and 
nothing to enable.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/1524847763.1311025.1353120896.2D5F8539%40webmail.messagingengine.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: custom facts

[R.I.Pienaar]

On Wed, 25 Apr 2018, at 19:05, Michael Di Domenico wrote:
> >> >
> >> > Perhaps something like this then, though that answer is old, in theory
> >> > it
> >> > should probably work for new Puppet:
> >> >
> >> > https://ask.puppet.com/question/4645/puppet-apply-and-pluginsync/
> >> >
> >>
> >> In recent Puppet with puppet apply it automatically finds facts in your
> >> modules, you dont need to copy them anywhere or sync them.
> >>
> >> I have not really been following this thread sorry if that's not helpful -
> >> but it basically just works
> >
> > I think the RP is trying to run Facter standalone on the command line, as he
> > mentions FACTERLIB, but yes, "puppet apply" should just work as is.
> 
> yes, that is true.  i want both facter and puppet to be able to find
> my custom facts without having to specify an environment variable.
> 
> thanks for suggestions so far, i'll poke at them and see if something
> fits the bill
> 

Facter on it's own can't I believe, you have to use puppet facts then you will 
get facts from modules - but beware the slightly different format.


-- 
R.I.Pienaar / www.devco.net / @ripienaar

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/1524677188.3836288.1350590520.7354DA1B%40webmail.messagingengine.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: custom facts

[R.I.Pienaar]

On Wed, 25 Apr 2018, at 17:52, Luke Bigum wrote:
> On Wednesday, 25 April 2018 15:18:13 UTC+1, Michael Di Domenico wrote:
> >
> > On Wed, Apr 25, 2018 at 10:14 AM, Luke Bigum <luke@lmax.com 
> > > wrote: 
> > > On Wednesday, 25 April 2018 15:01:00 UTC+1, Michael Di Domenico wrote: 
> > >> 
> > >> in the past i'd copy my ruby facts into 
> > >> /usr/share/ruby/vendor_ruby_facter (which probably wasnt right) 
> > > 
> > > 
> > > No... That's definitely not right :-)  Puppet has had a feature called 
> > > "pluginsync" for a while now, which downloads ruby code (types, 
> > providers, 
> > > facts) from a Puppet Master before it does anything on a Puppet Agent. 
> >  The 
> > > Agent will write it's downloaded Ruby code into /var/lib/puppet/lib/ 
> > > (/opt/puppetlabs/puppet/cache/lib in Puppet 5), and it will keep it 
> > > synchronised so you can't pollute it. 
> >
> > we're using puppet in standalone mode, not server/client. 
> >
> 
> Perhaps something like this then, though that answer is old, in theory it 
> should probably work for new Puppet:
> 
> https://ask.puppet.com/question/4645/puppet-apply-and-pluginsync/ 
> 

In recent Puppet with puppet apply it automatically finds facts in your 
modules, you dont need to copy them anywhere or sync them.

I have not really been following this thread sorry if that's not helpful - but 
it basically just works

-- 
R.I.Pienaar / www.devco.net / @ripienaar

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/1524671882.3806645.1350479616.109AD328%40webmail.messagingengine.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Announcing Choria Tasks Runner

[R.I.Pienaar]

hello,

Another mail about some Puppet related Choria feature, 

I recently released a system for open source users that can execute Puppet 
Tasks without Bolt and SSH. These tasks are run subject to strong RBAC and 
Auditing. 

It's part of the Choria project which is a continuation of MCollective.

You can read more in the docs: https://choria.io/docs/tasks/

-- 
R.I.Pienaar / www.devco.net / @ripienaar

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/1521740511.1311695.1312604048.1865CE9C%40webmail.messagingengine.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Choria Playbooks using Puppet DSL

[R.I.Pienaar]

hello,

I don't post here that often about Choria - a continuation of the MCollective 
project - but this time there is something of particular interest to Puppet 
users though I thought I'd drop a note.

You can now write Playbooks that integrate tools such as consul, etcd, 
terraform, Slack, graphite, PuppetDB PQL, MCollective and more all into one.  

You can use these to solve orchestration problems, you can make a collection of 
them and share them with your team or the community at large and more.

The official docs are here: https://choria.io/docs/playbooks/
I blogged about it here: 
https://www.devco.net/archives/2018/02/25/choria-playbooks-dsl.php

And below I'll put a sample for you to see

# Disables Puppet and Wait for all in-progress catalog compiles to end
plan acme::disable_puppet_and_wait (
  Enum[alpha, bravo] $cluster
) {
  choria::run_playbook(acme::slack_notify, message => "Disabling Puppet in 
cluster ${cluster}")
 
  $puppet_agents = choria::discover("mcollective",
discovery_method => "choria",
agents => ["puppet"],
facts => ["cluster=${cluster}"],
uses => { puppet => ">= 1.13.1" }
  )
 
  $ds = {
"type" => "consul",
"timeout" => 120,
"ttl" => 60
  }
 
  choria::lock("locks/puppet.critical", $ds) || {
choria::task(
  "action" => "puppet.disable",
  "nodes" => $puppet_agents,
  "fail_ok" => true,
  "silent" => true,
  "properties" => {"message" => "restarting puppet server"}
)
 
choria::task(
  "action"=> "puppet.status",
  "nodes" => $puppet_agents,
  "assert"=> "idling=true",
  "tries" => 10,
  "silent"=> true,
  "try_sleep" => 20,
)
  }
 
  choria::run_playbook(acme::slack_notify,
message => sprintf("Puppet disabled on %d nodes in cluster %s", 
$puppet_agents.count, $cluster)
  )
}

-- 
R.I.Pienaar / www.devco.net / @ripienaar

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/1519570681.3148398.1282669136.75F8CE85%40webmail.messagingengine.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Puppet 5 Stdlib IP address parsing

[R.I.Pienaar]

On Thu, 15 Feb 2018, at 14:50, John Baird wrote:
> R.I,
> 
> Can you point me to some docs on exactly how to use those?  I have looked 
> and I only see references to using them, but not how to actually use them 
> within a manifest for validation.  Any places you can point me to would be 
> much appreciated!

class thing(
  Stdlib::Compat::Ipv4 $ipaddress
) {

}

this is how you tell it the class param has to be a ipv4, any attempt to pass 
anything else is a compile error

https://puppet.com/docs/puppet/5.3/lang_data_type.html

> 
> Also, thanks for all of the useful modules you have written over the years, 
> I recognized your name instantly!  Thanks for getting back to me!
> 
> John Baird
> 
> On Thursday, February 15, 2018 at 12:19:30 AM UTC-6, R.I. Pienaar wrote:
> >
> > Use the Stdlib::Compat::Ipv4, ::Ipv6 and ::Ip_address data types 
> >
> > ---
> > R.I.Pienaar
> >
> > On 15 Feb 2018, at 01:41, John Baird <john.w...@gmail.com > 
> > wrote:
> >
> >
> > According to the stdlib docs, "is_ip_address" is deprecated.  There is no 
> > mention of how to replace it without using "validate_legacy" which itself 
> > will ultimately be deprecated.
> >
> > Is there a better/proper approach to validating IPv4 and/or IPv6 syntax 
> > with Puppet 5 ?
> > `
> > is_ip_address
> >
> > *Deprecated. Will be removed in a future version of stdlib. 
> > See validate_legacy 
> > <https://forge.puppet.com/puppetlabs/stdlib#validate_legacy>.*
> >
> > Returns true if the string passed to this function is a valid IP address.
> >
> > *Type*: rvalue.
> >
> > `
> >
> > -- 
> > You received this message because you are subscribed to the Google Groups 
> > "Puppet Users" group.
> > To unsubscribe from this group and stop receiving emails from it, send an 
> > email to puppet-users...@googlegroups.com .
> > To view this discussion on the web visit 
> > https://groups.google.com/d/msgid/puppet-users/3275659c-d7c0-487f-979b-8e62da5a3cd1%40googlegroups.com
> >  
> > <https://groups.google.com/d/msgid/puppet-users/3275659c-d7c0-487f-979b-8e62da5a3cd1%40googlegroups.com?utm_medium=email_source=footer>
> > .
> > For more options, visit https://groups.google.com/d/optout.
> >
> >
> 
> -- 
> You received this message because you are subscribed to the Google 
> Groups "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send 
> an email to puppet-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/puppet-users/273e4a69-f25a-4261-8bfd-25ff8cc74d6e%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.


-- 
R.I.Pienaar / www.devco.net / @ripienaar

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/1518703305.2380977.1271878208.0F44E8DE%40webmail.messagingengine.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: 'require' option is ignored?

[R.I.Pienaar]

On Thu, 15 Feb 2018, at 11:41, buoyant_puppy wrote:
> I think I got this. My main issue was the 'true' logic with an 'onlyif', 
> because that's always only going to either run (= and therefore meet the 
> requirement) or not run at all (= which also meets the requirement since 
> it's not a failure).
> 
> I feel the choice of words here leaves room for confusion. Like "unless"... 
> unless succeeds? unless fails? "requires" also leaves some amgiuity as 

"unless this thing is true" seems clear to me, also in line with how ruby works 
and also puppet

  if $thing { }
  unless $thing { }


> well, since it considers the requirement met as long as the required 
> resource did not explicitly return a failure. So "notrun" is just as good 
> as success, which to me doesn't really intuitively match what I think 
> "require" means.

require means the required resource is in the desired start.  Your desired 
state is not to run at certain times, the desired behavior was reached so the 
resource is in pass state.  require is a generic meta param that applies to all 
resources - it does not know the particulars of what you think a certain 
resource is doing, its at a higher level.

> 
> Here's a set of tests that illustrate all this more clearly, in case it 
> helps someone else that stumbles on this post:
>   exec { "test1": command => "/bin/false", unless => "/bin/true" }  # 
> unless = only if this fails
>   notify { "false, unless true fails, which it wont: this should not fail 
> (notrun) and i should see this": require => Exec["test1"] }
>   exec { "test2": command => "/bin/false", onlyif => "/bin/true" }   # 
> onlyif = only if this returns true
>   notify { "false, but only if true: this should fail and i should not see 
> this": require => Exec["test2"] }
>   exec { "test3": command => "/bin/true", unless => "/bin/true" } # unless 
> = only if this fails
>   notify { "true, unless true fails, which it wont: this should not run 
> true (notrun) and i should see this": require => Exec["test3"] }
>   exec { "test4": command => "/bin/true", onlyif => "/bin/false" } # onlyif 
> = only if this returns true
>   notify { "true, but only if false returns true, which it wont: true will 
> be run and i should see this": require => Exec["test4"] }
> 
> 
> -- 
> You received this message because you are subscribed to the Google 
> Groups "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send 
> an email to puppet-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/puppet-users/e9c2a7a4-148b-4337-aba7-acf308e7cbe0%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.


-- 
R.I.Pienaar / www.devco.net / @ripienaar

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/1518692076.866186.1271713656.324BD46F%40webmail.messagingengine.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Puppet 4 EOL?

[R.I.Pienaar]

On Mon, 12 Feb 2018, at 17:43, Sven vd wrote:
> Hi,
> 
> Currently our infrastructure and code is written with and run by puppet 4 
> opensource.
> 
> We are using https://yum.puppetlabs.com/el/7/PC1/x86_64/ repos for updates 
> of our installed software, puppetserver, puppetdb, puppet agent.
> 
> Since puppet 5 was released the puppet 5 packages shifted to another repo 
> https://yum.puppetlabs.com/puppet/el/7/x86_64/. We are not using this repo 
> since we are currently on puppet 4 codebase.
> 
> So the question is, how long will the 
> https://yum.puppetlabs.com/el/7/PC1/x86_64/  repo get updates (security 
> fixed, improvements etc) and when is open source puppet 4 considered End Of 
> Life?


if you look at the Puppet Enterprise support cycle and figure out which is the 
last one with Puppet 4 then you will know when 4 will be EOL.  If I read it 
right it looks to be around July 2018.

Upgrade to Puppet 5 from 4 is pretty trivial, so should be easy for you to 
follow along.

-- 
R.I.Pienaar / www.devco.net / @ripienaar

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/1518455707.2368530.1268211688.6F454C24%40webmail.messagingengine.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Puppet Agent Hang when PuppetServer Crashes...

[R.I.Pienaar]

On Mon, 1 Jan 2018, at 23:51, Matt Wise wrote:
> *Puppet Agent: 5.3.2*
> *Puppet Server: 5.1.4 - Packaged in Docker, running on Amazon ECS*
> 
> So we've recently started rolling over from our ancient Puppet 3.x system
> to a new Puppet 5.x service. The new service consists of a PuppetServer
> Docker Image (5.1.4) running in Amazon ECS, and our hosts booting up and
> running Puppet Agent 5.3.2. At this point in the migration, we're running
> ~150-200 hosts on the new Puppet5 system and we replace ~30-80 of them
> daily.
> 
> We are currently tracking down a problem with our PuppetServers and their
> memory usage, which is causing the containers to be OOM'd a few times a day
> (~10 OOMs a day across ~20 containers). While we know that we need to fix
> this, we've seen a scary behavior on the Puppet Agent side that we could
> use some advice with.
> 
> It seems that at least a few times a day now we will get a server hung in
> the boot process. The `puppet agent -t ...` process will just hang midway
> through the run. It seems that these hangs happen when the backend
> underlying PuppetServer process that they were connected to gets OOMed and
> goes away. Obviously the OOM is a problem.. but frankly I am more concerned
> with the Puppet Agent getting wedged for hours and hours without making any
> progress.
> 
> It seems that when this failure happens, the puppet agent does not ever
> time out. It never fails, or throws an error. It just hangs. We've had
> these hangs last upwards of 4-5 hours before our systems are automatically
> terminated.
> 
> We've enabled debug logging, but haven't caught one of these failures yet
> with debug mode turned on. In the mean time, are there any  known
> regressions or configuration tweaks we need to make to Puppet Agent 5.x
> more quick to fail or resilient in this case? I could obviously try to
> build in some wrapper around Puppet to catch this behavior .. but I am
> hoping that there are just some settings we need to tweak.

I see this often for other kinds of interruptions like network interruptions etc

I do recall a number of bugs around this to make it more robust, you might want 
to try searching Puppet jita 


-- 
R.I.Pienaar / www.devco.net / @ripienaar

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/1514847264.1185405.1221159992.28D2AE6B%40webmail.messagingengine.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Can puppet master and agent communicate with certificates

[R.I.Pienaar]

On Fri, 15 Dec 2017, at 14:22, Harish Kothuri wrote:
> Hi,
> 
> Is there a way, we can disable puppet CA completely and have PM and PA 
> communicates seamlessly?

no, thankfully.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/1513344202.4096117.1206136288.064B5B5B%40webmail.messagingengine.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Differences between Resource Defaults statement and per block default?

[R.I.Pienaar]

On Wed, 13 Dec 2017, at 18:00, Henrik Lindberg wrote:
> On 13/12/17 17:40, R.I.Pienaar wrote:
> > 
> > 
> > On Wed, 13 Dec 2017, at 16:31, Henrik Lindberg wrote:
> >> On 13/12/17 14:46, Tobias Koeck wrote:
> >>> Hi,
> >>>
> >>> I am wondering what the difference between a Resource Default statement 
> >>> like
> >>>
> >>> |Exec { path => '/usr/bin:/bin:/usr/sbin:/sbin', environment =>
> >>> 'RUBYLIB=/opt/puppetlabs/puppet/lib/ruby/site_ruby/2.1.0/', logoutput =>
> >>> true, timeout => 180, }
> >>>
> >>>
> >>
> >> What the others said is not quite accurate.
> >>
> >> This sets the defaults for all Exec resources that are declared in the
> >> same scope, or in any scope that is included from this scope. This is
> >> known as Dynamic Scoping and it is a horribly bad idea that is removed
> >> from modern puppet for everything except Resource Defaults (what the
> >> example construct is known as). The less you use this the better.
> > 
> > There's been a very unfortunate puppet 5 behaviour change here:
> > 
> >class bar {
> >  notify{"three": }
> >}
> > 
> >class foo {
> >  include bar
> > 
> >  notify{"one": }
> >  Notify{message => "default"}
> >  notify{"two": }
> >}
> > 
> >include foo
> > 
> > In 4 this would do as you say, both would use "default", but in 5...
> > 
> >Notice: three
> >Notice: /Stage[main]/Bar/Notify[three]/message: defined 'message' as
> >'three'
> >Notice: one
> >Notice: /Stage[main]/Foo/Notify[one]/message: defined 'message' as
> >'one'
> >Notice: default
> >Notice: /Stage[main]/Foo/Notify[two]/message: defined 'message' as
> >'default'
> > 
> > The positioning of the 'include' here would also change the behavior of
> > the 'three' resource
> > 
> > Bug or feature? Don't care personally, no-one should use this awful
> > feature.
> > 
> > Though I thought we killed the dynamic scope stuff wrt this :(
> > 
> 
> Unfortunately that was not a deliberate change. It just means that the 
> testing for how defaults are supposed to work has holes in it.
> I don't want it back though, and we have no error reports regarding 
> this. I hope it stays that way and that we can drop the resource 
> defaults or make them sane.


came up a few times in slack and irc, selfishly did not ask for them to
make tickets :P

-- 
R.I.Pienaar / www.devco.net / @ripienaar

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/1513184517.2613426.1203935400.25E60754%40webmail.messagingengine.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Differences between Resource Defaults statement and per block default?

[R.I.Pienaar]

On Wed, 13 Dec 2017, at 16:31, Henrik Lindberg wrote:
> On 13/12/17 14:46, Tobias Koeck wrote:
> > Hi,
> > 
> > I am wondering what the difference between a Resource Default statement like
> > 
> > |Exec { path => '/usr/bin:/bin:/usr/sbin:/sbin', environment => 
> > 'RUBYLIB=/opt/puppetlabs/puppet/lib/ruby/site_ruby/2.1.0/', logoutput => 
> > true, timeout => 180, }
> > 
> > 
> 
> What the others said is not quite accurate.
> 
> This sets the defaults for all Exec resources that are declared in the 
> same scope, or in any scope that is included from this scope. This is 
> known as Dynamic Scoping and it is a horribly bad idea that is removed 
> from modern puppet for everything except Resource Defaults (what the 
> example construct is known as). The less you use this the better.

There's been a very unfortunate puppet 5 behaviour change here:

  class bar {
notify{"three": }
  }

  class foo {
include bar 

notify{"one": }
Notify{message => "default"}
notify{"two": }
  }

  include foo

In 4 this would do as you say, both would use "default", but in 5...

  Notice: three
  Notice: /Stage[main]/Bar/Notify[three]/message: defined 'message' as
  'three'
  Notice: one
  Notice: /Stage[main]/Foo/Notify[one]/message: defined 'message' as
  'one'
  Notice: default
  Notice: /Stage[main]/Foo/Notify[two]/message: defined 'message' as
  'default'

The positioning of the 'include' here would also change the behavior of
the 'three' resource

Bug or feature? Don't care personally, no-one should use this awful
feature.

Though I thought we killed the dynamic scope stuff wrt this :(

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/1513183247.2607269.1203904840.1545BF04%40webmail.messagingengine.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Differences between Resource Defaults statement and per block default?

[R.I.Pienaar]

On Wed, 13 Dec 2017, at 14:46, Tobias Koeck wrote:
> Hi,
> 
> I am wondering what the difference between a Resource Default statement
> like
> 
> Exec {
>   path=> '/usr/bin:/bin:/usr/sbin:/sbin',
>   environment =>
>   'RUBYLIB=/opt/puppetlabs/puppet/lib/ruby/site_ruby/2.1.0/',
>   logoutput   => true,
>   timeout => 180,
> }
> 

this one applies to all execs in the code below it

> and
> 
> using a per block default like described in
> 
> https://puppet.com/docs/puppet/5.3/lang_data_default.html#per-block-resource-defaults

this one applies only to the resources in the group.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/1513177516.2339411.1203793960.3D3770D2%40webmail.messagingengine.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] loadjson reads from the master

[R.I.Pienaar]

On Fri, 1 Dec 2017, at 16:53, buoyant_puppy wrote:
> I'm trying to pull data from my cmdb into a variable, by downloading my 
> relevant data to a local json file and reading it in:
>   
> class get_cmdb {
>   file { "/tmp/${::hostname}.json":
> source => "http://mycmdb.example.com/${::hostname};
>   }
>   $mydata = loadjson("/tmp/${::hostname}.json")
> 
> The issue that the file in the first step is created on the agent, but
> the 
> loadjson attempts to read the file on the master.
> 
> How can I either read the file on the agent instead, or vice versa, fetch 
> the file on the master?
> 

All functions like foo() run on the master during compile.  It's a multi
phase process, the only way a node can influence the compile time is
using facts.

You could integrate your CMDB with puppet using a hiera data function
that could exist as a tier in your hierarchy

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/1512147574.2941891.1190871648.10BE647C%40webmail.messagingengine.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Question on searching for and using data inside a structured fact

[R.I.Pienaar]

nothing wrong with keys() but...

function uuid_for_partition($needle) {
  $uuid = $facts["partitions"].reduce() |$memo, $partition| {
$partition[1]["mount"] ? {
  $needle => $partition[0],
  default => $memo
}
  }
}

notice(uuid_for_partition("/boot"))


On Thu, Nov 9, 2017, at 00:54, Sean wrote:
> Hi,
> 
> I have been attempting (and failing miserably) at trying to obtain the
> UUID 
> of a partition mounted in a specific directory from the partitions fact.  
> I'm using puppet 4.10.8.
> 
> As an example, let's say I'm looking for the UUID of /boot on my
> systems...
> 
> $ facter partitions
> {"sda1"=>{"size"=>"1048576", "mount"=>"/boot/efi"}, 
> "sda2"=>{"uuid"=>"14528e73-61cc-4503-b24f-47c3b6e2aee2",
> "size"=>"1048576", 
> "mount"=>"/boot"},
> "sda3"=>{"uuid"=>"c0f0fa3e-b389-4814-ae8b-dec3b14816fb", 
> "size"=>"974673920"}}
> 
> I can successfully use the filter function to find the sda2 hash in
> puppet:
> 
> $x = $facts['partitions'].filter |$p,$d| { $d['mount' == '/boot' }
> $k = keys($x)
> $u = $x[k[0]]['uuid']
> notify { "$u": }
> 
> 
> This produces the desired resulting data, a string with the UUID, but it 
> requires using puppetlabs-stdlib's keys function.  So, is there a way to 
> accomplish this with native puppet alone?
> 
> Thanks you kindly.
> 
> -- 
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/fa9679ba-72a4-4ba2-8cbf-a1695cdefa8a%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.


-- 
R.I.Pienaar / www.devco.net / @ripienaar

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/1510213415.3457730.118944.2FE14A60%40webmail.messagingengine.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] After mcollective update agent does not work anymore

[R.I.Pienaar]

On Fri, Oct 20, 2017, at 14:22, Andreas Dvorak wrote:
> pr0cess is installed. The older mcollective works fine with that
> location.
> 
> >rpm -ql ruby-pr0cess
> /usr/lib/ruby/site_ruby/1.8
> /usr/lib64/ruby/site_ruby/1.8/x86_64-linux
> /usr/lib64/ruby/site_ruby/1.8/x86_64-linux/pr0cess.so
> 
> Do you know how to configure the location to the file or should I be it
> to 
> an other place?

It depends on your ruby that is running mcollective, find the exact path
to the ruby binary and run:

  ruby -e 'p $:'

and see if the place this file is matches where its looking, you can
also just try:

  ruby -r pr0cess -e 'puts "hello"'

but be sure to use the same ruby path mcollective use

-- 
R.I.Pienaar / www.devco.net / @ripienaar

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/1508503547.2659406.1145350280.46A7BC15%40webmail.messagingengine.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] After mcollective update agent does not work anymore

[R.I.Pienaar]

The problem appears to be:

cannot load such file -- pr0cess

there's some dependency like a gem that is not found in this
installation of puppet

On Thu, Oct 19, 2017, at 13:25, Andreas Dvorak wrote:
> Hi,
> 
> thank you. That is a good tip. The log says:
> 
> D, [2017-10-19T12:50:04.972364 #13809] DEBUG -- : agents.rb:104:in `block 
> in findagentfile' Found ehyp at 
> /usr/libexec/mcollective/mcollective/agent/ehyp.rb
> D, [2017-10-19T12:50:04.972530 #13809] DEBUG -- : pluginmanager.rb:167:in 
> `loadclass' Loading MCollective::Agent::Ehyp from
> mcollective/agent/ehyp.rb
> D, [2017-10-19T12:50:04.974482 #13809] DEBUG -- : pluginmanager.rb:167:in 
> `loadclass' Loading MCollective::Util::UnprivilegedAgent from 
> mcollective/util/unprivilegedagent.rb
> E, [2017-10-19T12:50:04.976625 #13809] ERROR -- : pluginmanager.rb:171:in 
> `rescue in loadclass' Failed to load
> MCollective::Util::UnprivilegedAgent: 
> cannot load such file -- pr0cess
> E, [2017-10-19T12:50:04.976730 #13809] ERROR -- : pluginmanager.rb:171:in 
> `rescue in loadclass' Failed to load MCollective::Agent::Ehyp: cannot
> load 
> such file -- pr0cess
> E, [2017-10-19T12:50:04.976815 #13809] ERROR -- : agents.rb:71:in `rescue 
> in loadagent' Loading agent ehyp failed: cannot load such file -- pr0cess
> D, [2017-10-19T12:50:04.976978 #13809] DEBUG -- : agents.rb:104:in `block 
> in findagentfile' Found ehyp at 
> /usr/libexec/mcollective/mcollective/agent/ehyp.rb
> D, [2017-10-19T12:50:04.977093 #13809] DEBUG -- : pluginmanager.rb:167:in 
> `loadclass' Loading MCollective::Agent::Ehyp from
> mcollective/agent/ehyp.rb
> D, [2017-10-19T12:50:04.978885 #13809] DEBUG -- : pluginmanager.rb:167:in 
> `loadclass' Loading MCollective::Util::UnprivilegedAgent from 
> mcollective/util/unprivilegedagent.rb
> E, [2017-10-19T12:50:04.980883 #13809] ERROR -- : pluginmanager.rb:171:in 
> `rescue in loadclass' Failed to load
> MCollective::Util::UnprivilegedAgent: 
> cannot load such file -- pr0cess
> E, [2017-10-19T12:50:04.980981 #13809] ERROR -- : pluginmanager.rb:171:in 
> `rescue in loadclass' Failed to load MCollective::Agent::Ehyp: cannot
> load 
> such file -- pr0cess
> E, [2017-10-19T12:50:04.981084 #13809] ERROR -- : agents.rb:71:in `rescue 
> in loadagent' Loading agent ehyp failed: cannot load such file -- pr0cess
> 
> It finds the agent, but can not load it.
> 
> The first line the the agent is:
> MCollective::Util.loadclass("MCollective::Util::UnprivilegedAgent")
> 
> What is wrong with that line?
> 
> If I remove that line the error is:
> E, [2017-10-19T13:17:18.922324 #42703] ERROR -- : pluginmanager.rb:171:in 
> `rescue in loadclass' Failed to load MCollective::Agent::Ehyp: cannot
> load 
> such file -- open4
> 
> #MCollective::Util.loadclass("MCollective::Util::UnprivilegedAgent")
> require 'open4'
> require 'rubygems'
> 
> >rpm -ql ruby-open4
> /usr/local/lib64/ruby/site_ruby
> /usr/local/share/ruby/site_ruby
> /usr/local/share/ruby/site_ruby/open4.rb
> 
> The open4 is installed, but can not be loaded. Why not?
> 
> Can you please help me?
> 
> -- 
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/ddcfa5b8-dfac-42f4-a0f8-cbb5171b958a%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.


-- 
R.I.Pienaar / www.devco.net / @ripienaar

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/1508415437.144750.1144107840.2A98DAF9%40webmail.messagingengine.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] After mcollective update agent does not work anymore

[R.I.Pienaar]

On Thu, Oct 19, 2017, at 10:49, Andreas Dvorak wrote:
> Dear all,
> 
> I have an self written mcollective agent that does nocht work anymore, 
> after the Puppet und MCollective update. All other agents are working.
> Does anybody has an idea?
> 
> 
> The client is running:
> mcollective 2.6.0
> puppet 3.7.1
> Centos 6
> 
> locate ehyp.rb
> /usr/local/libexec/mcollective/mcollective/agent/ehyp.rb
> /usr/local/libexec/mcollective/mcollective/application/ehyp.rb

The early logs just as the daemon starts shows you what it finds and why
it might not load something it does find, put it in debug and show us

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/1508403493.85649.1143933632.37CE1B29%40webmail.messagingengine.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: Notice: package install ensured on every run

[R.I.Pienaar]

On Thu, Sep 21, 2017, at 11:45, Lars Van Steenbergen wrote:
> Thank you both, 
> 
> The issue was indeed the wildcard.
> I did not notice this because the package did get installed.
> 
> Again, lesson learned ;-)

Puppet will pass what you give it to rpm/yum, so "yum install icinga*"
works fine, but then later it wants to know if "icinga*" is installed
and it looks for exactly that package name - it doesnt understand the
glob.  So it does not find a package called "icinga*" so it tries to
install it again etc

-- 
R.I.Pienaar / www.devco.net / @ripienaar

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/1505987773.1336429.1113467688.22EFA8DE%40webmail.messagingengine.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Notice: package install ensured on every run

[R.I.Pienaar]

On Thu, Sep 21, 2017, at 11:35, Lars Van Steenbergen wrote:
> So every run my puppetmaster spawns a notice that a certain package
> install 
> -> created. 
> Every time again, this is not a problem but really annoying.
> 
> Did a make a beginner mistake in the code, or is this a bug or something 
> else?
> 
> This is the manifest:
> 
> class icinga::install {
> package {'icinga*':

package doesnt take wildcards, thats why it happens.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/1505986789.1330073.1113452808.6B6BA13C%40webmail.messagingengine.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] PQL questions

[R.I.Pienaar]

On Thu, Aug 10, 2017, at 18:32, R.I.Pienaar wrote:
> I want to do dot based fact queries in PQL, basic example:
> 
>inventory[certname] {facts.os.distro.release.major = "7"}
> 
> Great, no problems so far that works, but I cannot figure out how to say
> != "7"
> 
> in the fact endpoint I can do:
> 
>facts {name = "%s" and !(value = "%s")}
> 
> However this does not support the dot notation so thats not useful here.
> 
> The AST docs[1] says there is and, or and not but I cant figure out how
> to use it there, the error messages various attempts give me are:
> 
>inventory[certname] {facts.os.distro.release.major not "7"
>Expected one of:
> 
>is not null
>is null
>in
>=
>>
><
><=
>>=
>~>
>~
> 
> This rather makes me think a basic not isn't supported here? But the old
> AST docs[1] suggests it should be, so I am guessing some support is
> missing in PQL here?
> 

flaf on IRC said to try this:

inventory[certname] {!(facts.os.distro.release.major = "7")}

This works, still to figure out string compares :)

> I'd also like to be able to do > etc on string values, which I think the
> AST based queries also support?
> 
> 
> [1]
> https://docs.puppet.com/puppetdb/5.0/api/query/v4/ast.html#dot-notation
> 
> -- 
> R.I.Pienaar / www.devco.net / @ripienaar
> 
> -- 
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/1502382772.1240443.1069431136.3BC482C6%40webmail.messagingengine.com.
> For more options, visit https://groups.google.com/d/optout.


-- 
R.I.Pienaar / www.devco.net / @ripienaar

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/1502389226.1271678.1069542560.5886EF84%40webmail.messagingengine.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] PQL questions

[R.I.Pienaar]

I want to do dot based fact queries in PQL, basic example:

   inventory[certname] {facts.os.distro.release.major = "7"}

Great, no problems so far that works, but I cannot figure out how to say
!= "7"

in the fact endpoint I can do:

   facts {name = "%s" and !(value = "%s")}

However this does not support the dot notation so thats not useful here.

The AST docs[1] says there is and, or and not but I cant figure out how
to use it there, the error messages various attempts give me are:

   inventory[certname] {facts.os.distro.release.major not "7"
   Expected one of:

   is not null
   is null
   in
   =
   >
   <
   <=
   >=
   ~>
   ~

This rather makes me think a basic not isn't supported here? But the old
AST docs[1] suggests it should be, so I am guessing some support is
missing in PQL here?

I'd also like to be able to do > etc on string values, which I think the
AST based queries also support?


[1]
https://docs.puppet.com/puppetdb/5.0/api/query/v4/ast.html#dot-notation

-- 
R.I.Pienaar / www.devco.net / @ripienaar

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/1502382772.1240443.1069431136.3BC482C6%40webmail.messagingengine.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] merging in-module default data with role-profile parameters

[R.I.Pienaar]

On Mon, Jul 17, 2017, at 11:12, Luke Bigum wrote:
> On Friday, 14 July 2017 17:17:03 UTC+1, R.I. Pienaar wrote:
> >
> >
> > I have not really found a elegant solution, and I think the right way is 
> > to stick this stuff in hiera on the mcollective::server_config key 
> > rather than try and set it via the params. 
> >
> > You're not doing anything programatic about this data, so why not put it 
> > in hiera? 
> >
> 
>  
> The "why" is mostly to do with what I consider to be "data" and what I 
> consider to be "design", influenced a little bit by coding style and the 
> use/abuse of Hiera in our environment.  I can boil it down to three main 
> points:
> 
> Design in one place - if I'm writing Profiles that use tech/component 
> modules, I prefer all the design/business logic in one place (in a
> profile) 
> rather than have half the params in Puppet code and half of it in Hiera. 
>  Profile parameters that are actually data are in Hiera.
> 
> "Staticness" / Attempt to reduce entropy - hard coding component class 
> parameters makes it harder if not impossible for a value to be overridden 
> in Hiera, and thus make machines different / introduce entropy. In a 
> perfect world this probably wouldn't happen, but all too often I find 
> examples of an engineer fixing one specific problem by setting one
> specific 
> Hiera key for a node, not knowing that they've just made that machine 
> behave differently to it's 19 other sibling machines that are supposed to 
> be exactly the same. Discipline and code review also helps stop this from 
> happening.
> 
> Testing - If I care a *very* great deal about a certain parameter's
> value, 
> I can write this data value in Puppet code and RSpec Unit test / Beaker 
> acceptance test that Profile.  If that value came from Hiera, I'd have to 
> begin testing my Hiera data, and since the top level of my Hierarcy is 
> "Node", doesn't that mean I'd have to run the same test for each of my 20 
> nodes that are supposed to be the same...?  With the value hardcoded in 
> Puppet, I've got one place to test the value. I get a certain level of 
> assurance that it can't change, and a certain degree of confidence that
> the 
> machines that profile applies to are "the same".

I see, fair points.  In that case you're best bet is the lookup you
describe or just duplicating the settings into your profile and hard
coding it, its not a lot.

Be aware though that next release of that module will manage the entire
config file and purge all things there not in config - over all better
but one more thing to consider when upgrading to the next version for
this approach specifically


-- 
R.I.Pienaar / www.devco.net / @ripienaar

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/1500286624.459792.1043176856.1CA4C9C3%40webmail.messagingengine.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] merging in-module default data with role-profile parameters

[R.I.Pienaar]

On Fri, Jul 14, 2017, at 18:12, Luke Bigum wrote:
> Hello,
> 
> I've come across an issue with how I want to write profiles vs how a
> module 
> chooses to structure their default data.  As an example, 
> the choria-io/puppet-mcollective module uses hashes of in-module data for 
> each configuration file (which is quite elegant, reduces the amount of 
> templates needed).  My issue with it is how I want to explicitly define 
> some parameters for a profile I'm writing.  If I set a few keys of the 
> 'server_config' hash I end up overwriting the rest of the defaults in the 
> module data, because an explicitly defined class param trumps the entire 
> in-module data hash:
> 
> **
>   class { '::mcollective':
> server=> true,
> client=> true,
> server_config => {
>   rpcauditprovider  => 'choria',
>   'plugin.rpcaudit.logfile' =>
>   '/var/log/puppetlabs/choria-audit.log',
> },
>   }
> **
> 
> I've got a solution by calling lookup() to get the original data
> structure, 
> then doing a hash merge in Puppet code:
> 
> **
>   $default_data = lookup('mcollective::server_config')
>   $my_data = {
> rpcauditprovider  => 'choria',
> 'plugin.rpcaudit.logfile' => '/var/log/puppetlabs/choria-audit.log',
>   }
>   class { '::mcollective':
> server=> true,
> client=> true,
> server_config => $default_data + $my_data,
>   }
> **
> 
> Would anyone consider that a dumb approach? Are there better ways?

I have not really found a elegant solution, and I think the right way is
to stick this stuff in hiera on the mcollective::server_config key
rather than try and set it via the params.

You're not doing anything programatic about this data, so why not put it
in hiera?

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/1500049009.3620455.1041075056.1C347BD9%40webmail.messagingengine.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: PuppetDB Curl Queries

[R.I.Pienaar]

On Tue, Jul 11, 2017, at 19:07, Peter Krawetzky wrote:
> Isn't that for the PE version?  we are using open source.

It's in all versions

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/1499793362.10881.1037544480.5421DAB6%40webmail.messagingengine.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] PuppetDB Curl Queries

[R.I.Pienaar]

Best to use PQL via 'puppet query'

Examples:
https://docs.puppet.com/puppetdb/5.0/api/query/examples-pql.html

On Tue, Jul 11, 2017, at 17:48, Peter Krawetzky wrote:
> Using CURL to query PuppetDB has got to be the most time consuming thing 
> I've ever done.  It took me almost 3 hours one day to create a CURL query 
> that I ended up creating in a SQL statement in 10 minutes once I figured 
> out the database structure.
> 
> Does anyone have:
> 
>1. A documented list of CURL queries and the syntax
>2. A documented list of SQL queries to directly against the Postgresql 
>database
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/8d8e9b09-0c05-4ae8-afcf-48d6a83f8247%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.


-- 
R.I.Pienaar / www.devco.net / @ripienaar

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/1499788471.3231435.1037451160.0703FCC7%40webmail.messagingengine.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] List all hosts

[R.I.Pienaar]

On Wed, May 31, 2017, at 15:33, Daniel Scott wrote:
> Hi,
> 
> I'm looking for a way to list all hosts known by a puppetserver (in 
> puppetdb).
> 
> I've been using 'puppet cert list --all', however, this doesn't
> necessarily 
> correspond to the list of hosts in puppetdb (for example, if I have to 
> rebuild the puppet server, and lose all the certs, but I still have the 
> database).
> 
> Is there a 'puppet' command to list all known hosts?
> 
> I know that it's possible by running a curl against the puppetdb server 
> itself, but it would be much cleaner if I could just run a command on the 
> puppetserver.

Install the client tools:

   https://docs.puppet.com/puppetdb/4.4/pdb_client_tools.html

Use PQL to query it:

   https://docs.puppet.com/puppetdb/4.4/api/query/examples-pql.html

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/1496237775.652693.994141456.1C1EE7B6%40webmail.messagingengine.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Could not retrieve local facts: undefined method `require_relative' for main:Object

[R.I.Pienaar]

On Wed, May 17, 2017, at 16:34, Helen Paterson wrote:
> Hi,
> 
> im currently getting the following error on a few of my Ubuntu solr
> servers
> 
> Error: Could not retrieve local facts: undefined method
> `require_relative' 
> for main:Object
> Error: Failed to apply catalog: Could not retrieve local facts: undefined 
> method `require_relative' for main:Object
> 
> 
> we are running puppet agent 3.8 , im not sure how to debug ???

I would guess your ruby is too old for one of your facts,
require_relative is a ruby method that came in recently.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/1495034663.745652.979740128.1B664CDD%40webmail.messagingengine.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] stop service after install

[R.I.Pienaar]

On Mon, May 15, 2017, at 13:52, Anton Gorlov wrote:
> Hi.
> At the current moment I need bind  the apache to localhost:80 and nginx
> to external_ip:80.
> I cannot change nginx config before it installed and debian start nginx
> automatic after install  package with  default configuration (bind to
> *:80) => conflict.
> 
> So first I stop  the apache service, after install nginx and go update
> config's...

debian will not overwrite configs on package install - suggest you put a
config down that does what you want first.

Debian is just by design stupid, thinks starting all services
unconfigured on install is a good idea, suggest you use a OS designed to
be used on servers and not peoples basements.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/1494850584.255916.976928248.0CBF54C4%40webmail.messagingengine.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Puppet4 $facts syntax

[R.I.Pienaar]

On Fri, Mar 10, 2017, at 14:06, Dirk Heinrichs wrote:
> Am 10.03.2017 um 14:02 schrieb R.I.Pienaar:
> 
> > the first is just wrong
> 
> OTOH, I mostly use $::facts['fact_name'].

this is not needed.

The reason you use $::foo is because of the problem here:

  $foo = "top"
  class x($foo="class") { 
notice($foo)
notice($::foo)
  }

  include x

this produce:

Notice: Scope(Class[X]): class
Notice: Scope(Class[X]): top

you need to guard against the accidental $foo which used to be much
worse with dynamic scope, so the code got littered with all this ::
rubbish.

$facts is globally reserved

  class x {
$facts = {}
  }

  include x

Error: Evaluation Error: Error while evaluating a '=' expression,
Attempt to assign to a reserved variable name: 'facts'

You can never cause the problem that raised the need for $::facts to
exist, you can just use $facts and it's all sweet and

In general with Puppet 4 the needs for all the :: stuff is almost all
gone

-- 
R.I.Pienaar / www.devco.net / @ripienaar

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/1489151425.3162917.906957512.5D8D0563%40webmail.messagingengine.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Puppet4 $facts syntax

[R.I.Pienaar]

On Fri, Mar 10, 2017, at 13:05, Poil wrote:
> Hi,
> 
> In the style guide we have $facts[::operatingsystem]
> 
> In all others documentation we have $facts['fact_name']
> 
> So which one is the good one ? Do we really need to scope inside 
> $facts[::scope] 

Easily answered:

  % puppet apply -e 'notice($facts[::operatingsystem])'
  Notice: Scope(Class[main]):

vs:

  % puppet apply -e 'notice($facts["operatingsystem"])'
  Notice: Scope(Class[main]): CentOS

the first is just wrong

-- 
R.I.Pienaar / www.devco.net / @ripienaar

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/1489150932.3161020.906949560.3F04C32B%40webmail.messagingengine.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Open Source puppet and mcollective issue

[R.I.Pienaar]

On Fri, Feb 24, 2017, at 11:45, Sanjiv wrote:
>  
> 
> Hi,
> We are using both flavor's of Puppet: Enterprise and Open Source. In open 
> source puppet we are trying to push the changes from puppet master to 
> agents. We are finding the nodes using the below commands:
> mco find -F ipaddress=xx.xx.xx.xx
> It sometimes find the nodes and sometimes did not find the nodes. I am
> not 
> able to get the root cause for the same. This is what I am using:
> Puppet Version: 4.9.2
> Mcollective Verson: 2.10.1
> ActiveMQ: 5.9.1
> 
> It seems it stuck somewhere and need to restart the mco and activemq
> again 
> and again.

usually because of ActiveMQ, it's proven to be too much of a pain.

I've made choria.io that configures mcollective with among others:

 - NATS.io middleware thats much more stable
 - PuppetDB integration for discovery

Together this gives a more predictable outcome

-- 
R.I.Pienaar / www.devco.net / @ripienaar

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/1487933671.340496.891499696.21363457%40webmail.messagingengine.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Puppet reporting

[R.I.Pienaar]

On Thu, Feb 9, 2017, at 08:22, devopsfor...@gmail.com wrote:
> Hi Everyone,
> 
> I want to report the puppet change events across nodes to a central
> server. 
> This should be compatible on all versions above 3.7/
> 
> 
> Has any one previously done this or if there is a better solution/way to 
> achieve this? 
> 
> If any one can suggest a good report processor will be very helpful.
> 
> Any suggestions would be appreciated.

that's what PuppetDB does.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/1486650466.977359.875656920.734ECB08%40webmail.messagingengine.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] puppetlabs apt - norecommend option

[R.I.Pienaar]

On Thu, Feb 2, 2017, at 09:13, Romgo wrote:
> Hello,
> 
> 
> I would like to use the apt module, but I can't set this preference (If I 
> am not wrong) :
> 
> /etc/apt.conf.d/01norecommend
> >
> > # apt : FILE MANAGED BY PUPPET
> >
> > APT::Install-Recommends "0";
> >
> > APT::Install-Suggests "0";
> >
>  
> Does anyone have an idea on how to implement this via this plugin ? 
> 
> Best regards,

why don't you just use a file resource? It's not required for every
possible feature ever to exist in every module, you can easily augment
them.


-- 
R.I.Pienaar / www.devco.net / @ripienaar

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/1486023600.1488019.867723928.1022ACAD%40webmail.messagingengine.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] how to use external facts in a template?

[R.I.Pienaar]

On Wed, Jan 25, 2017, at 08:20 PM, Sans wrote:

> 

> 

> On Wednesday, January 25, 2017 at 7:05:03 PM UTC, R.I. Pienaar wrote:
>> 

>> 

>> only if you enable structured facts and have a new facter 

> 

> Well, it's not "structured" i.e. it returns only a string. and didn't
> work as expected.
> It also an "external fact", not sure if that's the main issue.
> Facter.value() works fine with other  fact, like "hostname" etc.
> 



regardless, for @facts to exist you have to enable that feature.  It's
not about *your specific fact*

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/1485372233.3876307.859509952.4C8BA71C%40webmail.messagingengine.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] how to use external facts in a template?

[R.I.Pienaar]

- Original Message -
> From: "Sans" 
> To: "puppet-users" 
> Sent: Wednesday, 25 January, 2017 20:01:20
> Subject: Re: [Puppet Users] how to use external facts in a template?

> On Wednesday, January 25, 2017 at 2:20:30 PM UTC, R.I. Pienaar wrote:
>>
>>
>> not been following, but if you're on a recent version @facts["foo"] is the
>> best
>>
> 
> I didn't know that but will check soon. I'm on v3.8.x - will it work there?

only if you enable structured facts and have a new facter

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/1509158760.495323.1485371092938.JavaMail.zimbra%40devco.net.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] how to use external facts in a template?

[R.I.Pienaar]

- Original Message -
> From: "Sans" 
> To: "puppet-users" 
> Sent: Wednesday, 25 January, 2017 15:17:19
> Subject: Re: [Puppet Users] how to use external facts in a template?

>> Hi Sans,
>>
>> I think your ERB syntax may be off. Here's an example doing something
>> similar. Instead of Facter.value() just put an @ in front of the fact
>> name.
>>
>> <% @nameservers.each do |nameserver| -%>
>> nameserver <%= nameserver %>
>> <% end -%>
>>
>> Best regards,
>> -g
>>
>>  
> AFAIK (and understand), when you gave this: @nameservers compiler just
> treat that as variable, regardless of the fact it's actually a Fact or
> otherwise. Facter.value() is a valid syntax, which I use very often in my
> template and custom fact. The part of template, also try to determine if
> the fact is defined at all or not. It's not working for any external fact.
> As I already mentioned, it works for other facts, like "hostname" etc.
> 

not been following, but if you're on a recent version @facts["foo"] is the 
best

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/788926786.267818.1485354014084.JavaMail.zimbra%40devco.net.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Open source puppet performance monitoring/tuning?

[R.I.Pienaar]

- Original Message -
> From: "dkoleary" 
> To: "puppet-users" 
> Sent: Friday, 13 January, 2017 20:52:30
> Subject: Re: [Puppet Users] Open source puppet performance monitoring/tuning?

> Thanks; That looks like a pretty cool too; unfortunately, I can't seem to
> get it to run.
> 
> Centos 6.8 fully patched:
> 
> $ ./report_print.rb
> ./report_print.rb:17:in `require': no such file to load -- puppet
> (LoadError)
>from ./report_print.rb:17

if you're on puppet 4 you'll need to do:

 /opt/puppetlabs/puppet/bin/ruby report_print.rb

basically you have to use the ruby that puppet uses

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/1449934135.1132789.1484337980731.JavaMail.zimbra%40devco.net.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Open source puppet performance monitoring/tuning?

[R.I.Pienaar]

- Original Message -
> From: "dkoleary" 
> To: "puppet-users" 
> Sent: Friday, 13 January, 2017 19:43:20
> Subject: Re: [Puppet Users] Open source puppet performance monitoring/tuning?

> Hi, Garret;
> 
> Your suggestion to review last_run_summary.yaml results in one huge step in
> the right direction.
> 
> # grep file: /opt/puppetlabs/puppet/cache/state/last_run_summary.yaml
>  file: 121.817228425
> 
> So, how do I go about finding out which file resource(s) are causing the
> problem?

You can use https://github.com/ripienaar/puppet-reportprint to report on slow
things

See the sample report.

I think it'll work with Puppet 4, it's been a while, open an issue if it doesnt

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/380462397.1041195.1484333171651.JavaMail.zimbra%40devco.net.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Puppet managing thousands of resources

[R.I.Pienaar]

- Original Message -
> From: "Christopher Wood" 
> To: "puppet-users" 
> Sent: Wednesday, 11 January, 2017 22:33:22
> Subject: Re: [Puppet Users] Puppet managing thousands of resources

> Out of gruesome interest, 5000 resources of what?
> 
> Assuming I'm remembering the path correctly, something like this would count 
> it
> up, modify for your local case (assuming no puppetdb at your place) to search
> for resource types:
> 
> python -m json.tool /var/lib/puppet/client_data/catalog/`hostname -f`.json |
> grep '"type":' | sort | uniq -c | sort -rn | head

last_run_summary.yaml will show totals already also total time per resource 
type :)

> 
> What do you mean by populating local files via ENC? I'm drawing a blank. Or
> perhaps my mind is recoiling from the notion that you're sending contents of
> files in via top-level ENC variables.
> 
> (For reference catalog sizes around here go from 500-2000 resources with agent
> funs mostly from 15-90 seconds, 2-7 minutes in the initial run. (Because some
> departments do actually have sensible reasons to manage things with that
> granularity.) We're not so big though.)

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/1250936490.1005855.1484170800075.JavaMail.zimbra%40devco.net.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Puppet managing thousands of resources

[R.I.Pienaar]

Lots of improvements. Http connections are reused and new static catalogs will 
help. It's different for everyone just how much it helps though. 

---
R.I.Pienaar

> On 11 Jan 2017, at 18:58, Zachary Vida <vida.z...@gmail.com> wrote:
> 
> Hello, I was wonder if there are any significant impovements in later version 
> of puppet >= 2.6 to catolog compilation and/or application runtimes. 
> 
> In an environment I manage we populate many local files 
> (/etc/passwd,/etc/group,/etc/hosts) via ENC. This results in a steady state 
> catalog compilation/apply run times of several minutes and during an inital 
> puppet apply clocking in at 90 minutes. 
> 
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to puppet-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/puppet-users/d7cc6062-722b-4f8a-9284-27ded5048c34%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/A3DC0D18-A6AA-49B0-ACAD-1DB055B26718%40devco.net.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Over-engineering rant

[R.I.Pienaar]

> And anyone who has their puppet server name on their laptop set to "puppet" 
> is not allowed to yell about security.  EVER.

The scenario I showed was default how puppet works by design. You can be sure 
that most people deploy it that way. They certainly cannot make informed 
decisions about this aspect of puppet in most of the cases which is why the 
current behaviour needs a huge overhaul. For which there are tickets. Though 
real world input will be useful no doubt. 

Personally I use puppet apply on portable machines because the current 
situation is just impossible for that kind of machine. 

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/68DC82B4-9CD7-47C6-9A13-3D1709CB9327%40devco.net.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Over-engineering rant

[R.I.Pienaar]

- Original Message -
> From: "Rob Nelson" 
> To: "puppet-users" 
> Sent: Tuesday, 10 January, 2017 15:28:07
> Subject: Re: [Puppet Users] Over-engineering rant

> I would argue that it's when you break steps 1-3 down into implementation
> details that it becomes confusing for many. If you've done it before, it's
> trivial; if it's your first time, it can be hairy.

this really is the same flow as I highlighted and as shown puppet could just
do it for us

> 
> 
> Rob Nelson
> rnels...@gmail.com
> 
> On Tue, Jan 10, 2017 at 9:16 AM, Trevor Vaughan 
> wrote:
> 
>> Actually, from an automation point of view, this is pretty trivial.
>>
>> Step 1) Create new CA (preserving old CA trust) X number of days prior to
>> expiration
>> Step 2) Pass out both CA trust roots to all systems
>> Step 3) Start a re-signing party using the fact that you already have a
>> bi-directional trust in place
>> Step 4) Let the old CA certificate gracefully expire and remove it
>> whenever you like (nothing will trust it anyway)
>>
>> That's pretty much it.
>>
>> For traditional *NIX applications using a CAPath approach, this is trivial.
>>
>> As long as you have a valid CA in your CAPath, you can roll over
>> certificates with ease.
>>
>> Trevor
>>
>> On Mon, Jan 9, 2017 at 9:04 PM, Rob Nelson  wrote:
>>
>>> I think certificate handling is a valid critique of puppet's security
>>> implementation. Running a public key infrastructure of any sort is
>>> difficult. Things like expired CAs and a lack of intermediate signing CAs
>>> does expose puppet administrators who are lacking those fairly rare skill
>>> sets to some difficult potential issues. I don't want to run a CA, mostly
>>> because I've had to run one before. Many people would also like to extend
>>> the expiration to more than 5 years, but don't find out about this issue
>>> until 4.5 years in. Whoops :)
>>>
>>> It's just that the fix isn't agents automatically accepting new CAs. In
>>> the example given of bringing a new CA online, the issue isn't that the
>>> client would be missing a copy of the original CA signatures, but that
>>> there's no way to verify the new CA is related to the old CA. This
>>> constitutes a pretty high security risk with a decent probability for
>>> exploitation - and not just by external parties, it would be easy to DoS
>>> your agents during a failed migration or by testing with vagrant or
>>> additional VMs by forgetting to change DNS/IPs or a dozen other simple
>>> things to miss. Any improvement here probably ends up being relatively
>>> complex to ensure risks remain low.
>>>
>>> It would be much more reasonable to have an extremely long lived CA and
>>> some intermediate CAs. This is supported by puppet, but only I believe with
>>> an external CA setup (https://docs.puppet.com/puppe
>>> t/latest/config_ssl_external_ca.html) - again, not something most of us
>>> should probably be doing. I don't know that there's a great way to handle
>>> this for the masses, unless Puppet wants to become a CA and sign
>>> intermediates for us ;)
>>>
>>> On Mon, Jan 9, 2017 at 7:18 PM John Gelnaw  wrote:
>>>
 since the agent has, in theory, a valid copy of the original CA which it
 can use to validate the connection.

>>> --
>>> Rob Nelson
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "Puppet Users" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an
>>> email to puppet-users+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit https://groups.google.com/d/ms
>>> gid/puppet-users/CAC76iT_2XN3vaZKrpzsrXOzkT%2B4_3P82ZZWkipig
>>> m8%3D%3DXew9ZA%40mail.gmail.com
>>> 
>>> .
>>>
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> --
>> Trevor Vaughan
>> Vice President, Onyx Point, Inc
>> (410) 541-6699 x788 <(410)%20541-6699>
>>
>> -- This account not approved for unencrypted proprietary information --
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Puppet Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to puppet-users+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit https://groups.google.com/d/
>> msgid/puppet-users/CANs%2BFoVhHTsauG_gA_fODFXWYAoj9McHuvLk5ikOC%
>> 3DoReFd35Q%40mail.gmail.com
>> 
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
> 
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To 

Re: [Puppet Users] Over-engineering rant

[R.I.Pienaar]

- Original Message -
> From: "John Gelnaw" 
> To: "puppet-users" 
> Sent: Tuesday, 10 January, 2017 01:17:58
> Subject: Re: [Puppet Users] Over-engineering rant

> On Monday, January 9, 2017 at 2:39:38 PM UTC-5, R.I. Pienaar wrote:
>>
>>
>> Because if i can convince your client to connect to $evil_ca, then what?
>> How's it to know its a new legit ca and not a new bad ca?
>>
> 
> The same way it "knew" when you originally provisioned it-- It didn't.  In
> fact, the agent, by default, displays the *request* fingerprint-- but never
> the server fingerprint, and doesn't give me a chance to verify it.
> 
> So how many times have you verified you didn't talk to an evil CA when you
> originally connected an agent?

Every time? I logged into my known CA using a non Puppet means, I know it's
the known CA because of SSH safety checks and I sign the client I expect to
sign on this known CA using the information at hand - the client fingerprint
that I visually confirm.
 
> And the thing is, if I delete that cached file, it promptly (and as near as
> I can tell, blindly) downloads the ca.pem file anyway.

But this is not enough, the new ca.pem isn't all you need, you need certs signed
by the new ca too.

Today the trust system is such that the master has to know its handing code
out to trusted clients - hence giving you the info you need to establish client
trust.  Yes more is needed, see below.

> The entire point of a public/private key system is the ability to trust.
> The agent can trust the server, the server can trust the agent.
> 
> The lack of ability to renew that trust *before* it expires is a serious
> failure-- Recently, my initial 5 year CA expired.  The "conventional
> wisdom" was to REBUILD MY ENTIRE ENTERPRISE.  If I'd had to do that,
> there's a good chance I'd have reevaluated my 5 year old decision to go
> with puppet-- not saying I wouldn't have wound up with puppet anyway, but
> I'd have looked much, much harder at competing products, which have made
> huge progress in 5 years.

Yes, as I said to you before, the Puppet CA system needs a lot of work, it
was designed now ~10 years ago and much have changed, it's had some organic
growth but a huge fixup is needed. I bet 10 years ago Luke did not expect
the CA to be around 10 years on and did not imagine we are where we are
so understandable how it is, but it should have been redesigned a while
ago already.

Turns out it's not news to anyone that this is needed and if you look in 
Jira there is a whole group of tickets covering exactly that and afaik
it's quite high priority. I am sure constructive input on those will be
appreciated.

This is why I've previously, when you contacted me off list, also asked
the same question to you: Have you filed any tickets or are you just 
ranting to make yourself feel better?

To expand on the issue with redownloading CA and blind trust, lets 
consider a situation I am often in.

My laptop laptop1.mycorp.local is Puppet managed, have a cert and
a CA.  My laptop is using DHCP because I travel a lot and it uses
the default 'puppet' name for the master.

I go to evilcorp.local who gives me a DHCP host name sucker1.evilcorp.local,
my Puppet agent makes a new cert automagically for this name, sends
it off to be signed by puppet1.evilcorp.local who in turn auto signs
it, I cache the new ca.pem and we're off.  It runs a exec{} that
rsyncs my whole ~ off to its NAS neatly bypassing any disk encryption
I might have and so steals all my other clients code and secrets I
happen to have on my laptop.

Except this doesn't happen because it doesn't redownload the CA.
Not redownloading the CA is CRITICAL.  And yes naming things still
suck, calling it a cache is a mistake, not treating it like a cache
is not.

Today you can mitigate this happening even in the case where somehow
ca.pem goes missing - like it ends up in lost+found. By setting a 
specific certname that is related to your HARDWARE and not your 
SOFTWARE.  Don't use 'puppet' as a master name.  Not enough though
since my whole SSL dir and config might go missing and this is the 
problem with Puppet and its annoying pure local disk based approach
to this.

Local disk issues aside, Ideally I want:

  # puppet agent --waitforcert 10 --ca_finger_print xx:xx:xx

It should send off the CSR and only accept a signed cert back from 
that CA, it should only store that CA, it should store that finger
print in a lock file and ONLY EVER talk to that CA or do anything
as a result of that CA.

If it has any private key at all, it should never automatically
generate a new private key regardless of certname. Automatic
bootstrapping should only happen when the whole ssl setup is 
completely missing.

The process of reissuing expiring certs or cycling your client
certs should be done ONLY under the management of the existing
trust relationship and never automatically.

  * A week/month before CA expires, the master CA makes a new 

Re: [Puppet Users] Over-engineering rant

[R.I.Pienaar]

- Original Message -
> From: "John Gelnaw" 
> To: "puppet-users" 
> Sent: Monday, 9 January, 2017 20:14:00
> Subject: Re: [Puppet Users] Over-engineering rant

> On Monday, January 9, 2017 at 10:10:08 AM UTC-5, R.I. Pienaar wrote:
>>
>>
>> so we're on the same page are you just saying in general the NTP module
>> has too much
>> going on and its too huge for a "simple" piece of software?
>>
> 
> Mostly, it was the unexpected syntax.  Somehow, I completely missed any
> references to data typing.  I'm not even *opposed* to it-- although there's
> a very lazy part of me that says it needs to remain optional.  :)
> 
> While the puppet 3 version is, quite frankly, hideous, I understand why
> it's that way, and it's at least formatted nicely, so it's easily read.
> 
> The puppet 4 version looks cluttered (even though it's much simpler, it
> APPEARS more cluttered because it's not a table any longer), and was a
> paradigm shift I was unprepared for.
> 

yes, today we have:

   class foo(
 String $thing,
 Boolean $other_thing,
 Enum[Boolean, String] $yet_another_thing
   ) { } 

my early feedback on this was from a readability perspective the thing I
care for most is the variable name and like in this class the var names
are obscured as you're immediately drawn to the var types and not their
names

Indention would have helped so there is a column of var names all below
each other, but better would be:

   class foo(
 $thing String,
 $other_thing Boolean,
 $yet_another_thing Enum[Boolean, String]
   ) { } 

Here I can see what the variables are and care for the rest later, there
is a ticket and I know it was planned to support both, not sure where that
is

>From a system perspective we can have MUCH better auto generated docs now
that it knows what type a variable is and user interfaces like the console
can eventually produce much better user interfaces because they can prompt
for things intelligently

> But reading through it makes sense.
> 
> Although-- I think I'd consider (optionally) moving the params to an
> external file, for readability, if nothing else.
> 
> In both the puppet 3.x and 4.x examples, you've got a whole lot of
> information jammed into the "first line" (that has 50+ parameters) that can
> overwhelm a novice user.
> 
> Whatever happened to yaml-in-modules as a concept?  I'd think using
> something like that for parameter definitions would be a much cleaner
> approach.

look at data/* in the module, you still have to define the parameters so
it knows to look them up, I think having the parameters in code is best
but the data and configuration of them (how to merge etc) in data is most
usable, especially as the data aspect is optional etc

> 
> Maybe something like:
> 
> params.yaml:
> classes:
>  ntp:
>config_epp:
>  type: string
>  required: false
> 
> 
> ... but that may be too much caffeine talking.  ;)
> 
> 
>> and Data now uses Hiera, its a LOT LESS code in Puppet 4 and fewer
>> dependencies
>> etc
>>
>> Just want to understand the actual complaint part of this distinctly from
>> the rant
>> part of this mail thread.
>>
> 
> Not even sure it was a complaint-- Just a bit of culture shock as an
> unknown feature crept up on me.
> 
> Heck, you should have seen me trying to find out what the "@@" syntax meant
> (puppetdb has been somewhat unstable until recently in my environment, so
> I've never spent much time on it, and didn't have a need for exported
> resources).
> 
> Puppet, as a language, however, has been a moving target for years-- at one
> point in the 3.x days, I had to switch to a fixed version to keep my puppet
> server from becoming incompatible with my existing code-- but that also
> meant I couldn't easily get security updates, because puppet doesn't
> understand "Update to latest version below version 'x'".  Things have
> improved considerably, but it's a still a full time job keeping up with the
> changes.

4 has been a sea change from the old ad hoc approach to a whole standardisation
and rationalisation perspective, the outcome is much better and actually 
standard
and documented and with a proper language specification and you can find out how
things work - a HUGE improvement, but yes it's practically a brand new language

5 which isnt that far off will be very very smooth sailing as the language 
changes
are done - apparently :) time will tell.

> But if you want rants:
> 
>  * why won't my puppet agents download a new CA from the puppet master
> when I update it?  Why do I have to manually delete the "cached"
> /var/lib/puppet/ssl/certs/ca.pem file in order to get the new ca.pem file
> downloaded?  That's not cached, that's stored.  ;)

Because if i can convince your client to connect to $evil_ca, then what?
How's it to know its a new legit ca and not a new bad ca?

>  * similarly, having to manually delete / renew agent certs is painful
> because you have to be logged in on 

Re: [Puppet Users] Over-engineering rant

[R.I.Pienaar]

- Original Message -
> From: "John Gelnaw" 
> To: "puppet-users" 
> Sent: Monday, 9 January, 2017 15:56:34
> Subject: Re: [Puppet Users] Over-engineering rant

> On Sunday, January 8, 2017 at 2:31:33 PM UTC-5, Rob Nelson wrote:
>>
>> There are a lot of very valid issues and concerns you bring up here. I do
>> want to start by saying, however, that puppet 4 is more than 6 months old -
>> about 20 months to be precise - and most of the significant language
>> changes were introduced somewhat earlier in the future parser in puppet 3.
>> These changes should be easier to take in for sure, but that is at least 3x
>> more to catch up on. I hope that doesn't sound like a harsh response, but I
>> think it's more accepted that after 1.5-2 years, most moving projects will
>> require significant re-learning.
>>
> 
> I've been using "future parser" in Puppet 3 for a while-- I absolutely had
> to have iteration, and a few other features, so I *thought* I had been
> keeping up with puppet development.
> 
> I had a similar reaction to the OP when I looked at the NTP code--
> "ek!!!".
> 

so we're on the same page are you just saying in general the NTP module has too 
much
going on and its too huge for a "simple" piece of software?

Or that are you comparing the puppet 3 version:

  
https://github.com/puppetlabs/puppetlabs-ntp/blob/1cdff74278d2fce0f7a12100d12913c9e0c36ce8/manifests/init.pp
  and it's companion file 
https://github.com/puppetlabs/puppetlabs-ntp/blob/1cdff74278d2fce0f7a12100d12913c9e0c36ce8/manifests/params.pp

with puppet 4 version

  https://github.com/puppetlabs/puppetlabs-ntp/blob/master/manifests/init.pp
  and it's companion file 
https://github.com/puppetlabs/puppetlabs-ntp/blob/master/data/common.yaml

and saying it's gotten impossible and much worse?

The main difference is lines like:

 validate_bool($disable_auth)

became

 Boolean $disable_auth

and Data now uses Hiera, its a LOT LESS code in Puppet 4 and fewer dependencies
etc

Just want to understand the actual complaint part of this distinctly from the 
rant
part of this mail thread.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/762014448.114427.1483974584036.JavaMail.zimbra%40devco.net.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Over-engineering rant

[R.I.Pienaar]

- Original Message -
> From: "Fabrice Bacchella" 
> To: "puppet-users" 
> Sent: Sunday, 8 January, 2017 11:04:18
> Subject: Re: [Puppet Users] Over-engineering rant

>> Le 8 janv. 2017 à 03:00, Jakov Sosic  a écrit :
>> 
>> Hi guys,
>> 
>> this is maybe a topic better suited for -dev list, but, well, here goes.
>> 
>> I've been using puppet heavily for 3-4 years, up until version 4, now I'm 
>> mostly
>> maintaining my own open source modules.
>> 
>> What stumped me lately is the amount of changes that are happening.
>> 
>> 
>> Every week/two-weeks I do some code changes, and since I tried adding some of
>> the spec tests through TravisCI, I've encountered errors about
>> `validate_string` being obsoleted.
>> 
>> Then, looking deeper into the rabbit hole. I've encountered this:
>> 
>> https://github.com/puppetlabs/puppetlabs-ntp/blob/master/manifests/init.pp
>> 
>> And I was shocked... :D WTF just happened? :D
>> 
> 
> This one is funny too:
> https://github.com/puppetlabs/puppetlabs-ntp/blob/master/templates/ntp.conf.epp
> 
>> And, on the other hand - all this complexity to manage a NTP?
> 
> And that's for something that for a given environment never change, have no
> options. So dropping a standard file that is hand made once in a lifetime is
> enough for the vast majority of people.
> 
> That's why I don't use standard or references modules. I can do in 10 lines
> written in 10 minutes what they did in 100 written in many days. I don't care
> that they don't run on some exotic plate from that I never heard of or are not
> good for stratum 1 servers. They are tailored for my need, that's enough for
> me.
> They never brake, never warn, works almost unchanged from puppet 2.7 time and 
> it
> take me the same amount of time that it would have taken to download,
> understand and check them.
> 
>> 
> 
>> 2) Something like search function in chef instead of exported resources and
>> puppetdb
> 
> Puppetdb is very nice and useful, but perhaps a simple and custom query 
> langage
> would be easier to use than strange json query.

google puppet PQL which is that simper language, a searcher function for it 
ships out of the box.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/2042284282.166.1483879404410.JavaMail.zimbra%40devco.net.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Trouble with future parser ?

[R.I.Pienaar]

- Original Message -
> From: "Paul Seymour" 
> To: "puppet-users" 
> Sent: Tuesday, 3 January, 2017 12:05:45
> Subject: Re: [Puppet Users] Trouble with future parser ?

> On Tuesday, 3 January 2017 10:59:42 UTC, R.I. Pienaar wrote:
>>
>>
>>
>> - Original Message -
>> > From: "Paul Seymour" 
>> > To: "puppet-users" 
>> > Sent: Tuesday, 3 January, 2017 11:57:02
>> > Subject: [Puppet Users] Trouble with future parser ?
>>
>> > Hi,
>> > 
>> > OK trying to evaluate how much work and effort it's going to be to move
>> to
>> > Puppet v4.x I have switched on the future parser in our Dev environment.
>> > 
>> > I am now getting this kind of thing:-
>> > 
>> > $ puppet agent -t --trace
>> > Info: Retrieving pluginfacts
>> > Info: Retrieving plugin
>> > Info: Loading facts
>> > Error: Could not retrieve catalog from remote server: Error 400 on
>> SERVER:
>> > Evaluation Error: Error while evaluating a Function Call, Failed to
>> parse
>> > template grub2/default_grub.erb:
>> >  Filepath:
>> > /etc/puppet/environments/dev/modules/grub2/templates/default_grub.erb
>> >  Line: 15
>> >  Detail: undefined method `empty?' for nil:NilClass
>>
>> I'm guessing it's due to the empty? call on the @cmdline_linux variable?
>> You'll have to show the class code etc.
>>
>> My guess would be that particular variable is not known within the scope
>> of
>> the class where you use the template, older puppet had dynamic scope for
>> templates
>> and that's been removed.
>>
>>
> Thanks. Slightly cut down
> 
> class grub2::params {
>  $config_template   = 'grub2/default_grub.erb'
>  $cmdline_linux = 'vconsole.font=latarcyrheb-sun16
> rd.lvm.lv=vg01/root crashkernel=auto vconsole.keymap=uk zswap.enabled=1
> net.ifnames=0 ipv6.disable=1'
>  $cmdline_linux_default = ''
>  $default_entry = '0'
>  $device_install= ''
>  $update_binary = '/usr/sbin/grub2-mkconfig'
>  $grub2_options = hiera('grub2::options', $cmdline_linux)
> ...
> }
> 
> class grub2 (
>  $cmdline_linux = $grub2::params::cmdline_linux,
>  $grub2_options = $grub2::params::grub2_options,
>  $cmdline_linux_default = $grub2::params::cmdline_linux_default,
>  $config_file   = $grub2::params::config_file,
>  $build_file= $grub2::params::build_file,
>  $config_template   = $grub2::params::config_template,
>  $update_binary = $grub2::params::update_binary,
>  $update_grub   = $grub2::params::update_grub,
>  $transparent_hugepages = $grub2::params::transparent_hugepages,
> ...
> ) inherits grub2::params {
> 
> class grub2::config {
>  file { $::grub2::config_file:
>ensure  => 'file',
>owner   => '0',
>group   => '0',
>mode=> '0644',
>content => template($::grub2::config_template),
>require => Class['grub2::install'],
>  }

yes, so this class needs access to the variable in question, best to pass it
into it as a property

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/1564830649.68196.1483441667436.JavaMail.zimbra%40devco.net.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Trouble with future parser ?

[R.I.Pienaar]

- Original Message -
> From: "Paul Seymour" 
> To: "puppet-users" 
> Sent: Tuesday, 3 January, 2017 11:57:02
> Subject: [Puppet Users] Trouble with future parser ?

> Hi,
> 
> OK trying to evaluate how much work and effort it's going to be to move to
> Puppet v4.x I have switched on the future parser in our Dev environment.
> 
> I am now getting this kind of thing:-
> 
> $ puppet agent -t --trace
> Info: Retrieving pluginfacts
> Info: Retrieving plugin
> Info: Loading facts
> Error: Could not retrieve catalog from remote server: Error 400 on SERVER:
> Evaluation Error: Error while evaluating a Function Call, Failed to parse
> template grub2/default_grub.erb:
>  Filepath:
> /etc/puppet/environments/dev/modules/grub2/templates/default_grub.erb
>  Line: 15
>  Detail: undefined method `empty?' for nil:NilClass

I'm guessing it's due to the empty? call on the @cmdline_linux variable?
You'll have to show the class code etc.

My guess would be that particular variable is not known within the scope of
the class where you use the template, older puppet had dynamic scope for 
templates
and that's been removed.



> at /etc/puppet/environments/dev/modules/grub2/manifests/config.pp:7:16 on
> node vrdevpds001.iggroup.local
> /usr/share/ruby/vendor_ruby/puppet/indirector/rest.rb:207:in `is_http_200?'
> /usr/share/ruby/vendor_ruby/puppet/indirector/rest.rb:100:in `find'
> /usr/share/ruby/vendor_ruby/puppet/indirector/indirection.rb:201:in `find'
> /usr/share/ruby/vendor_ruby/puppet/configurer.rb:294:in `block in
> retrieve_new_catalog'
> /usr/share/ruby/vendor_ruby/puppet/util.rb:335:in `block in thinmark'
> /usr/share/ruby/benchmark.rb:296:in `realtime'
> /usr/share/ruby/vendor_ruby/puppet/util.rb:334:in `thinmark'
> /usr/share/ruby/vendor_ruby/puppet/configurer.rb:293:in
> `retrieve_new_catalog'
> /usr/share/ruby/vendor_ruby/puppet/configurer.rb:61:in `retrieve_catalog'
> /usr/share/ruby/vendor_ruby/puppet/configurer.rb:106:in
> `prepare_and_retrieve_catalog'
> /usr/share/ruby/vendor_ruby/puppet/configurer.rb:202:in `run_internal'
> /usr/share/ruby/vendor_ruby/puppet/configurer.rb:134:in `block in run'
> /usr/share/ruby/vendor_ruby/puppet/context.rb:64:in `override'
> /usr/share/ruby/vendor_ruby/puppet.rb:246:in `override'
> /usr/share/ruby/vendor_ruby/puppet/configurer.rb:133:in `run'
> /usr/share/ruby/vendor_ruby/puppet/agent.rb:47:in `block (4 levels) in run'
> /usr/share/ruby/vendor_ruby/puppet/agent/locker.rb:20:in `lock'
> /usr/share/ruby/vendor_ruby/puppet/agent.rb:47:in `block (3 levels) in run'
> /usr/share/ruby/vendor_ruby/puppet/agent.rb:117:in `with_client'
> /usr/share/ruby/vendor_ruby/puppet/agent.rb:44:in `block (2 levels) in run'
> /usr/share/ruby/vendor_ruby/puppet/agent.rb:82:in `run_in_fork'
> /usr/share/ruby/vendor_ruby/puppet/agent.rb:43:in `block in run'
> /usr/share/ruby/vendor_ruby/puppet/application.rb:179:in `call'
> /usr/share/ruby/vendor_ruby/puppet/application.rb:179:in `controlled_run'
> /usr/share/ruby/vendor_ruby/puppet/agent.rb:41:in `run'
> /usr/share/ruby/vendor_ruby/puppet/application/agent.rb:361:in `onetime'
> /usr/share/ruby/vendor_ruby/puppet/application/agent.rb:327:in `run_command'
> /usr/share/ruby/vendor_ruby/puppet/application.rb:381:in `block (2 levels)
> in run'
> /usr/share/ruby/vendor_ruby/puppet/application.rb:507:in `plugin_hook'
> /usr/share/ruby/vendor_ruby/puppet/application.rb:381:in `block in run'
> /usr/share/ruby/vendor_ruby/puppet/util.rb:496:in `exit_on_fail'
> /usr/share/ruby/vendor_ruby/puppet/application.rb:381:in `run'
> /usr/share/ruby/vendor_ruby/puppet/util/command_line.rb:146:in `run'
> /usr/share/ruby/vendor_ruby/puppet/util/command_line.rb:92:in `execute'
> /usr/bin/puppet:8:in `'
> Warning: Not using cache on failed catalog
> Error: Could not retrieve catalog; skipping run
> 
> The template looks like this:-
> # WARNING: This file maintained by Puppet.
> 
> GRUB_DEFAULT=<%= @default_entry %>
> GRUB_TIMEOUT=<%= @timeout %>
> <% if @hidden_timeout != nil -%>
> GRUB_HIDDEN_TIMEOUT=<%= @hidden_timeout %>
> <% end -%>
> <% if @hidden_timeout_quiet != nil -%>
> GRUB_HIDDEN_TIMEOUT_QUIET="<%= @hidden_timeout_quiet %>"
> <% end -%>
> 
> GRUB_DISTRIBUTOR=<%= @distributor %>
> GRUB_CMDLINE_LINUX_DEFAULT="quiet"
> 
> <% if !@cmdline_linux.empty? -%>
> GRUB_CMDLINE_LINUX="<%= @grub2_options %>"
> <% else %>
> GRUB_CMDLINE_LINUX=""
> <% end -%>
> 
> Which parses via erb fine and was working before.
> 
> I cannot see what the issue might actually be ?
> 
> Any help would be appreciated.
> 
> Thanks
> Paul
> 
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email
> to puppet-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/f6288744-d465-439a-826d-5e1e20eca311%40googlegroups.com.
> For more 

Re: [Puppet Users] Re: Array Iteration for Community Edition of Puppet(3.8)

[R.I.Pienaar]

- Original Message -
> From: "Joe" <09cic...@gmail.com>
> To: "puppet-users" 
> Sent: Sunday, 1 January, 2017 19:15:03
> Subject: [Puppet Users] Re: Array Iteration for Community Edition of 
> Puppet(3.8)

> Hello Guys thanks for the replies..
> 
> Apologies for the top posting here.. the reply to post only includes my
> text. I am using the "puppetlabs-release-pc1-trusty.deb" apt source from
> puppet labs and the latest version is 3.8.7 as seen below. I am also using
> the puppetmaster-passenger package from the same repo. R.I Pienaarr said to
> use version 4 however I do not see puppetmaster 4 packages available.
> 
> puppetmaster:
>  Installed: (none)
>  Candidate: 3.8.7-1puppetlabs1
>  Version table:
> 3.8.7-1puppetlabs1 0
>500 http://apt.puppetlabs.com/ trusty/main amd64 Packages
> 3.8.6-1puppetlabs1 0
>500 http://apt.puppetlabs.com/ trusty/main amd64 Packages
> 
> 
> Am I missing something? How can I install the Puppetmaster 4 and
> Puppetmaster-passenger 4 packages on ubuntu server via repository?

You'll have to read about upgrading, its quite the undertaking and the
process is designed so people dont accidentally update and then end up
with inoperable CM systems.

Best start with the Puppet 4 upgrade docs and release notes etc, also 
some pretty good talks at recent Puppetconf about updating

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/1406257407.181120.1483297433107.JavaMail.zimbra%40devco.net.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Array Iteration for Community Edition of Puppet(3.8)

[R.I.Pienaar]

- Original Message -
> From: "John Gelnaw" 
> To: "puppet-users" 
> Sent: Sunday, 1 January, 2017 10:48:49
> Subject: Re: [Puppet Users] Array Iteration for Community Edition of 
> Puppet(3.8)

> On Sunday, January 1, 2017 at 2:41:16 AM UTC-5, R.I. Pienaar wrote:
>>
>>
>> Puppet 3 is now dead, upgrade to Puppet 4 - it's free - and you too can
>> enjoy
>> features designed to solve your problem
>>
> 
> While understandable, that's something of an irritating answer-- It
> underlies a problem I've felt puppet has had since the 1.x days-- Any
> feature you're using can stop working with little warning, unless you
> follow the puppetlabs blogs closely.
> 
> Newer changes aren't quite as drastic as banning hyphens from a class name,
> but it can still be a major pain when you have a bunch of puppet code that
> used to work.  :)
> 
> It also does a nice job of completely ignoring the user's question.

This isn't a case of something that stopped working, the feature is new.

> 
> @Joe:  The iteration feature is available in Puppet 3.7.x and later, but
> you need to enable the "future parser"-- which is also the first step in
> upgrading smoothly to puppet 4.x.

Just blindly enabling future parser, especially on older 3.x releases
can actively cause pretty bad side effects, unexpected changes to nodes etc

First time I did it I had to reinstall the machine in question, so perhaps
not the best of advise either :)

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/1266053538.330.1483281853349.JavaMail.zimbra%40devco.net.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Array Iteration for Community Edition of Puppet(3.8)

[R.I.Pienaar]

- Original Message -
> From: "Joe" <09cic...@gmail.com>
> To: "puppet-users" 
> Sent: Sunday, 1 January, 2017 06:05:49
> Subject: [Puppet Users] Array Iteration for Community Edition of Puppet(3.8)

> Hi All
> 
> Puppet v3.8.7 community on Ubuntu 14 LTS
> 
> I have been attempting to write a class to use the "file_line" type
> reference from the stdlib library to add multiple lines to a file if these
> lines are not present.
> I was attempting to do this with iteration using the each function and
> tried with static and Hiera arrays. After a few hours of failure I came
> across the docs for Puppet Enterprise that say this iteration capability
> was introduced in Puppet 4.
> 
> It looks like this, testdefs is an array in Hiera defined in the nodes yaml
> config
> 
> each($testdefs) |$hline| {
>   file_line { 'Append a line to /etc/testfile':
>  ensure => present,
>  line  => "$hline",
>   path=> '/etc/testfile',
>}
> }
> 
> To be clear I am trying to..
> iterate through a Hiera array
> pass each array member to the file_line type
> append this member to a file if it does not exist.
> 
> Is there a way to do this with Puppet 3.x or should I just make a static
> class with multiple file_line types?

Puppet 3 is now dead, upgrade to Puppet 4 - it's free - and you too can enjoy
features designed to solve your problem

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/65009808.109.1483256466293.JavaMail.zimbra%40devco.net.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Hiera 4 problems

[R.I.Pienaar]

- Original Message -
> From: "Jonathan Gazeley" <jonathan.gaze...@bristol.ac.uk>
> To: "puppet-users" <puppet-users@googlegroups.com>
> Sent: Wednesday, 30 November, 2016 17:16:50
> Subject: Re: [Puppet Users] Hiera 4 problems

> On 30/11/16 16:03, R.I.Pienaar wrote:
>> you need to completely remove the old ripienaar-module_data backend as
>> its not 4 compatible - looks like this is what is happening here
>>
>> if you do use it, you can adjust your modules before hand to be puppet 4
>> compatible by adding a puppet 4 hiera.yaml for its own module data feature
> 
> Yes, I removed the ripienaar-module_data module from all branches - we
> weren't using it anyway. I checked that it is not being referenced in
> any of my manifests. I can't find any reference to module_data_backend
> with a recursive grep in /etc/puppetlabs.
> 
> Any more suggestions?
> 

whats in your classic hiera.yaml?

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/1067447212.779029.1480522852369.JavaMail.zimbra%40devco.net.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Hiera 4 problems

[R.I.Pienaar]

- Original Message -
> From: "Jonathan Gazeley" 
> To: "puppet-users" 
> Sent: Wednesday, 30 November, 2016 16:59:16
> Subject: [Puppet Users] Hiera 4 problems

> I'm still setting up my new PE 2016.4 installation and I'm running into
> a problem with Hiera data per environment. I followed these steps:
> 
> https://docs.puppet.com/puppet/4.7/reference/lookup_quick.html#if-you-already-use-hiera-in-environments
> 
> Every Puppet run errors with:
> 
> Error: Could not retrieve catalog from remote server: Error 500 on
> SERVER: Server Error: Evaluation Error: Error while evaluating a
> Function Call, Lookup of key 'classes' failed: Cannot load backend
> module_data: no such file to load -- hiera/backend/module_data_backend
> in Cannot load backend module_data: no such file to load --
> hiera/backend/module_data_backend at
> /etc/puppetlabs/code/environments/pe/manifests/site.pp:32:1 on node
> puppet4-prod.resnet.bris.ac.uk
> 

you need to completely remove the old ripienaar-module_data backend as
its not 4 compatible - looks like this is what is happening here

if you do use it, you can adjust your modules before hand to be puppet 4
compatible by adding a puppet 4 hiera.yaml for its own module data feature

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/1747502492.757372.1480521790445.JavaMail.zimbra%40devco.net.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] facing issues while using fact hashes

[R.I.Pienaar]

- Original Message -
> From: "giridhar kazama" 
> To: "puppet-users" 
> Sent: Thursday, 24 November, 2016 18:34:39
> Subject: [Puppet Users] facing issues while using fact hashes

> Hello,
> 
> 
> We are trying to use fact hashes in satellite 6.2(puppet 3.8) and getting
> some weird errors like Error: facts is not a hash or array when accessing
> it with distro at /etc/puppet/modules/kazama/manifests/init.pp
> 
> we are completely stuck and unable to proceed further.
> 
> Could someone please help us with some examples of hashes or else redirect
> us to a site where we can find more about the fact hashes.

did you configure puppet for it? 
https://docs.puppet.com/puppet/3.8/reference/lang_facts_and_builtin_vars.html#the-factsfactname-hash

probably also need to set stringify_facts false

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/27712352.576929.1480009326714.JavaMail.zimbra%40devco.net.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: name resolver

[R.I.Pienaar]

there are several on the forge too, but there's a good
reason your firewall doesnt allow you to enter names, its
not a safe thing to do.

- Original Message -
> From: "Peter Faller" 
> To: "puppet-users" 
> Cc: "Albert Shih" 
> Sent: Tuesday, 15 November, 2016 08:44:39
> Subject: [Puppet Users] Re: name resolver

> Hi Albert
> 
> Here's a custom parser function that can resolve names:
> 
> require "resolv"
> 
> module Puppet::Parser::Functions
> 
>  newfunction(
>  :name2ip,
>  :type => :rvalue,
>  :doc => "name2ip( hostname ) => ip_address"
>  ) do |arguments|
>raise(Puppet::ParseError, "name2ip(): Wrong number of arguments given
> (#{arguments.size} for 1)") if arguments.size < 1
> 
>name = arguments[0]
> 
>begin
>  return Resolv.getaddress(name)
>rescue
>  begin
>return Resolv::Hosts.new.getaddress(name)
>  rescue
>raise(Puppet::Error, "Can't resolve host name '#{name}' to an IP
> address")
>  end
>end
>  end
> end
> 
> On Monday, 14 November 2016 23:41:29 UTC+2, Albert Shih wrote:
>>
>>
>>
> 
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email
> to puppet-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/ed9160af-82e5-4131-aae0-84dfaa8a507a%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/2017627398.272.1479198792832.JavaMail.zimbra%40devco.net.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] if else statment is now working in puppet

[R.I.Pienaar]

- Original Message -
> From: "mohammed mathin" 
> To: "puppet-users" 
> Sent: Wednesday, 9 November, 2016 23:08:44
> Subject: [Puppet Users] if else statment is now working in puppet

> Hi,
> 
> My questing will be silly but sorry for that
> 
> I facing problem on setting up the hostname based manifest
> 
> My requirement is if the hostname match statment1 file need to be print.
> 
> But in all the nodes statmen1 file is printing not sure where i have done
> mistake. hear the below my manifest file
> 
> 
> class pkg::statment {
>if ["$hostname" == "172.20.14.173"] {

your hostname will not be an ip address, it will be like web1

add notify{"hostname is ${hostname}": } and see what it says

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/1172061445.710504.1478731462817.JavaMail.zimbra%40devco.net.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] development workflow

[R.I.Pienaar]

> On 7 Nov 2016, at 14:22, Robert  wrote:
> 
> Thanks!
> 
> When I said Bitbucket I meant the in-house Bitbucket instance as well - 
> storing anything outside our infrastructure is not really an option.
> Actually we compared Bitbucket and Git_Hub_ earlier and chose Bitbucket, but 
> kind of abandoned the whole evaluation since it wasn't really needed yet. I'm 
> reluctant to use something as bloated if I could use cgit for web view, and 
> probably gitolite for access control. But I have to say these products have 
> their charm as well... 
> 
> Gerrit is bloated *and* ugly, so after all a one-in-all product might work 
> best. What I don't like with Bitbucket is that 1.) the "free" (10$) version 
> is limited to 10 users and that might be scarce 2.) it seems that you can't 
> control the access on a per-repository but on a per-project basis and this 
> would mean I have to create bunch of projects (which isn't a blocker, 
> actually...).
> 
> Gitlab would be another option, the enterprise features are quite promising, 
> but it's not cheap.
> 
> Anyway, if others have experiences and suggestions, they're welcome.

Check out gogs.io. Doesn't have CI built in but it's so light and easy to 
deploy and run it's well worth a consideration over gitlab 
> 
> Best
> Rp
> 
> 
> 
>> On Mon, Nov 7, 2016 at 10:43 AM, Paul Seward  
>> wrote:
>> Hi,
>> 
>> An in-house gitlab server will let you do 2,3,4,5 and 7, gitlab supports 
>> webhooks to r10k/code manager which will do 6 for you.
>> 
>> It's easy to set up (and there are puppet modules that will help you do 
>> that) and you don't have to persuade your compliance/governance dept to let 
>> you keep everything in a 3rd party service like bitbucket.
>> 
>> Some workflow related features (eg mandating a minimum number of approvals 
>> on a merge request before it being accepted) are only available in the 
>> enterprise edition, but you can get a lng way with the free version.
>> 
>> -Paul
>> 
>>> On 7 November 2016 at 09:33, Robert  wrote:
>>> Dear List,
>>> 
>>> Puppet started out as a PoC for us, to see if it's worth the investment in 
>>> time and energy. The answer is definitely yes, and we'd like to take some 
>>> sort of next step.
>>> 
>>> Which would be cooperation with smaller teams, versioning & review of code 
>>> and stuff.
>>> 
>>> So I'd like to hear your thoughts on how this could be achieved best. (I 
>>> read several articles etc. but they may or may not work IRL.)
>>> 
>>> Requirements and nice-to-haves:
>>> 1. we use a single PE server
>>> 2. we have a git server, one repository per puppet module
>>> 3. I'd like to be able to control the access to the repositories, like: the 
>>> linux admins have all rights; the jboss team has only access to the jboss 
>>> module + 1-2 smaller modules; the network team to other modules etc.
>>> 4. every team should be able to change its modules freely - but not the 
>>> production branch
>>> 5. in order to change the production branch, somebody from the linux admins 
>>> has to review the commit and accept/deny it
>>> 6. changes in the repositories should be propagated automatically to the PE
>>> 7. we need some sort of a web repository browser
>>> 
>>> For 7, I have already set up cgit... but I'm not addicted to it if there is 
>>> something better.
>>> 
>>> As of 6, automatic propagation could be done either by r10k or Code 
>>> Manager. Which one is recommended nowadays?
>>> 
>>> 5 would be an importand one; my first idea would be Gerrit. Does someone 
>>> use it?
>>> 
>>> For 3 and 4 would be probably gitolite the best tool, but access control 
>>> may be included in other software?
>>> 
>>> Or, alternatively, should I use something heavy-weight all-in-one 
>>> juggernaut like Bitbucket?
>>> 
>>> 
>>> I'd be happy to read about your setup and best practices.
>>> 
>>> Best
>>> Rp
>>> -- 
>>> You received this message because you are subscribed to the Google Groups 
>>> "Puppet Users" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an 
>>> email to puppet-users+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/puppet-users/CANwwCtxUCHnHhB7xSWqb66oT9tGitv_nEtN_Q86UCWN9bC23rQ%40mail.gmail.com.
>>> For more options, visit https://groups.google.com/d/optout.
>> 
>> 
>> 
>> -- 
>> --
>> Paul Seward,Senior Systems Administrator,University of Bristol
>> paul.sew...@bristol.ac.uk  +44 (0)117 39 41148GPG Key ID: E24DA8A2
>> GPG Fingerprint:7210 4E4A B5FC 7D9C 39F8  5C3C 6759 3937 E24D A8A2
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Puppet Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to puppet-users+unsubscr...@googlegroups.com.
>> To view this discussion on the web 

Re: [Puppet Users] What is the limit of nodes mcollective and activemq can maintain?

[R.I.Pienaar]

- Original Message -
> From: "Dayton Jones" 
> To: "puppet-users" 
> Sent: Thursday, 3 November, 2016 18:13:01
> Subject: [Puppet Users] What is the limit of nodes mcollective and activemq 
> can maintain?

> I've seen posts of the "800 node wall" with mcollective/activemq, but
> nothing recent
> (http://ramblings.narrabilis.com/books/masteringpuppet/mcollective).

There isn't really a good rule of thumb, the oreilley book has some good
guidance but really it's a bit hit and miss at your scale.  With the way
that Java GC is I doubt it will be solid.  I am working on using NATS.io
instead of ActiveMQ and at least one user here reported success but ofcourse
I have no idea how this will behave at your scale - I do suspect better
than what you have with ActiveMQ though.

Philosophically I do not think such huge collectives make a whole lot of
sense, it's hard for a human to really consider the impact of actions at
that scale and it's perhaps worth making several actual seperate loose
standing mcollectives rather than making this giant 30k one. Further while
mcollective makes effort to have a data model and display model that makes
sense even on large scale, I doubt you can really comprehend the output 
at such scale when there is variance.

Above though depends of course on your use case and what you're doing but
I am very weary of such giant ones.  Perhaps you can elaborate?

Better use the mcollective-users lists.


> 
> Is there a logical limit of nodes that a collective can contain?  I'm
> working in an environment that currently has about 27,000 nodes - they are
> broken up into separate collectives, but some collectives have several
> thousand nodes (up to 9,000) and growing.  Running "mco inventory --lc"
> will most times report back in the 27k range, but more and more that number
> is significantly less (with some collectives not even showing up) - in the
> hundreds instead of 10's of thousands...
> 
> Stopping and restarting the activemq brokers, will "fix" this most of the
> time.
> 
> Running puppet 3.6.2, mcollective-puppet 1.7.2, and activemq 5.9.1
> 
> Currently have 7 collectives configured, each collective has either one or
> two brokers, but the "main" broker (and the largest collective) has 3
> brokers (master +2 slaves)
> 
> 
>~]$ mco inventory --lc --dt=120
> 
>   Collective Nodes
>   == =
>   col5_mcollective   136
>   col4_mcollective   282
>   col2_mcollective1276
>   col7_mcollective   3059
>   col6_mcollective3451
>   col3_mcollective   6744
>   col1_mcollective12115
>   mcollective27064
> 
> Total nodes: 27064
> 
> 
> ~]$ mco inventory --lc --dt=120
> 
>
> 
> Collective Nodes
>   == =
>   col5_mcollective   138
>   col4_mcollective   284
>   col7_mcollective   3062
>   col6_mcollective3433
>   mcollective6918
> 
> Total nodes: 6918
> 
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email
> to puppet-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/f075a078-1dee-49a8-bb5f-56fcc2dee5bb%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/1203200876.549781.1478193759030.JavaMail.zimbra%40devco.net.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] paragraphing hiera yaml

[R.I.Pienaar]

- Original Message -
> From: "Christopher Wood" 
> To: "puppet-users" 
> Sent: Friday, 28 October, 2016 19:45:42
> Subject: [Puppet Users] paragraphing hiera yaml

> Here's a Friday sort of question.
> 
> All the yaml emitters don't add the extra space that I can add as a person
> editing a file to make things more readable. Or to be more accurate, I can't
> manage it myself and I can't find one that does.
> 
> Consider the readability of the two examples below when thinking about what 
> keys
> go with which classes. Also keep in mind that while example one may be fine 
> for
> many of us, lots more people will find it easier to work with yaml using
> example two.
> 
> So how would I auto-magically auto-paragraph hiera yaml to make it friendlier
> for more people, while still keeping it syntactically valid?
> 
> 
> Example one:
> 
> ---
> one::services::enabled: true
> one::two::abc: 8.45
> one::two::three: this is the string
> puppet4::ca_server: otherhostname
> puppet4::server: hostname
> 
> 
> Example two:
> 
> ---
> one::services::enabled: true
> 
> one::two::abc: 8.45
> one::two::three: this is the string
> 
> puppet4::ca_server: otherhostname
> puppet4::server: hostname

nothing really built in but you can hack this up yourself (emphasis on hack)

https://gist.github.com/ripienaar/097aa19b928a57b4b7a4ec861fa4

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/2124299857.120.1477817859281.JavaMail.zimbra%40devco.net.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Facts and Resource relationships

[R.I.Pienaar]

- Original Message -
> From: "Erez Zarum" 
> To: "puppet-users" 
> Sent: Thursday, 6 October, 2016 09:40:44
> Subject: [Puppet Users] Facts and Resource relationships

> I'm not sure if it's a bug or an expected behavior.
> 
> I have written a simple fact for a module that returns a version of a
> binary file, it executes: "binary --version" and then parses the version,
> no issues there, it works.
> 
> The issue i am having is relying on this fact in case the binary file gets
> upgraded during a package installation (this is the simple example)
> 
> package { 'package':
> ensure => '1.3.8'
> } ->
> notify { "version: ${::binary_version}": }
> 
> If the previous version was 1.3.7 the fact "binary_version" will return
> 1.3.7, the next run it will return 1.3.8 as expected.
> The biggest issue is if i rely on this fact to pick up a template to use,
> if this package is not yet installed the fact won't work and will work only
> on the second run.
> 
> I can only assume this happens because the facts are being "compiled"
> before the catalog is.
> 
> I have tried different ways to declare the relationship but it doesn't work.

yes, you cant use facts for something that changes during a run.  It's for facts
about your node that influence the creation of the catalog.

things the catalog changes - well thats after the catalog was created

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/685981672.59634.1475739920045.JavaMail.zimbra%40devco.net.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Duplicate declaration - hard to find...

[R.I.Pienaar]

- Original Message -
> From: "Ugo Bellavance" 
> To: "puppet-users" 
> Sent: Wednesday, 21 September, 2016 14:51:00
> Subject: Re: [Puppet Users] Duplicate declaration - hard to find...

>>
>>
>> in a define all resources have to have unique names, error says in some
>> case
>> you do not. So you're either attempting to make 2 instances where
>> application
>> is 'agtweb' or something else,
>>
>> Show the actual code.  And the actual code where you make 'agtweb'
>> application.
>>
>>
> Sorry here's the code:

which one produced the actual error you had? Computer doesnt really have
a concept of 'or' about code here.

Again though, your file{} resources need to be unique, so when you have
the first case you have to do:

  apache::varwwwatdsrcapp{"foo":
application => "foo"
  }

  apache::varwwwatdsrcapp{"bar":
application => "baz"
  }

these are fine, but:

  apache::varwwwatdsrcapp{"foo":
application => "foo"
  }

  apache::varwwwatdsrcapp{"bar":
application => "foo"
  }

is not because it would cause a duplicate file of the same name

likewise

  apache::varwwwatdsrcapp{"foo": }
  apache::varwwwatdsrcapp{"bar": }

would fail because you set a default on 'application' which would
cause duplicates.

> 
> Either:
> 
> define apache::varwwwatdsrcapp (
> 
>$application  = 'agtweb',
>$client   = '',
>$envstage = '',
> 
> ) {
> 
>  file {
>  "/var/www/atd/src/${application}":
>  ensure => directory,
>  owner  => "deploy",
>  group  => "deploy",
>  mode   => 0755,
>  require => Class['apache::varwwwatdsrc'],
>  }
> 
> }
> 
> Or
> 
> define apache::varwwwatdsrcapp (
> 
>$application  = 'agtweb',
>$client   = '',
>$envstage = '',
> 
> ) {
> 
>  file {
>  '/var/www/atd/src/agtweb':
>  ensure => directory,
>  owner  => "deploy",
>  group  => "deploy",
>  mode   => 0755,
>  require => Class['apache::varwwwatdsrc'],
>  }
> 
> }
> 
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email
> to puppet-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/79dff55f-e972-4a9c-9636-3a0f5f44b84c%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/638693790.228597.1474462516945.JavaMail.zimbra%40devco.net.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Duplicate declaration - hard to find...

[R.I.Pienaar]

- Original Message -
> From: "Ugo Bellavance" 
> To: "puppet-users" 
> Sent: Wednesday, 21 September, 2016 14:29:50
> Subject: [Puppet Users] Duplicate declaration - hard to find...

> Hi,
> 
> I'm getting this error message when I run a puppet noop:
> 
> Error 400 on SERVER: Duplicate declaration: File[/var/www/atd/src/agtweb]
> is already declared in file
> /etc/puppet/modules/apache/manifests/varwwwatdsrcapp.pp at line 17; cannot
> redeclare at /etc/puppet/modules/apache/manifests/varwwwatdsrcapp.pp:17
> 
> Here's the contents of the file (I tried with the app1 directly or using
> the ${application} variable

not really useful to show code other than the code producing the error.

in a define all resources have to have unique names, error says in some case
you do not. So you're either attempting to make 2 instances where application
is 'agtweb' or something else,

Show the actual code.  And the actual code where you make 'agtweb' application.

> 
> define apache::varwwwatdsrcapp (
> 
>$application  = 'app1',
>$client   = '',
>$envstage = '',
> 
> ) {
> 
>  file {
> #"/var/www/atd/src/${application}":
>'/var/www/atd/src/app1':
>  ensure => directory,
>  owner  => "deploy",
>  group  => "deploy",
>  mode   => 0755,
>  require => Class['apache::varwwwatdsrc'],
>  }
> 
> }
> 
> Contents of the file containing the required class:
> 
> class apache::varwwwatdsrc {
> 
>  file { '/var/www/atd/src':
>  ensure => directory,
>  owner  => "root",
>  group  => "root",
>  mode   => 0755,
>  require => File["/var/www/atd"],
>  }
> 
> }
> 
> Contents of the file containing the required File:
> 
> class apache::varwwwatd {
> 
>  file { '/var/www/atd':
>  ensure => 'directory',
>  owner  => 'root',
>  group  => 'root',
>  mode   => 0744,
>  }
> 
> }
> 
> I realize that I use double quotes where I shouldn't, but I don't think
> that affects the logic.
> 
> Any ideas where the problem may be?
> 
> Thanks,
> 
> Ugo
> 
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email
> to puppet-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/4b843ccb-c2ba-4f4d-9b9b-6ae7da9d16b0%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/1063999239.209562.1474461266280.JavaMail.zimbra%40devco.net.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Defined Resource types and Relationship

[R.I.Pienaar]

- Original Message -
> From: "Erez Zarum" 
> To: "puppet-users" 
> Sent: Wednesday, 21 September, 2016 10:19:24
> Subject: Re: [Puppet Users] Defined Resource types and Relationship

> If i understand correctly, I do not have to contain (declare contain) on
> the defined resource (like in app::server)?
> As in my example it will work as expected?

yes, your example is fine, i mean containment if you were to include anything
in the define

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/1043987034.9938.1474446410004.JavaMail.zimbra%40devco.net.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Defined Resource types and Relationship

[R.I.Pienaar]

- Original Message -
> From: "Erez Zarum" 
> To: "puppet-users" 
> Sent: Wednesday, 21 September, 2016 09:16:18
> Subject: [Puppet Users] Defined Resource types and Relationship

> Is it the same behavior as classes?
> Example:
> 
> define app::server {
>  ::app::server::config { '/etc/app.conf': }
>  ::app::server::service { 'app': }
> 
>  App::Server::Config['/etc/app.conf'] -> App::Server::Service['app']
> }
> 
> define app::server::config {
>  file { $name:
>ensure => present
>  }
> }
> 
> define app::server::service {
>  service { $name:
>ensure => 'running'
>  }
> }
> 
> Will this work as expected, what happens if i have dependency resources
> inside the defined types? will it contain it as well?

yes with the same caveats as classes and class containment

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/214964943.339.147748140.JavaMail.zimbra%40devco.net.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: notify resource different between 3 and 4?

[R.I.Pienaar]

- Original Message -
> From: "jcbollinger" 
> To: "puppet-users" 
> Sent: Tuesday, 20 September, 2016 15:37:21
> Subject: Re: [Puppet Users] Re: notify resource different between 3 and 4?

> On Monday, September 19, 2016 at 10:03:14 AM UTC-5, R.I. Pienaar wrote:
>>
>>
>>
>> On 19 Sep 2016, at 15:31, jcbollinger 
>> wrote:
>> I see a difference between 3.8 and 4.6 with respect to the result of
>> interpolating an array into a string.  In Puppet 3 (and earlier) you get a
>> concatenation of the stringifications of all the elements, whereas in
>> Puppet 4, you get a more formatted representation.  I would have expected
>> such a change to be applied during a major version update -- so between 3.x
>> and 4.0 -- but a quick browse of the release notes does not appear to
>> mention it.
>>
>> This is not a puppet behaviour change. Newer Ruby does nicer looking to_s
>> on arrays that's why
>>
>>
> 
> I'm prepared to believe that there's no Puppet code change, which would
> explain why it's not documented in any release notes, but there's certainly
> an observable behavior difference between the two example runs.  If that is
> not to be accounted a Puppet behavior change then I suppose it must also be
> observable with (only) Puppet 3.8 running on different Ruby versions.
> That's a nice gotcha if you happen to rely on interpolating arrays (not
> that I would recommend doing so in any case).

yeah, and so you would I think, certainly recall people on IRC running into 
that.

> 
> On the other hand, I observe that the current (4.6) Puppet docs document
> the array interpolation format
> ,
> independent of underlying Ruby.  That may now be a distinction without much
> practical difference, but it's the right thing to do: details of the
> infrastructure -- and especially changes to them -- ought not to leak out
> into Puppet's user-facing behavior.  This sort of thing will become more
> important as Puppet continues its movement away from Ruby as the main
> implementation language.

yup, this becomes a specified and supported way to do this and you can probably
expect these to be properly treated in future.

There is additionally massive amount of string formatting stuff now in the 
language
https://github.com/puppetlabs/puppet-specifications/blob/master/language/types_values_variables.md

Though their usability leaves a lot to be desired, I suppose they are meant to 
be
used as plumbing for higher order solutions like wrapper functions or something,
I can't imagine anyone using them as is.


> In any case, inasmuch as the OP was asking about behavioral differences, it
> is highly relevant that the one observable difference of any significance
> arises not because of a difference in the version of Puppet, but because of
> a difference in the version of the Ruby underneath.

Yeah, expect less of that as work moves toward C based compilers etc, this
will make pinning every thing down to specified behaviour, good times.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/1120926933.445844.1474379654522.JavaMail.zimbra%40devco.net.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: notify resource different between 3 and 4?

[R.I.Pienaar]

> On 19 Sep 2016, at 15:31, jcbollinger  wrote:
> 
> 
> 
>> On Friday, September 16, 2016 at 12:11:26 PM UTC-5, Christopher Wood wrote:
>> While trying to figure out the reduce function with notice/notify I happened 
>> across this thing. It looks like an unquoted array in the notify resource's 
>> message only appears as its first array item. Not sure if it's a bug. 
>> 
>> I couldn't find any documentation to say if this was intended and I couldn't 
>> really tell what the type was doing with the self.should bit. I am not 
>> actually a programmer. 
>> 
>> $ cat /tmp/xx.pp 
>> $array = ["one", "two", "three"] 
>> 
>> notify { 'notify one': 
>>   message => "${array}", 
>> } 
>> 
>> notify { 'notify two': 
>>   message => $array, 
>> } 
>> 
>> With puppet 3 I see this: 
>> 
>> $ puppet --version 
>> 3.8.7 
>> $ puppet apply /tmp/xx.pp 
>> Fact file /etc/facter/facts.d/monit_fail_count was parsed but returned an 
>> empty data set 
>> Fact file /etc/facter/facts.d/monit_fail_count was parsed but returned an 
>> empty data set 
>> Notice: Compiled catalog for mail82c40.carrierzone.com in environment 
>> production in 0.03 seconds 
>> Notice: one 
>> Notice: /Stage[main]/Main/Notify[notify two]/message: defined 'message' as 
>> 'one' 
>> Notice: onetwothree 
>> Notice: /Stage[main]/Main/Notify[notify one]/message: defined 'message' as 
>> 'onetwothree' 
>> Notice: Finished catalog run in 0.05 seconds 
>> 
>> With puppet 4 I see this: 
>> 
>> $ puppet --version 
>> 4.6.2 
>> $ puppet apply /tmp/xx.pp 
>> Notice: Compiled catalog for cwl.hostopia.com in environment production in 
>> 0.09 seconds 
>> Notice: [one, two, three] 
>> Notice: /Stage[main]/Main/Notify[notify one]/message: defined 'message' as 
>> '[one, two, three]' 
>> Notice: one 
>> Notice: /Stage[main]/Main/Notify[notify two]/message: defined 'message' as 
>> 'one' 
>> Notice: Applied catalog in 0.11 seconds 
> 
> 
> I see a difference between 3.8 and 4.6 with respect to the result of 
> interpolating an array into a string.  In Puppet 3 (and earlier) you get a 
> concatenation of the stringifications of all the elements, whereas in Puppet 
> 4, you get a more formatted representation.  I would have expected such a 
> change to be applied during a major version update -- so between 3.x and 4.0 
> -- but a quick browse of the release notes does not appear to mention it.

This is not a puppet behaviour change. Newer Ruby does nicer looking to_s on 
arrays that's why


> 
> You called out the unquoted array being bound to the 'message' parameter of 
> the second Notify, but that seems to have exactly the same behavior in the 
> two Puppet outputs you present.  In both cases, the message is taken as the 
> first element of the array.  As R.I. observed, you should not bind an array 
> to a parameter that expects a string.  Given that you did so, I think Puppet 
> handled the situation in a reasonable way.  I'm uncertain whether that 
> behavior is documented.
> 
> 
> John
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to puppet-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/puppet-users/eadea0df-b342-47b9-a3e3-daa981d128b7%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/E14BBDEE-2291-45BD-96BB-0D3D06AD3E21%40devco.net.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] notify resource different between 3 and 4?

[R.I.Pienaar]

- Original Message -
> From: "Christopher Wood" <christopher_w...@pobox.com>
> To: "puppet-users" <puppet-users@googlegroups.com>
> Sent: Friday, 16 September, 2016 19:39:21
> Subject: Re: [Puppet Users] notify resource different between 3 and 4?

> On Fri, Sep 16, 2016 at 06:17:48PM +0100, R.I.Pienaar wrote:
>> 
>> 
>> - Original Message -
>> > From: "Christopher Wood" <christopher_w...@pobox.com>
>> > To: "puppet-users" <puppet-users@googlegroups.com>
>> > Sent: Friday, 16 September, 2016 19:10:23
>> > Subject: [Puppet Users] notify resource different between 3 and 4?
>> 
>> > While trying to figure out the reduce function with notice/notify I 
>> > happened
>> > across this thing. It looks like an unquoted array in the notify resource's
>> > message only appears as its first array item. Not sure if it's a bug.
>> > 
>> > I couldn't find any documentation to say if this was intended and I 
>> > couldn't
>> > really tell what the type was doing with the self.should bit. I am not 
>> > actually
>> > a programmer.
>> > 
>> > $ cat /tmp/xx.pp
>> > $array = ["one", "two", "three"]
>> > 
>> > notify { 'notify one':
>> >  message => "${array}",
>> > }
>> > 
>> > notify { 'notify two':
>> >  message => $array,
>> > }
>> > 
>> 
>> yes this is across all resource types, you cant pass a array to the namevar 
>> and
>> produce many resources, you have to do so to the title
> 
> I thought both messages would have some variant of [one, two, three].
> 
> Also the namevar here is the name parameter.
> 
> But then things get even weirder when I try to do things with the namevar:
> 
> $ cat /tmp/y.pp
> $array = ["one", "two", "three"]
> 
> notify { $array:
>  message => $array,
> }
> 
> $ puppet apply /tmp/y.pp
> Notice: Compiled catalog for cwl.hostopia.com in environment production in 
> 0.04
> seconds
> Notice: one
> Notice: /Stage[main]/Main/Notify[one]/message: defined 'message' as 'one'
> Notice: one
> Notice: /Stage[main]/Main/Notify[two]/message: defined 'message' as 'one'
> Notice: one
> Notice: /Stage[main]/Main/Notify[three]/message: defined 'message' as 'one'
> Notice: Applied catalog in 0.08 seconds

kind of expected, or just undefined, message should be a string don't give it a 
array.
but you can see the names got created as per the array so that seems fine to 
me, if anything
I think it should raise when you pass non string to message


> But this seems like it might be more normal, but then breaks in a manner I did
> not expect:
> 
> $ cat /tmp/z.pp
> $array = ["one", "two", "three"]
> 
> notify { $array:
>  name => $array,
>  message => $array,
> }
> 
> $ puppet apply /tmp/z.pp
> Error: Evaluation Error: Error while evaluating a Resource Statement, Cannot
> alias Notify[two] to [["one", "two", "three"]] at /tmp/z.pp:3; resource
> ["Notify", "one", "two", "three"] already declared at /tmp/z.pp:3 at
> /tmp/z.pp:3:1 on node cwl

yeah you cant pass arrays to name either - this is the main change here, you 
used to be able to.
It *is* though creating notify[one] notify[two] etc but then fail because of 
passing things
into name you shouldnt :)

> The namevar thing works as expected with a file. Feeling more like this is bug
> now.
>
> $ cat /tmp/a.pp
> $array = ["/tmp/one", "/tmp/two", "/tmp/three"]
> 
> file { $array:
>  content =>  $array,
> }

it doesnt really, content isnt the namevar. you're passing a array to title 
thats fine, content
being an array it's probably just going to puts the array into the file as a 
string

This stuff seems to work though errors can be a LOT better and I think it 
should be more strict
on the type of things passed to String properties like message

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/31059471.611617.1474047876604.JavaMail.zimbra%40devco.net.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] notify resource different between 3 and 4?

[R.I.Pienaar]

- Original Message -
> From: "Christopher Wood" 
> To: "puppet-users" 
> Sent: Friday, 16 September, 2016 19:10:23
> Subject: [Puppet Users] notify resource different between 3 and 4?

> While trying to figure out the reduce function with notice/notify I happened
> across this thing. It looks like an unquoted array in the notify resource's
> message only appears as its first array item. Not sure if it's a bug.
> 
> I couldn't find any documentation to say if this was intended and I couldn't
> really tell what the type was doing with the self.should bit. I am not 
> actually
> a programmer.
> 
> $ cat /tmp/xx.pp
> $array = ["one", "two", "three"]
> 
> notify { 'notify one':
>  message => "${array}",
> }
> 
> notify { 'notify two':
>  message => $array,
> }
> 

yes this is across all resource types, you cant pass a array to the namevar and 
produce many resources, you have to do so to the title

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/403108144.592797.1474046268142.JavaMail.zimbra%40devco.net.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] variable scoping and erb templates

[R.I.Pienaar]

- Original Message -
> From: "Matt Zagrabelny" 
> To: "puppet-users" 
> Sent: Tuesday, 16 August, 2016 15:07:28
> Subject: Re: [Puppet Users] variable scoping and erb templates

> On Tue, Aug 16, 2016 at 8:04 AM, jcbollinger  
> wrote:
>>>
>>> On Tue, Aug 16, 2016 at 1:31 AM, Lowe Schmidt  wrote:
>>> > What version of Puppet are you running?
>>>
>>> Debian Jessie:
>>>
>>> 3.7.2-4
>>>
>>
>>
>> That looks like bug PUP-1220.  Note that although the ticket is marked as
>> being fixed in Puppet 3.5, commentary on the ticket and details of the
>> associated commit make me think that the fix only applies when you use the
>> future parser.
> 
> Thanks for clearing my confusion, John!

historically this is how puppet worked both in manifests and templates, that
got deprecated but for some reason templates didnt get the same treatment, 4
finished the job

> 
> Best,
> 
> -m
> 
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email
> to puppet-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/CAOLfK3W4DAqi9%3D63pwxGUO_jYQkcL6bnSMx_cePPN3z1dVyuyA%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/164645949.512039.1471353775876.JavaMail.zimbra%40devco.net.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: Puppet .... ruby regex

[R.I.Pienaar]

- Original Message -
> From: "Robert Poulson" 
> To: "puppet-users" 
> Sent: Thursday, 4 August, 2016 16:42:21
> Subject: Re: [Puppet Users] Re: Puppet  ruby regex

>>
>> $pp_shortcertname= "${trusted['certname']}".match(/([^.]+)\./)[1]
>>
>> not sure I fully understand why this works and [] doesn't.
>>
>> Not 100% sure I understand what the [1] does !
>>
> 
> The parentheses are for capturing the matching text, and \1 for re-using it
> as a backreference; [1] outside of the pattern.
> 
> See http://ruby-doc.org/core-2.1.1/Regexp.html#class-Regexp-label-Capturing

this is not a ruby question, the code in question is PUPPET DSL.

The DSL match function looks for a regex and returns what it finds and any
capture groups.

You access the 2nd item in the array as array[1]

if certname if hostname.domain.name

$matches = $trusted["certname"].match(/([^.]+)\./)

Here $matches will have ["hostname.", "hostname"]

and $matches[1] will fetch "hostname"

https://docs.puppet.com/puppet/latest/reference/function.html#match

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/2071316264.537951.1470322230272.JavaMail.zimbra%40devco.net.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Announce: Ruby 2.3 update planned for puppet-agent 1.6.0

[R.I.Pienaar]

- Original Message -
> From: "Francois Lafont" 
> To: "puppet-users" 
> Sent: Tuesday, 2 August, 2016 14:01:05
> Subject: Re: [Puppet Users] Announce: Ruby 2.3 update planned for 
> puppet-agent 1.6.0

> Hi,
> 
> On 02/08/2016 06:28, Geoff Nichols wrote:
> 
>>> 1. So it concerns gems installed via this command:
>>>
>>> /opt/puppetlabs/puppet/bin/gem install $gem_foo
>>>
>>> Is it correct?
>>>
>> 
>> Yes, that's correct.
> 
> Ok.
> 
>>> 2. And what about gems installed via this command?
>>>
>>> /opt/puppetlabs/bin/puppetserver gem install $gem_foo
>>>
>>> Is a re-installation after the upgrade needed too?
>>>
>> 
>> No, gems installed using Puppet Server's `puppetserver gem install`
>> subcommand use a separate (JRuby) interpreter. Those gems should not be
>> affected and should not require re-installation after the upgrade.
> 
> Ok.
> 
> Thanks for your answer Geoff. But, in this case, I don't really see the
> impact of this migration Ruby 2.1 => 2.3 in a classical "clients/server"
> architecture (I mean the impact for the _user_ because I imagine there are
> eventually impacts for the puppet-agent developer ;)).
> 
> For instance, I have installed hiera-eyaml but it's for the server
> (so I have made "/opt/puppetlabs/bin/puppetserver gem install hiera-eyaml").
> I have installed hiera-eyaml with the "puppet" command too, to just
> have the "eyaml" command in my PATH too (ie in /opt/puppetlabs/puppet/bin/)
> but it's just for convenience.
> 
> Another example: if I have ruby functions in my puppet modules, these
> functions are executed in the server side, so no impact too in this case,
> correct ?
> 
> In fact, where could be the "user" impacts of this change? The only thing
> I see is "custom facts" in modules which are Ruby code executed in clients
> side. Are there another things which I need to check carefully in the
> clients/server architecture?

There are still people who do not use puppetserver but passenger.  And many
who use apply only. 

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/937065163.388073.1470141878444.JavaMail.zimbra%40devco.net.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: Something wrong with classification and hiera

[R.I.Pienaar]

- Original Message -
> From: "Alex Samad" 
> To: "puppet-users" 
> Sent: Wednesday, 20 July, 2016 21:29:27
> Subject: [Puppet Users] Re: Something wrong with classification and hiera

> Hi
> 
> Very strange, edited hiera.yaml. ended up not makeing any changes -
> restarte puppet server
> 
> and it seems to be working !
> 
> sigh ...

yes, thats normal, do need to restart after editing it

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/1833606557.815646.1469064694463.JavaMail.zimbra%40devco.net.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: most idiomatic way to set resource defaults

[R.I.Pienaar]

- Original Message -
> From: "Matthew Pounsett" 
> To: "puppet-users" 
> Sent: Monday, 11 July, 2016 16:26:42
> Subject: [Puppet Users] Re: most idiomatic way to set resource defaults

> On Friday, 8 July 2016 04:27:26 UTC-4, Peter Faller wrote:
>>
>> Are you using the create_resources function to instantiate the resources?
>> It takes a third argument containing default values:
>>
>> $widgets = hiera('widgets', {})
>> $widget_defaults = hiera('widget_defaults', {})
>> create_resources(::widget, $widgets, $widget_defaults)
>>
> 
> I haven't go so far as to write that part yet, but I was thinking of
> something along those lines.   Because of the varying defaults, I would
> actually need to iterate over the customer names.
> 
> $widgets = hiera('widgets', {})
> $widget_defaults = hiera('widget_defaults', {})
> $widgets.each |String $customer, Hash $data| { create_resources( ::widget,
> $widgets[$customer], $widget_defaults[$customer] }
> 
> The problem I can't solve with this approach is that which customer's
> widgets I'm creating is actually an important attribute of the widget type,
> as it relates to where files get created, etc.  This is why I was wondering
> if there was a better way to organize the data in Hiera.  I considered
> reformatting the 'widgets' dictionary into a list so that the customer name
> is an attribute, not a key:
> 
> $widgets = hiera('widgets', [])
> $widget_defaults = hiera('widget_defaults', {})
> $widget_defaults.each |String $customer, Hash $defaults| {
>   $widget_data = $widgets.filter |$data| { $data['customer'] == $customer }
>   create_resources( ::widget, $widget_data, $widget_defaults[$customer])
> }
> 
> That gets repetitive and doesn't organize  as well, however.

I have a bunch of examples @ 
https://www.devco.net/archives/2015/12/16/iterating-in-puppet.php
something there might help, best avoid create_resources in puppet 4 :)

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/570045702.303862.1468247492252.JavaMail.zimbra%40devco.net.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] PQL Questions

[R.I.Pienaar]

> On 11 Jul 2016, at 00:39, Wyatt Alt <wy...@puppet.com> wrote:
> 
> 
> 
> 
>> On 07/10/2016 01:32 PM, R.I.Pienaar wrote:
>> hey,
>> 
>> Been playing with the PQL language and it's quite nice, have 2 questions.
>> 
>> I want to do a regex case insensitive match, docs mention you can do whatever
>> Postgres supports but I can't figure out how to do case insensitive matches
>> with PQL?
>> 
>> Postgres supports ~ and ~* operators but PQL only supports ~. So I suppose
>> I could match [aA][bB][cC] to get case insensitivity, but thats a tad ugly
> Hey R.I,
> 
> I agree -- the docs are incorrect here and if you link the page you're 
> looking at I'll change them. PuppetDB currently only supports postgres's ~ 
> operator, but I think adding support for ~* would be a good feature and 
> technically easy, so I've created 
> https://tickets.puppetlabs.com/browse/PDB-2861 to address it. For now your 
> hack is probably the best you can do.

Thanks. No if that's all you support the docs are correct. They mention it 
supports some marchers pgsql supports but I guess those are more related to the 
fact that it's the basic posix regex only and nothing fancy. 

>> 
>> Next I have a fact like:
>> 
>>   foo => { bar => ["a", "b", "c"]}
>> 
>> How do I search into that where bar contains "b"? There's an "in" operator
>> but I can't seem figure out both how to search inside the sub hash and also
>> how to match inside a array like that?
> Querying structured facts in PQL is still pretty inconvenient in some cases, 
> but you could do this with something like
> 
> fact_contents{path ~> ["foo", "bar", "\\d"] and value = "b"}
> 
> This can be inserted as a subquery to get the certnames associated with such 
> a value, e.g
> 
> nodes{certname in fact_contents[certname]{path ~> ["foo", "bar", "\\d"] and 
> value = "b"}}
> 
> Incidentally, we have two tickets in flight (PDB-2632 and PDB-2633) that will 
> enable the nicer syntax
> 
> inventory{facts.foo.bar.match("\\d") = "b"}
> 
> to do the same thing (subject to tweaking still but that's the gist of it). 
> These should be included in the next feature release, assuming no issues pop 
> up. Having some kind of explicit handling for array containment seems like an 
> interesting idea -- we'll have to give it some thought.

Right I think I can probably hack up what I need then with your suggestion. If 
I get it working I will open a docs ticket to get some examples added 

Thanks! PQL is a lot easier than the other format :) though there was some 
pretty frustrating times since it got hung up spaces around () and {} I will 
find my broken queries and open tickets about those too

Oh and the "puppet query" tool doesn't seem to be linked against SSL so 
couldn't get it to speak over https

I will look in the week if there are existing tickets as open some. Just wanted 
to get my back working before going to deep in jira. 


> 
> Wyatt
>> 
>> ---
>> R.I.Pienaar
> 
> 

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/60AFC812-6B30-41CA-B4BB-D24C9013111C%40devco.net.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] PQL Questions

[R.I.Pienaar]

hey,

Been playing with the PQL language and it's quite nice, have 2 questions.

I want to do a regex case insensitive match, docs mention you can do whatever
Postgres supports but I can't figure out how to do case insensitive matches
with PQL?

Postgres supports ~ and ~* operators but PQL only supports ~. So I suppose
I could match [aA][bB][cC] to get case insensitivity, but thats a tad ugly

Next I have a fact like: 

  foo => { bar => ["a", "b", "c"]}

How do I search into that where bar contains "b"? There's an "in" operator
but I can't seem figure out both how to search inside the sub hash and also
how to match inside a array like that?


---
R.I.Pienaar

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/1976388372.749138.1468182765788.JavaMail.zimbra%40devco.net.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Is it possible to gracefully exit the puppet agent run after sending facts?

[R.I.Pienaar]

- Original Message -
> From: "Peter Faller" 
> To: "puppet-users" 
> Sent: Friday, 8 July, 2016 10:29:56
> Subject: Re: [Puppet Users] Is it possible to gracefully exit the puppet 
> agent run after sending facts?

> Would 'puppet agent --test --noop' be an option?

in theory, but -noop will still take a long time because it processes the whole 
thing.

Also --noop is a terrible lier, it has many side effects, some disastrous.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/589269246.699.1467966735950.JavaMail.zimbra%40devco.net.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Is it possible to gracefully exit the puppet agent run after sending facts?

[R.I.Pienaar]

- Original Message -
> From: "Haani Niyaz" 
> To: "puppet-users" 
> Sent: Friday, 8 July, 2016 03:25:26
> Subject: Re: [Puppet Users] Is it possible to gracefully exit the puppet 
> agent run after sending facts?

> Not all but most of it. I guess the intention was to use the PuppetDB since
> that is already an existing data source. Pushing the info will require
> setting up some more infrastructure but I understand that it might need to
> happen. Thanks.

I think it's legit, why not, its facts, it's in the puppet world, puppet is 
pushing
ever more capable querying APIs and even designing custom query languages for 
exactly
this data, dashboards to view them already exist and other integrations pop up 
all 
the time like the recent Sensu one. you should be able to use it.

there might be a face to do this, maybe puppet facts, but I refuse to look at 
them 
they are so horrid, with terrible help output etc, so a ghetto solution:

FACTER_sync_facts=true puppet agent --test

check in your classification (node files or whatever) for the $sync_facts
fact and don't add any classes when "true"

It would probably be trivial to write a bit of code to do this too using the
existing Puppet APIs

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/373848585.434.1467961456633.JavaMail.zimbra%40devco.net.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] can create a top level variable in my enc

[R.I.Pienaar]

- Original Message -
> From: "Alex Samad" 
> To: "puppet-users" 
> Sent: Wednesday, 6 July, 2016 09:01:10
> Subject: [Puppet Users] can create a top level variable in my enc

> Hi
> 
> I have a bash script produce this for my test node
> 
> ---
> environment: production
> ybenv: alextest


---
environment: foo
parameters:
  ybenv: foo

https://docs.puppet.com/guides/external_nodes.html#parameters

> 
> 
> I have this in my hiera.yaml file
> :hierarchy:
> 
>  # node specific
>  - "nodes/%{::trusted.certname}"
> 
>  # OS specific
>  - "os/%{::osfamily}"
> 
>  # Envornment
>  - "ybenv/%{::ybenv}"
> 
>  # common to all
>  - common
> 
> 
> These are my hieradata files
> hieradata/
> hieradata/os
> hieradata/os/RedHat.yaml
> hieradata/nodes
> hieradata/nodes/testnode.yaml
> hieradata/common.yaml
> hieradata/ybenv
> hieradata/ybenv/alextest.yaml
> 
> 
> But this file doesn't seem to be getting read
> hieradata/ybenv/alextest.yaml
> 
> and tried doing some testing in my site.pp
> 
> tried this
> $ybenv=hiera('ybenv')
> info("Certname [${trusted['certname']}] OsName [${osfamily}] ybenv
> [${ybenv}] environment [${environment}]")
> 
> and also just this
> 
> info("ybenv [${ybenv}]")
> 
> and it the logs it say ybenv undefined
> 
> 
> 
> A
> 
> 
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email
> to puppet-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/0c3c410c-cad1-47e6-a017-3a177458bc8d%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/423813383.108961.1467788613580.JavaMail.zimbra%40devco.net.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Inconsistent MCollective plugins across platforms?

[R.I.Pienaar]

Packaging on ubuntu with PC1 is unfortunately broken, there was a recent
commit to fix this but I doubt anything has been released to fix it.

as for 'puppetd' agent vs 'puppet' agent, back in the dark ages you didnt
have 'puppet agent' but 'puppetd', thats a old agent to manage ancient puppet



- Original Message -
> From: "Peter Kristolaitis" 
> To: "puppet-users" 
> Sent: Monday, 4 July, 2016 20:30:31
> Subject: [Puppet Users] Inconsistent MCollective plugins across platforms?

> We're in the midst of upgrading from Puppet 3.8 to the latest PC1
> release, and I've found what seems to be inconsistent package behavior
> with MCollective plugins.
> 
> Background:  We have historically used 'mco puppet' and 'mco rpc puppet'
> to orchestrate multi-node application deployments.  We do basic system
> configuration using scheduled agent runs, but some resources are tagged
> such that they only run during our orchestrated deploys.  We run a mix
> of Windows and Linux (mostly Ubuntu, but recently we've had to support
> CentOS as well).
> 
> Getting the 'mco puppet' command is normally done by installing the
> mcollective-puppet-(agent|client) package.On CentOS, this works fine:
> 
> [root@pr01cw-sql01ny ~]# rpm -qa | grep puppetlabs-release
> puppetlabs-release-pc1-1.0.0-2.el6.noarch
> puppetlabs-release-6-12.noarch
> 
> [root@pr01cw-sql01ny ~]# yum install mcollective-puppet-agent
> Loaded plugins: fastestmirror
> Setting up Install Process
> Loading mirror speeds from cached hostfile
>  * base: mirror.trouble-free.net
>  * extras: repo1.ash.innoscale.net
>  * updates: mirror.solarvps.com
> Resolving Dependencies
> --> Running transaction check
> ---> Package mcollective-puppet-agent.noarch 0:1.11.0-1.el6 will be
> installed
> --> Finished Dependency Resolution
> ...(snip)...
>   Installing : mcollective-puppet-agent-1.11.0-1.el6.noarch 1/1
>   Verifying  : mcollective-puppet-agent-1.11.0-1.el6.noarch 1/1
> 
> Installed:
>   mcollective-puppet-agent.noarch 0:1.11.0-1.el6
> 
> Complete!
> 
> However, on Ubuntu:
> 
> root@pr00fc-pup01va:~# dpkg -l | grep puppetlabs-release
> ii  puppetlabs-release 1.0-12 all
> "Package to install Puppet Labs gpg key and apt repo"
> ii  puppetlabs-release-pc1 1.0.0-2trusty
> all  Release packages for the Puppet Labs PC1 repository
> 
> root@pr00fc-pup01va:~# aptitude install mcollective-puppet-client
> The following NEW packages will be installed:
>   libruby1.9.1{a} mcollective-common{a} mcollective-puppet-client
> mcollective-puppet-common{a} ruby{a} ruby-json{a} ruby-stomp{a}
> ruby1.9.1{a}
> 0 packages upgraded, 8 newly installed, 0 to remove and 0 not upgraded.
> Need to get 240 kB/2,926 kB of archives. After unpacking 14.1 MB will be
> used.
> The following packages have unmet dependencies:
>  puppet-agent : Breaks: mcollective-common (< 3.0.0) but
> 2.8.4-1puppetlabs1 is to be installed.
> The following actions will resolve these dependencies:
> 
>  Remove the following packages:
> 1) puppet-agent
> 2) puppetserver
> 
> Accept this solution? [Y/n/q/?]
> 
> So it appears that the dependencies are expressed differently between
> the two platforms -- works on CentOS, breaks on Ubuntu.
> 
> Somewhat even more confusingly, Ubuntu has another package called
> 'mcollective-plugins-puppetd' that appears to provide identical
> functionality (enable/disable/runonce/etc) that is not present on
> CentOS, and it is NOT compatible with the mcollective-puppet-* commands
> (i.e. issuing an 'mco puppetd' command from an mco client is ignored by
> an mco server that has the 'mco puppet' command available).
> 
> From what I've been able to tell,  mcollective plugins were in flux as
> part of the change to PC1, which is why you need to install both the PC1
> and legacy repositories to get some plugins.  But PC1 has been
> 'released' for quite a while and I was kind of expecting these sorts of
> issues to be sorted out by now.
> 
> Is there a good solution to this?  I'm at the point where I'm thinking
> of just ripping the Ruby file(s) out of one of the packages and managing
> it with a file{} resource and ditching packages completely, but if
> there's a better way to do this, I'd like to hear about it.
> 
> And of course, there are no packages for mcollective plugins available
> for Windows at all, as far as I can tell.  But that's a whole other
> issue.  ;)
> 
> Thanks,
> 
> - Peter
> 
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email
> to puppet-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/577AAB47.9010702%40alter3d.ca.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 

Re: [Puppet Users] Convert hiera_hash code to hiera_array?

[R.I.Pienaar]

- Original Message -
> From: "Carlos Parada" 
> To: "puppet-users" 
> Sent: Wednesday, 29 June, 2016 15:25:14
> Subject: Re: [Puppet Users] Convert hiera_hash code to hiera_array?

> Hi Henrik,
> 
> Yeah, updating to a newer version sounds like the sensible thing to do,
> lots of politics involved on this though :/
> 
> Will try to test updating to Puppet 4.5

word of caution, LOTS have changed from 2.x to 4.5. And lots of those will
be warned about in 3.latest.

Definitely recommend you use 3.latest to work out your issues and then going
to 4 which should be much easier.  As 4 will not warn you about things it will
raise errors.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/1503450711.689.1467207842186.JavaMail.zimbra%40devco.net.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] external node classifier my setup

[R.I.Pienaar]

>> I agree but how do you make them difference for different nodes, if I
>> specify a group of nodes that have a specific MOTD... the nodes don't
>> care but ( i was using it as an example). maybe a better one would be
>> say smtp setup - all nodes have it, non prod must point to the non
>> prod smtp server.

Environments is a very big hammer for whats basically a tiny nail you're 
describing.

Suggest you look to hiera instead for a solution.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/162870092.176.1466754501655.JavaMail.zimbra%40devco.net.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] CRL is not honored by the puppetmaster.

[R.I.Pienaar]

The CRL tends to only be read at startup by the web server. So restart and it 
should work - if non puppetserver you should have configured it correctly 
though 

---
R.I.Pienaar

> On 16 Jun 2016, at 05:38, Dan Mahoney <goo...@gushi.org> wrote:
> 
> Hey all,
> 
> This terrifies me.
> 
> As part of my certificate roll, I did, on my master:
> 
> root@pm:~ # puppet cert clean somehost.foo.org
> Notice: Revoked certificate with serial 43
> Notice: Removing file Puppet::SSL::Certificate somehost.foo.org at 
> '/var/puppet/ssl/ca/signed/somehost.foo.org.pem'
> Notice: Removing file Puppet::SSL::Certificate somehost.foo.org at 
> '/var/puppet/ssl/certs/somehost.foo.org.pem'
> 
> If I run it again, it re-revokes the cert, but of course there's nothing to 
> delete.  Doing puppet ca revoke somehost.foo.org also redoes the revocation.
> 
> However the agent happily continues to download catalogs.  (Or more 
> accurately, the master continues to hand them out).
> 
> I've verified that the cert is listed as revoked in *both* the host CRL as 
> well as the CA CRL, using the following:
> 
> openssl crl -inform PEM -text -noout -in /var/puppet/ssl/ca/ca_crl.pem
> 
> (where it's listed as 2B, because it's in hex, but the revoke date is right).
> 
> It's also in the host ca on the puppetmaster -- so the two places there's a 
> CA, it's listed with the right date.  There's only one place each of these 
> files can be pointed to in puppet.conf, so it's not possible that I've set it 
> to be written, but not actually used, is it?
> 
> -Dan
> 
> -- 
> 
> Dan Mahoney
> Techie,  Sysadmin,  WebGeek
> Gushi on efnet/undernet IRC
> ICQ: 13735144   AIM: LarpGM
> Site:  http://www.gushi.org
> ---
> 

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/6B30B7FE-23EE-482E-8331-6A09F4E39FE9%40devco.net.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Puppet environments..

[R.I.Pienaar]

- Original Message -
> From: "John Doe" 
> To: "puppet-users" 
> Sent: Thursday, 26 May, 2016 15:34:17
> Subject: [Puppet Users] Puppet environments..

> Hey,
> 
> I been stuck for a while with this now.
> 
> Thing is that I can't understand how tell puppetmaster to issue different
> environments for the agent. I see in Puppet Enterprise everything is
> explained very well and detailed, but in open source version everything
> looks very messy, there is no clear picture how things should look like.
> 
> The most confusing part here for me is that how to TEACH puppetmaster
> identify nodes and then assign them to appropriate environment?

you have 2 options, either on the node configure environment in the puppet.conf
or you must have an ENC that sets the node environment.

That's it, ENC docs @ https://docs.puppet.com/guides/external_nodes.html

If you're on latest Puppet you might like a prebuilt one I made @ 
https://forge.puppet.com/ripienaar/classifier

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/2049786089.219986.1464270890380.JavaMail.zimbra%40devco.net.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] puppet server 4: hiera set up?

[R.I.Pienaar]

- Original Message -
> From: "Rob Nelson" 
> To: "puppet-users" 
> Sent: Friday, 20 May, 2016 21:36:25
> Subject: Re: [Puppet Users] puppet server 4: hiera set up?

> Doug,
> 
> You could add --trace to see where it's looking. I would also try tossing
> something into common, which requires NO facts, to ensure base hiera
> functionality before moving on to tiers dependent upon fact values.
> 
> 
> Rob Nelson
> rnels...@gmail.com
> 
> On Fri, May 20, 2016 at 3:11 PM, dkoleary 
> wrote:
> 
>> Hey;
>>
>> Before dumping a bunch of data into hiera data files, I wanted to run a
>> quick check to verify functionality.  This seems to be set up so I'm
>> suspecting my test isn't valid.  Could someone take a peek and confirm for
>> me?
>>
>> This is the set up:
>>
>> # h
>> pm
>>
>> # puppet config print hiera_config
>> /etc/puppetlabs/puppet/hiera.yaml
>>
>> # cat /etc/puppetlabs/puppet/hiera.yaml
>> ---
>> :backends:
>>   - yaml
>> :hierarchy:
>>   - "hosts/%{facts.hostname}"
>>   - "environments/%{facts.environment}"
>>   - "host_env/%{facts.env}"
>>   - "os/%{facts.osfamily}"
>>   - common
>> :yaml:
>>   :datadir: /etc/puppetlabs/code/hieradata
>>
>> # facter hostname
>> pm
>>
>> # cat /etc/puppetlabs/code/hieradata/hosts/pm

my guess is this should be pm.yaml

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/344859018.727155.1463773353025.JavaMail.zimbra%40devco.net.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] How to Read New Files Dynamically with Hiera?

[R.I.Pienaar]

- Original Message -
> From: o...@soluto.com
> To: "puppet-users" 
> Sent: Monday, 18 April, 2016 13:45:58
> Subject: Re: [Puppet Users] How to Read New Files Dynamically with Hiera?

> I'm using git, but still, a single file is too messy. I will take a look at
> Jerakia.
> 

there is a HOCON backend for hiera https://github.com/cprice404/hiera-hocon
and HOCON supports including files into others, not sure if this will let
you do what you want but it's an option for staying with Hiera

> On Friday, April 15, 2016 at 3:03:39 PM UTC+3, Craig Dunn wrote:
>>
>>
>>
>> On Thu, Apr 14, 2016 at 4:34 PM,  wrote:
>>
>>>  Hi,
>>> We need to manage many keys in Hiera. Since many people should be able to
>>> edit the keys and in order to avoid a complete mess I was thinking to work
>>> with many different files. The problem is that I don't know how to make
>>> Hiera read from new files. I don't want to add each file to the hierarchy
>>> explicitly.
>>> Optimally I would add something like that
>>> /etc/puppetlabs/code/enironments/%{::environment}/hieradata/delegated/*
>>>
>>> and Hiera will just read from all files that are under the
>>> delegated
>>>
>>
>>
>> You could use Jerakia to do this (it can also be configured as a regular
>> hiera backend).  It supports fragments so if your hierarchy contains
>> "/delegated" then the presence of a directory called "delegated.d" will
>> automatically get checked and if present any files within it are
>> concatenated together along with delegated.yaml and returned as one YAML
>> document.  see the "Fragments" documentation in
>> http://jerakia.io/datasources/file/
>>
>>
>>
>>
> 
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email
> to puppet-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/2e420308-dc27-403e-81af-cd1ef23649ee%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/1480139089.213309.1460981952797.JavaMail.zimbra%40devco.net.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: puppet catalog compilation job queue idea

[R.I.Pienaar]

I believe the thing thats happening here is called Direct Puppet, there
were some puppet conf talks about this you might want to look at the videos.

But it's around reworking the compile flow so you can pre-compile things, re-run
earlier compiled things, redo the static catalogs and even rewriting the 
compiler
in C++

There are stuff happening on Jira at the moment, but I'd guess lots of this will
be PE only if recent blogs are anything to go by

- Original Message -
> From: "jcbollinger" 
> To: "puppet-users" 
> Sent: Tuesday, 8 March, 2016 15:51:31
> Subject: Re: [Puppet Users] Re: puppet catalog compilation job queue idea

> On Monday, March 7, 2016 at 7:57:33 PM UTC-6, SG Madurai wrote:
>>
>> Hi John, Thank you for the update.
>>
>> Pardon me if i am asking about things that have been clarified/ settled
>> already.
>>
>> From what i understand, agent run times are primarily determined by
>> - catalog compilation time at master
>> - the time for agent to apply catalog on its node
>>
>>
> 
> Both of those are contributors.  The former is rarely a major one.  There
> is also time spent by the agent computing facts, which is usually even
> less, but can be costly if costly custom facts are installed.
> 
> Also, catalog application often is not an agent-only activity, as it
> commonly involves the agent obtaining files from the master's file server.
> This can be very expensive for both the agent and the master.
> 
> 
> 
>> So was basically wondering if there is an option to separate these 2
>> functions and manage these 2 independent of each other (at times convenient
>> for each of these activities)
>>
>>
> 
> Nodes have as much control as they want to exercise of when and how often
> they perform catalog runs.  If they run the agent in daemon mode then they
> can configure the run interval, but they also have the option of running it
> at the times they choose via a scheduler, such as cron, or on-demand either
> manually or via a remote-control system such as MCollective.
> 
> The master does perform some caching to speed catalog building, but as I
> already said, it is impractical for it to cache whole catalogs for direct
> service to clients.  The problem here lies in determining accurately and
> efficiently when cached catalogs are stale.
> 
> 
> 
>> If these concerns shouldn't arise with running multiple puppet masters w/
>> puppet db (or by imply upgrading...we are on v3.8 btw), then will explore
>> that option first.
>>
> 
> 
> If your master(s) do not adequately serve the catalog request load, then
> the quickest solution is often to empower them by running more puppetmatser
> threads, adding CPU, adding RAM, increasing network bandwidth, and/or
> shutting down other services.  "Shutting down other services" might include
> moving PuppetDB to a separate machine.  Do also attend to the possibility
> of uneven load: some kinds of site configurations lend themselves to highly
> uneven load on the master, such that it sometimes gets transiently
> overloaded even though it has sufficient capacity for its average load.
> 
> If individual catalog compilations are taking a long time, then it is
> probably worthwhile investigating why that is.  It may well be the case
> that you can realize substantial improvements by modifying your manifest
> set.  If the master is bogged down at the file server then you are probably
> managing either large numbers of files or very large files, or both, in an
> inefficient way; this is an area where it is relatively easy to shoot
> yourself in the foot.
> 
> If none of those alternatives yield the catalog service bandwidth you need,
> then the next logical step is multiple masters.
> 
> 
>>
>> I couldn't be sure if these configuration options (multiple puppet masters
>> w/ puppet db) by itself can take care of the issues we are facing with
>> agent runs  in our environment
>> (timeouts, slowness..)
>>
>> We have one puppet master (v3.8) managing 150-200 nodes in an environment.
>>
> 
> 
> That's a fairly substantial load for a single master, but whether it's at
> or beyond the capacity you should expect depends greatly on your manifests,
> data, and nodes.
> 
> In any event, you started off in the wrong direction by asking about agent
> run times.  If agents' catalog requests are being serviced slowly, and
> especially if they sometimes time out, then your problem is likely to be an
> overtaxed master.  Long catalog-building times can contribute to that, but
> so can the overall number of requests, uneven load, competing jobs, and
> other factors.
> 
> 
> 
>>
>> BEFORE actually implementing this setup (multiple puppetmasters w/ puppet
>> db) in our environment, i wanted to see if this is all there is to do - to
>> fix these timeouts/ delays we see in our agent runs.
>>
>>
> 
> As with any optimization problem, you are best off proceeding in a manner
> that is informed by *data* about what parts of the 

Re: [Puppet Users] Template problems

[R.I.Pienaar]

- Original Message -
> From: "Ugo Bellavance" 
> To: "puppet-users" 
> Sent: Tuesday, 8 March, 2016 13:50:46
> Subject: Re: [Puppet Users] Template problems

> Just a thought, where should I have looked for that? Is it pure Ruby?

yeah pretty much, there are template docs but this I guess is just confusing.

If you're on recent puppet you should try epp templates, they are written
using the puppet language so less context changing

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/74543261.314464.1457442697474.JavaMail.zimbra%40devco.net.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Template problems

[R.I.Pienaar]

You can't nest the <% %> inside another. Try:

<%= if @rotatelogsuselink then "-L /var/log/httpd/#{@name}/access.log" end %>

Everything inside is normal Ruby and that's how interpolation works there

---
R.I.Pienaar

> On 8 Mar 2016, at 04:32, Ugo Bellavance <u...@lubik.ca> wrote:
> 
> > <%= if @rotatelogsuselink then "-L /var/log/httpd/<%= name %>/access.log" 
> > end %>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/DCC11E2D-E90A-4105-8806-BA73A897C620%40devco.net.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Syntax problem, if/case in class section for $hostname

[R.I.Pienaar]

- Original Message -
> From: "Denny Schierz" 
> To: "puppet-users" 
> Sent: Monday, February 15, 2016 2:33:47 PM
> Subject: Re: [Puppet Users] Syntax problem, if/case in class section for 
> $hostname

> hi,
> 
> in the last 5 min I was able to solve my problem. The problem was that I
> wanted to override a parameterized class .. my solution is is now:
> 
> class users::fbar::params {
> 
> if ($::hostname =~ /^devpc21+(\d+)./) {
>  $groups  = [ 'admin' ] }
> else {
> 
>  $groups  = [ 'devel' ] }
> }
> 
> class users::fbar (
>  $ensure  = present,
>  $groups  = $users::fbar::params::groups
> )
>  inherits  users::fbar::params
> 
> {
>   case $ensure {
> 
>  present: {
> users::add_user { fbar:
>comment=> 'Foo Bar',
>uid => 1024,
>groups  => $groups,
>shell   => '/bin/bash',
>yubikeyid   => 'cxx',
>require => Group[ $groups ],
> }
>  }
>  absent: {
> users::del_user { ['fbar' ]:
>managehome  => true,
> }
> 
>  }
>   }
> }
> 
> It seems to be impossible to use if/case/whatever as selector for a
> parameter.

Puppet has selectors for this purpose.

https://docs.puppetlabs.com/puppet/latest/reference/lang_conditional.html#selectors

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/871116132.285727.1455543495753.JavaMail.zimbra%40devco.net.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: Making a "role" fact work

[R.I.Pienaar]

- Original Message -
> From: "Gareth Humphries" 
> To: "puppet-users" 
> Sent: Friday, January 29, 2016 4:50:50 PM
> Subject: [Puppet Users] Re: Making a "role" fact work

> ENC is the end game, but we have legacy hosts this has to work on.  Right
> now I have site.pp which has a list of unpleasant regexes and an 'include
> role::' stanza for each.  I could put '$role= ;
> include role::$role' in each of them instead, but I would have to do that
> in every single case, which I'm trying to avoid.
> 
> External facts work, but not on the first run.  Because facts get loaded
> before catalog compilation, the host doesn't know what to set that fact to
> until it already has a catalog -  a little bit chicken-and-egg.
> If i'm relying on the role fact to get data out of hiera, I need that fact
> available first run or compilation will fail.

facts are available from first run.

Plugin sync happens first and then it requests a catalog including the newly
received facts.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/368899749.239293.1454082807346.JavaMail.zimbra%40devco.net.
For more options, visit https://groups.google.com/d/optout.