Re: [Puppet Users] puppetlabs-* forge modules and 'parser = future'

[Jason Antman]

Yeah. I found an error in the puppetlabs-mcollective module (
https://tickets.puppetlabs.com/browse/MODULES-1192) where it doesn't work
with "trusted_node_data = true", which per the docs is a 3.6.2 recommended
safe setting. When I was testing my fix, I made the mistake of running
specs with future parser enabled... and saw how horribly they failed.

IMO at least for official modules (and ideally for use by anyone
interested) there needs to be a single, centrally-managed list of puppet
versions and parameters that are tested against. I know I've seen a few
modules that still don't run specs with anything > 3.4.

On Thu, Sep 18, 2014 at 6:10 PM, Spencer Krum 
wrote:

> +1 for a plan for this
>
> On Thu, Sep 18, 2014 at 2:16 PM, Tim Skirvin  wrote:
>
>> I decided to try out 'parser = future' today, and the first thing
>> to fail was puppetlabs-apache, with errors along the lines of:
>>
>> Filepath:
>> /srv/puppet/env/puppet/modules/apache/templates/httpd.conf.erb
>> Line: 19
>> Detail: comparison of Float with String failed
>>
>> There's already a bug report for this[1], but that's not really
>> my point.  I'm curious as to the larger questions - when are the modules
>> supported by PuppetLabs in the Forge going to be ready for use with the
>> future parser?  And, when these modules are ready, how will we know?  Will
>> it be listed as compatible with 4.0.0?
>>
>> And until this is ready, is 'parser = future' doing much good?
>>
>> - Tim Skirvin (tskir...@fnal.gov)
>> --
>> HPC Systems Administrator / Developer
>> http://www.linkedin.com/in/tskirvin
>>USCMS-T1 Collaboration   Fermilab Scientific Computing
>>
>> [1] https://tickets.puppetlabs.com/browse/MODULES-910
>>
>
>
>
> --
> Spencer Krum
> (619)-980-7820
>
> --
> 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/CADt6FWOMjWQtszuwncC42Mgs%2BcBmuNF2tC8zyr%3DxdusXCObhFg%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/CAFt4V4mu1JBE7ade87hw%3DrkP0UTVwci0tfd9AX6cUJ43iRuwWQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: Generate Puppet manifiest from server

[Jason Antman]

IMO there's no sane way to do this automatically. What would it do, put
every file on the system into a module? The code certainly wouldn't be
properly modularized and parameterized, and would be a maintenance
nightmare.

On Thu, Sep 25, 2014 at 8:42 AM, Paul Tötterman 
wrote:

> Anyone knows if there is any possibility to generate a puppet manifiest
>> from a server to use it as a template to other servers?.
>>
>
> Take a look at BluePrint 
>
> Cheers,
> 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/75324e1c-9688-40c8-81ce-087531d9928d%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/CAFt4V4n9-MD1QiSUhYW8D%2BQOkRZ5XYznW4C-u6rE74SaJgwycA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] scaning n/w and finding puppet agent

[Jason Antman]

Not built-in to puppet, but this should be trivial to do with nmap or a
similar tool and a list of the nodes that *are* running puppet.

On Fri, Sep 26, 2014 at 10:35 AM, kaustubh chaudhari 
wrote:

> Hi,
>
> Just had a though if this is possible. I have seen this feature in HPSA.
>
> Is there a way to scan the n/w and find the nodes who dont have puppet
> installed on them ?
>
> -Kaustubh
>
> --
> 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/1fb69b4a-1ab8-49d5-b556-1541e2ac7e97%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/CAFt4V4m9%3DZ%2BiDwSZSBnwMwZnP2TWhM6wNhWnmTUArr9jHj4ewg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: facter error message - what does this mean?

[Jason Antman]

What facter versions are you running?

On Fri, Sep 26, 2014 at 6:02 AM, kaustubh chaudhari 
wrote:

>
> Hi,
>
> I am also facing same issue. unable to find where to look for, puppet
> agent runes file facter runes fine if run manually.
>
>
> But schedule run still not working.
>
> Any help is appreciated.
>
> FYI: This happened after upgrade from 3.3.2 to 3.6.2
>
> -Kaustubh
>
> On Wednesday, September 24, 2014 8:16:54 AM UTC-4, JonY wrote:
>>
>> I'm seeing this error appear on a client machine (/var/log/syslog):
>>
>>  puppet-agent[17158]: Failed to apply catalog: Could not retrieve local
>> facts: Invalid facter option(s) type
>>
>> If I run 'puppet agent --test' it runs fine.
>>
>> If I run 'puppet agent --test --debug' there is no mention of this error.
>>
>> Yet if I wait until the next scheduled run the error will reappear.
>>
>>
>> What's going on?
>>
>  --
> 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/30f04d48-b51c-4360-9a1c-feb205438639%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/CAFt4V4mBpu0JFDxpEPfJuv6ora5%3DwihrQBsvKBfgYBJvx%2B%2BfZA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Basic Pupet Managed Hiearchies

[Jason Antman]

With a very small edge-case asterisk (the puppet Device support, which I've
never used), yes. The agent is a piece of software that runs (as a daemon,
via cron, manually, or via some other scheduling mechanism like
mcollective) on a host ("node" in Puppet nomenclature) and applies catalogs
to that one node.

There's a good introduction to this at
https://docs.puppetlabs.com/learning/agent_master_basic.html - I'd also
encourage you to look through the rest of the Learning Puppet section on
docs.puppetlabs.com.

On Sat, Sep 27, 2014 at 12:23 PM, Dennis Gearon  wrote:

> Thanks Jason. If I ever get to 1000 nodes, then I guess I'll have
> something to worry about, then. LOL! One final question.
>
> An 'agent' is really a managed server instance, not a Puppet worker
> managing something else, (as the word 'Agent' would suggest). So really,
> Agents only apply catalogs to themselves, right?
>
> On Sat, Sep 27, 2014 at 9:07 AM, Jason Antman 
> wrote:
>
>> Agents never control other agents. Aside from supporting technology
>> (PuppetDB, an ENC if you have one, a database to back PuppetDB), yeah, a
>> master and N agents is the gist of it.
>>
>> There are some docs online (see specifically the "Tuning and Scaling"
>> section of the Puppet Documentation Index,
>> https://docs.puppetlabs.com/puppet/#tuning-and-scaling ) about scaling,
>> and a search of the mailing list archives (as well as Google - there have
>> been quite a few blog posts on this) should help turn up other options and
>> experiences.
>>
>> Off the top of my head, I believe there are generally two paradigms used:
>> either clustering/HA for your masters, generally load-balanced from what I
>> gather, or (what I do) splitting up agents between different masters (by
>> location, or network, or dev/test/prod). My current infrastructure is made
>> up of ~450 nodes which are served by three masters - dev, test/QA and prod.
>> We run every 30 minutes, via mcollective with a set concurrency. The
>> masters are VMs, running on the same physical hosts as PuppetDB and its
>> PostgreSQL instance, so I'm quite confident that I could scale each one to
>> a few thousand nodes before I have to worry about overloading one host. In
>> addition, since we split dev, test/QA and prod masters, we can deploy
>> module changes (and puppet/puppetdb/etc. upgrades) to the dev environment,
>> validate there, promote to test/QA, validate there, and then promote to
>> prod.
>>
>> -Jason
>>
>> On Sat, Sep 27, 2014 at 11:03 AM, Dennis Gearon 
>> wrote:
>>
>>> Been burnnig up the keyboard and spewing packets to search for this
>>> answer, but haven't seen it.
>>>
>>> From what I've read, there is only:
>>>   A/ A Puppet Master
>>>   B/ Infinite number of 'Agent' nodes.
>>>
>>> Is this right?
>>>
>>> Is there any other kinds of nodes?
>>>
>>> Do Agent nodes ever control other nodes?
>>>
>>> What happens when the puppet master gets overloaded, how do you cluster
>>> or use a 'super' master to divide the load?
>>>
>>> Thanks for clearning this up for 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/4c6dde8c-d82e-4159-85a0-6fe4cc7aeb04%40googlegroups.com
>>> <https://groups.google.com/d/msgid/puppet-users/4c6dde8c-d82e-4159-85a0-6fe4cc7aeb04%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>  --
>> 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/AdEjg1IBGUc/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/CAFt4V4%3DkTtL1O8JNeKLidmLpym61q8DYdPmVy4rJTa%2BOJLV_0g%40mail.gmail.com
>> <https://groups.google.com/d/msgid/puppet-users/CAFt4V4%3DkTtL1O8JNeKLidmLpym61q8DYdPmVy4rJTa%2BOJLV_0g%40mail.gmail.com?utm_medium=email&utm_so

Re: [Puppet Users] Re: Puppet facts uploading to PuppetDB

[Jason Antman]

Hmm... I didn't even know this existed. Ironically, given your question, it
sounds like something I'd want to use. But if it's going away, I guess I'll
just totally forget that I heard it...

Use case: We still have a bunch of legacy systems that aren't puppetized
and probably never will be (lots of "base" stuff that we do on "every" host
that would break these snowflakes). For everything else, PuppetDB is our
one and only inventory system. These legacy boxes exist only in a...
spreadsheet. If I knew there was a way to get facts from them into PuppetDB
without risking what would happen with a full puppet run, I probably
would've done it by now...

-Jason

On Fri, Sep 26, 2014 at 1:36 PM, Chuck  wrote:

> We are pushing facts into puppetdb for initial loads so that we can track
> system loads before puppet runs the first time.
>
>
> On Friday, September 26, 2014 12:26:09 PM UTC-5, Ken Barber wrote:
>>
>> Do many people use or care about the ability to upload facts out of
>> band to PuppetDB from a machine without the need for a full catalog
>> compilation? Its not a highly documented facility, ie. doesn't work
>> out of the box without configuration changes, but I know some people
>> have asked me this on IRC etc.
>>
>> If you are using this facility, are you running masterless or with a
>> puppet master out of curiosity? Also - why are you using this
>> facility, what does it give you - what problems are you trying to
>> solve beyond just relying on the facts from a catalog compilation?
>>
>> I'm just curious because some of this functionality is changing in a
>> future Puppet (basically it will stop working), trying to determine
>> whether its worth the time to port this functionality over to
>> something new. Or whether we should promote a new project outside of
>> the PL core items to do this (like a new module or plugin for
>> example).
>>
>> ken.
>>
>  --
> 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/c94810dd-3e34-44db-bc63-bd6efa9d7df5%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/CAFt4V4nYogKicaHXyw2g%3DqaJnja7c_rukmWnV4Hg3zYUetjgEw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Arbitrary facts - Best practices?

[Jason Antman]

IMO...

The "right" way to do this is to use a parameterized class in your module
that generates the config files.

Beyond that, it's up to you how you set that parameter to the correct value
for a node - you could use Hiera, you could use an ENC, or if you still
have a small setup and are using node manifests or some such, you could
just declare the class with the appropriate parameter there.

On Fri, Sep 26, 2014 at 4:15 PM, Christopher Wood <
christopher_w...@pobox.com> wrote:

> On Fri, Sep 26, 2014 at 01:00:44PM -0700, Ciro Iriarte wrote:
> >El viernes, 26 de septiembre de 2014 15:21:19 UTC-4, Christopher Wood
> >escribió:
> >
> >  In your place I'd add a level to my hiera setup and template the
> bird
> >  config.
> >
> >  There's a number of different options you could use to classify
> which
> >  node is in which site, from the node yaml in hiera to an ENC to a
> fact
> >  provisioned when the host is built.
> >
> >Currently I'm running 1 puppet slave for tests and a master. Hiera is
> not
> >(yet?) in the mix, whatever that is O_o'
> >I assume this is a basic setup and I'm missing components, which are
> the
> >components expected in a current Puppet 3 implementation?
>
> I couldn't say what's expected since requirements vary. For hiera take a
> look at:
>
> https://docs.puppetlabs.com/hiera/1/configuring.html
>
> Other things you may be interested in as you grow, see docs.puppetlabs.com
> for details:
>
> ca puppetmaster
> non-ca puppetmasters at each location for catalog compilation
> roles/profiles (http://www.craigdunn.org/2012/05/239/)
> git to store your manifests
> puppetdb
> mcollective
> ENC of some kind
> custom facts
> https://forge.puppetlabs.com/
> hiera-eyaml or similar https://github.com/TomPoulton/hiera-eyaml
>
> (The list rather goes on and on, you seem to be doing just fine without
> most of this. They're still available should you need them.)
>
> --
> 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/20140926201521.GA12027%40iniquitous.heresiarch.ca
> .
> 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/CAFt4V4k8A3M6GQaL16eV6iJ2xneBaKgBYJ0SBDdggiZ2dt%3D8Tg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Basic Pupet Managed Hiearchies

[Jason Antman]

Agents never control other agents. Aside from supporting technology
(PuppetDB, an ENC if you have one, a database to back PuppetDB), yeah, a
master and N agents is the gist of it.

There are some docs online (see specifically the "Tuning and Scaling"
section of the Puppet Documentation Index,
https://docs.puppetlabs.com/puppet/#tuning-and-scaling ) about scaling, and
a search of the mailing list archives (as well as Google - there have been
quite a few blog posts on this) should help turn up other options and
experiences.

Off the top of my head, I believe there are generally two paradigms used:
either clustering/HA for your masters, generally load-balanced from what I
gather, or (what I do) splitting up agents between different masters (by
location, or network, or dev/test/prod). My current infrastructure is made
up of ~450 nodes which are served by three masters - dev, test/QA and prod.
We run every 30 minutes, via mcollective with a set concurrency. The
masters are VMs, running on the same physical hosts as PuppetDB and its
PostgreSQL instance, so I'm quite confident that I could scale each one to
a few thousand nodes before I have to worry about overloading one host. In
addition, since we split dev, test/QA and prod masters, we can deploy
module changes (and puppet/puppetdb/etc. upgrades) to the dev environment,
validate there, promote to test/QA, validate there, and then promote to
prod.

-Jason

On Sat, Sep 27, 2014 at 11:03 AM, Dennis Gearon  wrote:

> Been burnnig up the keyboard and spewing packets to search for this
> answer, but haven't seen it.
>
> From what I've read, there is only:
>   A/ A Puppet Master
>   B/ Infinite number of 'Agent' nodes.
>
> Is this right?
>
> Is there any other kinds of nodes?
>
> Do Agent nodes ever control other nodes?
>
> What happens when the puppet master gets overloaded, how do you cluster or
> use a 'super' master to divide the load?
>
> Thanks for clearning this up for 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/4c6dde8c-d82e-4159-85a0-6fe4cc7aeb04%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/CAFt4V4%3DkTtL1O8JNeKLidmLpym61q8DYdPmVy4rJTa%2BOJLV_0g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Announce: Puppet Server 0.2.0

[Jason Antman]

FWIW,

(1) at my current shop, there's an immense hatred of everything JVM. That's
going to be a hard transition. Not to mention Puppet is the only place we
run Ruby, so it's nice and easy to let puppet do whatever it wants with
Ruby. Not so much for installing JVMs that may break production (improperly
configured and installed, I'll grant) applications.

(2) I've gotta say, I'll really miss dropping log statements directly in
the puppet source when something seems wonky (and not having to compile
something).

On Fri, Sep 26, 2014 at 7:42 PM, Felix Frank <
felix.fr...@alumni.tu-berlin.de> wrote:

>  On 09/26/2014 11:12 PM, Rob Reynolds wrote:
>
>   Felix, if your "what?" is about Java (the language), that was a
>> mistake. JVM on the server side, generally written in Clojure, is the
>> direction things are heading. C++ on the client side. Ruby is still
>> sticking around in order to support extensions. That said, some things
>> we'll need to discuss and figure out what the best way to move forward is.
>> Luke wrote up a good post about some of these changes at
>> http://puppetlabs.com/blog/evolving-puppet-for-next-ten-years
>>
>>  As I said in my original response about apply, that is something that
>> we still need to figure out and something that will be coming up on
>> puppet-dev in the future. There is a lot to consider and discuss in that
>> decision because of the number of people and systems affected.
>>
>
>  Yes, apologies about that. I meant JVM, generally written in Clojure. I
> was using language from the original statement from Trevor and should have
> been more clear.
>
>
> Thanks guys, I should have been more specific in my wild exclamation :-)
>
> I'm good with JVM, but C++ feels like a backward step in many regards. My
> judgment here may be clouded by reading too many blogpost of them naysayers.
>
> --
> 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/5425F9F9.4010501%40Alumni.TU-Berlin.de
> 
> .
>
> 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/CAFt4V4kJjGLm_YMdujSuQq81YcQMPceQhSZEwddSXo4YXwJesg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Script to track orphaned resources

[Jason Antman]

Two things that I've come across that help this situation:
- for new modules, rspec tests
- for existing modules, https://github.com/ripienaar/puppet-catalog-diff -
I generate a catalog with the new and old branch, then diff them


On Fri, Aug 22, 2014 at 9:34 AM, Martin Langhoff 
wrote:

> For context... Our puppet setup is complex, with many behaviors controlled
> by facter facts, in part controlled by a .INI file that support personnel
> can edit. We manage thousands of VMs.
>
> So unit tests are interesting but offer very limited coverage. Tracking
> orphans on live nodes is much more comprehensive. In particular it catches
> things folks haven't thought about.
>
> For example, a node had a class webserver applied. For whatever (bad)
> reasons that class is no longer applied... hey this node has apache
> installed and running, but now unmanaged! We sure as heck want an alert
> over that.
>
> Any long-term puppet infra has high risk of orphaned resources. There's so
> many ways this can happen.
>
> cheers,
>
> m
> On Aug 21, 2014 6:08 PM, "Garrett Honeycutt" 
> wrote:
>
>> On 8/21/14 5:45 PM, Manuel Quiñones wrote:
>> > Hello,
>> >
>> > I'm working on a utility script to track orphaned resources.  With
>> > orphans I mean: resources that were previously managed by Puppet, but
>> > they no longer are.  I want to track those while I do a refactor in my
>> > manifests.
>> >
>> > Here is the script I wrote:
>> >
>> > https://gist.github.com/manuq/eec269ce7ba00974f46e
>> >
>> > It is based on some assumptions, and here is my question: are these
>> > assumptions correct?
>> >
>> > - Puppet generates the following files on each run, even when called
>> > with --noop:
>> > - last_run_report.yaml: contains the resources currently managed, in
>> > full detail (serialized Puppet objects)
>> > - state.yaml: contains the resources Puppet ever managed since the file
>> > was created, only their name and some timestamps "checked" and "synced"
>> > - last_run_summary.yaml: among other things, contain the timestamp of
>> > the run, and the total time it took
>> >
>> > Based on that, I have two methods that output the orphans:
>> >
>> > Method 1: use state.yaml and read the "checked" timestamp. If it was not
>> > checked in the last run, then it is an orphan.
>> > Method 2: orphans are the subset of resources that are contained in
>> > state.yaml and are not contained in last_run_report.yaml.
>> >
>> > Critics and suggestions welcome.  Also I hope this can be useful to
>> others.
>> > Cheers,
>> >
>> > PS Note that this topic was discussed earlier in May.  I took it as
>> > initial reference:
>> >
>> https://groups.google.com/forum/#!searchin/puppet-users/orphan/puppet-users/ghKfRBkPD5A/m7KTeymd2XwJ
>>
>> Hi Manuel,
>>
>> Your plan is quite clever though if your goal is to refactor your puppet
>> modules and not leave anything out, spec tests are the way to go.
>>
>> http://rspec-puppet.com/tutorial/
>>
>> Best regards,
>> -g
>>
>> --
>> Garrett Honeycutt
>> @learnpuppet
>> Puppet Training with LearnPuppet.com
>> Mobile: +1.206.414.8658
>>
>> --
>> 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/53F66DE9.4020705%40garretthoneycutt.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/CACPiFCJsMK0oOMOZH6WcL27VDk3At3Dz8Pp1Q2o27zPv%2BsmvaQ%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/CAFt4V4%3DOnD7rR%3DshuCTV2csVnP%2BFmH1VPSnGHbKpTvnuhXeAFg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] is it possible to run agent with negated tag?

[Jason Antman]

There's at least one open issue for this,
https://tickets.puppetlabs.com/browse/PUP-1376
It doesn't appear to have much interest, so I doubt it will get much
attention.

-Jason


On Thu, Aug 14, 2014 at 6:25 AM, Maciek Jackowski 
wrote:

> is it possible to run agent with negated tag?
> for example
> puppet agent --verbose --no-daemonize  --runinterval=30  --tags
> !negated_tag
> of course above is not working
>
> i want to simply compile and run puppet catalog without specific
> negated_tag tagged resources
>
> regards
>
>  --
> 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/3760960d-95b9-4725-b6bc-8e3dd9d6d968%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/CAFt4V4nruzU_fngtNWroVGMqtEWfdwN9wU0Px5kfNJi0xo7pKQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Challenge: who am i and what do i do

[Jason Antman]

Agreed with Atom...

I generally think that this method is backwards. The system shouldn't tell
Puppet what it wants to be; Puppet (possibly fed by some external data
source(s)) should tell the system what to be. Sure, in some very large
environments with a small number of possible configurations, the other way
around will work. But why do something like tie your entire CM system to a
hostname convention?

-Jason


On Wed, Aug 27, 2014 at 1:35 AM, Atom Powers  wrote:

> DHCP + CMDB + ENC will get you there. (Foreman is an easy CMDB for Puppet.)
>
> DHCP answers "Where am I?" and "Who am I?"
> CMDB + ENC answers "What am I supposed to do?"
>
>
> On Tue, Aug 26, 2014 at 12:41 PM, Alex Demitri 
> wrote:
>
>> Hi guys - i am fairly new to puppet and i am trying to figure out ways to
>> implement it in my organization to make good use of it. One thing we
>> thought would be useful to better our deployment process, is to add a
>> mechanism that would have a vanilla server getting installed on a VM, boot
>> up, check into puppet and figure out these three questions:
>>
>> 1) Where am I?
>> - in what Datacenter/Availability zone am I? Based on that, what
>> syslog servers do i have to use, NTP servers, etc..
>> 2) Who am I?
>> - what server am i? What files do i need for basic functions?
>> 3) What am I supposed to do?
>> - based on what server I am, what am i supposed to do? do i have to
>> run Tomcat? Apache? And if yes, where are my configuration files?
>>
>> In short, find a holistic way for a system to come up to speed by itself.
>> I already thought of using meaningful hostnames for the roles of the
>> servers but that does not work well in the cloud...
>>
>> Thoughts?
>>
>> Thanks!
>> Alex
>>
>> --
>> 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/16a1cb0c-ab6d-4578-a221-482a86d05130%40googlegroups.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> Perfection is just a word I use occasionally with mustard.
> --Atom Powers--
>
> --
> 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/CAF-H%3DOm_0G3-VWnnjK5F6VD-rwQd8mtfQbnnkR_VKb0uYrmssQ%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/CAFt4V4nerNymn486%3DvS1g%3DDBJjPjR5YWBvZfnSSpqbzxTkO7OA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: Puppet logging agent/master

[Jason Antman]

FWIW,

1) for logging, we use ELK. We tried Splunk... the quote they gave us was
somewhere around our entire annual software budget. Also, it's closed
source.

2) We don't do anything with logs, aside from the few times we need to
manually confirm something. We rely on reports (PuppetBoard, and some
custom code around PuppetDB) for run analysis.

-Jason


On Sun, Aug 31, 2014 at 1:20 PM, Walid  wrote:

> Hi Martijn
>
> are you using the logstash reporter
> https://github.com/logstash/puppet-logstash-reporter , would it be
> possible to share your puppet kibana dashboards, and logstash.conf file
>
> regards
>
> Walid
>
>
> On 27 August 2014 19:54, Martijn  wrote:
>
>> We still use Puppet Dasboard (with PuppetDB) to get a quick overview of
>> the state of nodes and the logs of their Puppet runs. Not very fancy and a
>> little hard to search, but it works well as a read-only dashboard.
>>
>> Furthermore we use the ELK-stack (Logstash, Elasticsearch, Kibana) (See
>> http://www.elasticsearch.org/overview/), which is essentially an
>> open-source alternative to Splunk, to ship all logs from each host via a
>> queue to a central server, where they're normalized, processed and stored
>> in Elasticsearch. I've created several dashboards in Kibana that query that
>> data to graph metrics and show anomalies, not just for Puppet runs. I'd
>> prefer to add some active alerting to this pipeline, but have yet to figure
>> that out.
>>
>> There are many ways to do this, but this works pretty well for us.
>>
>> Regards, Martijn
>>
>>
>> Op dinsdag 26 augustus 2014 19:34:51 UTC+2 schreef Mike Reed:
>>
>>> Hello all,
>>>
>>> I've recently been looking into various methods for configuring
>>> meaningful logging from my puppet 3.6 master/agent nodes.  I've typically
>>> gone the route of grep'ing through syslog on both master/agents and I'd
>>> like something a little more robust and user friendly for other who may not
>>> be hip on going through hundreds of lines of syslog information in addition
>>> to a simpler design.
>>>
>>> I've recently been playing with an agent's puppet.conf and simply trying
>>> to set the logdir using this with no success at all (permissions have been
>>> changed to allow puppet to write to that directory):
>>> [agent]
>>> logdir=/var/log/puppet
>>>
>>> I've also tested syslog facility configurations but after some time, it
>>> seemed like having to modify multiple configuration files to get puppet
>>> logging consistent, seems a bit bulky to me.
>>>
>>> I suppose I have two questions:
>>>
>>> 1.  Is there a simple way to push messages to a file other than
>>> /var/log/syslog on an Ubuntu machine?
>>> 2.  Is there a preferred way in the community by which people aggregate
>>> logs to make troubleshooting nodes issues easier to manage?
>>>
>>> Thank you all for your time in advance.
>>>
>>> Cheers,
>>>
>>> Mike
>>>
>>  --
>> 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/59be2841-9cf1-49cd-ac2d-d219db0e2c38%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/CAN4dctqzWsG9DJs0X635yqTv34KRbmgcjH5eJPB0TwHVwcVVFg%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/CAFt4V4%3DD3T__H1-BRKnQTUiEv1EDgEcHE0boZ-rrRe2QWW7J%2BQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Offline facts

[Jason Antman]

The few times I've had to do things like this (like pulling information
from a physical inventory database to find the rack a host is in, for
monitoring) I've just cached the fact value on disk, usually using some
sort of mtime-based TTL. That being said, I've only done this for facts
that are "optional", i.e. if the fact isn't present, something won't be set
but it won't affect the actual operation of the system.

-Jason


On Thu, Sep 4, 2014 at 12:26 PM, jcbollinger 
wrote:

>
>
> On Wednesday, September 3, 2014 11:32:54 AM UTC-5, Khoury wrote:
>>
>> Sorry for the delay Felix. Here's a specific example of a situation where
>> the fact might return what I would consider useless information and I would
>> want to revert back to a the value set previously:
>>
>> On OS X you can have an active user that is at the console and owns
>> /dev/console. If you want to gather that information it's fairly
>> straightforward. But under certain circumstances the owner of the console
>> is root. In that scenario I'd still want the data set on the fact prior to
>> that to persist. My thinking is that I can just validate the data returned
>> (within the plugin itself) and if it doesn't meet my criteria, I can set
>> the fact to itself using Facter.value(console_user).
>>
>>
>
> As long as you intend to perform the validation inside the fact
> implementation, the fact can keep and use its own cache somewhere on the
> system.
>
> Alternatively, the master stores the most recent set of facts provided by
> each node, and it can be accessed via the REST API
> .  You could
> conceivably use that as a fact cache.
>
> Overall, however, it is probably a poor idea to compute or rely on node
> facts that reflect the dynamic state of the system, as opposed to its
> (semi-) stable configuration.
>
>
> John
>
>
>
>>
>> On Fri, Aug 29, 2014 at 9:04 AM, Felix Frank > de> wrote:
>>
>>> On 08/28/2014 11:01 PM, Khoury Brazil wrote:
>>> > I currently have it written to reuse the data using Facter.value()
>>> after
>>> > validation but wanted to make sure there wasn't something standardized
>>> > that I missed.
>>>
>>> Can you provide an example of that? I don't really see what you did
>>> there.
>>>
>>> --
>>> 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/5400A4A4.5020406%40alumni.tu-berlin.de.
>>> 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/7eea2790-537d-45c6-8ee5-d6eb6588e895%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/CAFt4V4kZTQz3uVYN0nTgoqFu-PbZf6EW8Q1u_6kfe4Nb%3D2vkPw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] How to make puppetlabs_spec_helper ignore modules inside fixtures

[Jason Antman]

Seb,

I actually *just* came by a very similar issue myself. The examples at
http://murphyslaw.github.io/blog/2012/04/06/run-specs-excluding-integration-specs/
should help you.

-Jason


On Wed, Aug 13, 2014 at 8:42 AM, Jason Antman  wrote:

> Seb,
>
> You really shouldn't be running specs for dependent modules.
>
> (1) If I were you, I'd really use the spec helper, and garethr's module
> skeleton - https://github.com/garethr/puppet-module-skeleton
> (2) looking at your code, you should just be able to
> t.pattern = 'spec/(classes|defines)/*_spec.rb'
>
> -Jason
>
>
> On Tue, Aug 12, 2014 at 2:47 PM, Sebastian Otaegui 
> wrote:
>
>> Hello all,
>>
>> I have created this module:
>>
>> https://github.com/Spantree/puppet-thrift and everything worked fine all
>> specs ran fine.
>>
>> Now I using the puppetlabs/apt module and when I run the 'rake spec' it
>> is trying to run the 'apt' tests, and it is failing (I think) because I am
>> not providing the appropriate facts.
>>
>> Is there a way to ignore the rspecs inside the fixtures/modules/
>> directory?
>>
>> I tried to do this:
>>
>> require 'rake'require 'rspec/core/rake_task'
>>
>> RSpec::Core::RakeTask.new(:spec) do |t|  t.pattern = 'spec/*/*_spec.rb'end
>>
>>
>>
>> But it didn't work.
>>
>> Can anybody point me in the right direction here?
>>
>> Thanks in advance,
>> Seb
>>
>> --
>> 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/1d7b8768-0e72-40c3-97f7-623d08f028ac%40googlegroups.com
>> <https://groups.google.com/d/msgid/puppet-users/1d7b8768-0e72-40c3-97f7-623d08f028ac%40googlegroups.com?utm_medium=email&utm_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/CAFt4V4mukbYuwbB3iY9pLAJsMNRQE6RGk5VY_yLeC-BKiAv05w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] jenkins workflow

[Jason Antman]

(1) a compile test is good, really good. make sure cheap tests happen first
(and fail fast) before expensive ones.
(2) I have a strong bias for having the automated jobs just run "bundle
exec rake test" or something like that, so that you can use the same job
for multiple modules


On Thu, Aug 7, 2014 at 8:11 AM, Nick Cammorato 
wrote:

> Pre-commit hooks are great but Github and github enterprise won't enforce
> them(arbitrary code on the server is uncool for some reason), so if you
> want to be 100% and use either they still need to be run as part of your
> jenkins build task.
> On Aug 6, 2014 7:11 PM, "John Warburton"  wrote:
>
>> On 7 August 2014 02:17, Bernard Clark  wrote:
>>
>>> I'm setting up a jenkins server to perform continuous integration on my
>>> puppet codebase, and I'm interested in running at least the following tests:
>>>
>>>- puppet parser validate
>>>- puppet lint
>>>
>>> These are cheap to do. Give yourself immediate feedback by making them
>> pre commit hooks -
>> http://puppetlabs.com/blog/how-set-git-commit-hooks-puppet-enterprise
>>
>>>
>>>- rspec-puppet
>>>- test-kitchen
>>>
>>> Have I overlooked any other worthwhile tests, and has the community
>>> distilled any wisdom about best practices, particularly regarding git
>>> workflow? Any advice would be much appreciated!
>>>
>> Look at server spec as well - http://serverspec.org/
>>
>> 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/CAAJLFxV%2BmR%3D88Wkh-GXYqOuZdboXdH2YTV%3DtAM47n0yUVNegKQ%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/CAKJ8awdGpfA7Ox9TbYqgdfOwLMax-2mTqvQZ1PpxKZjToGnZWw%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/CAFt4V4%3DDAG8GsnzvYDXc9xKWKpTdUgq-Jc67eQ%2BGPwwwYa0Rqg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Puppet's yumhelper.py vs. other pythons on the system

[Jason Antman]

So... there *is* a bug open that relates to this,
https://tickets.puppetlabs.com/browse/PUP-2144 (and by extension
https://tickets.puppetlabs.com/browse/PUP-1362 which appears to be being
worked on, and would fix this).

I don't know if that should work, and I honestly don't know how to set a
global path for Puppet. I can think of a few options:
(1) set the path wherever you run puppet from (cron, init script if daemon,
etc.)
(2) change the ordering in the default root path
(3) wait for one of the above tickets to be fixed and released

That being said, for future reference, it's generally (I know some will
disagree) bad practice to install a non-system-compatible Python in a
globally-used path.


On Wed, Aug 6, 2014 at 5:24 PM,  wrote:

> When trying to add packages to a CentOS 6 system I am getting chronic
> errors of the form:
>
> Error: Could not get latest version: Execution of '/usr/local/bin/python
> /usr/lib/ruby/site_ruby/1.8/puppet/provider/package/yumhelper.py' returned
> 1: 
>
> Error: /Stage[main]/Jenkins_packages::Centos/Package[subversion]/ensure:
> change from 1.6.11-10.el6_5 to latest failed: Could not get latest version:
> Execution of '/usr/local/bin/python
> /usr/lib/ruby/site_ruby/1.8/puppet/provider/package/yumhelper.py' returned
> 1: 
>
>
> whether manually running "puppet agent --test" or letting cron do it for
> me.
>
> This seems to be because the default root path in CentOS includes
> /usr/local/bin before /usr/bin, and thus I am getting a user-needed other
> python version that is a mismatch with the python version that puppet seems
> to want to play with.
>
> When I run:
>
> "puppet agent --test --path /sbin:/bin:/usr/sbin:/usr/bin:/root/bin"
>
>
> things seem to work without complaint.
>
> I tried to set that path in /etc/puppet/puppet.conf, but it doesn't seem
> to work. Should that work?
>
>  --
> 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/45991a27-d387-498a-ab8c-975e387db468%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/CAFt4V4%3Dv47Mh_TWAA9-t-9VZN%3DSNu1nNajNEKD05pXbMh5Xrvg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] More admins using the same master

[Jason Antman]

Yeah. You don't need to give them access to the master, you need something
(I use a git hook on the git server) that deploys new pushes to the master.


On Tue, Aug 5, 2014 at 12:15 PM, Christopher Wood <
christopher_w...@pobox.com> wrote:

> Off the top of my head, have them commit/push to the same git repository
> where that repository is checked out by the puppetmaster. You can give them
> each a VM to test their own stuff, where they'll also find out how their
> manifests interact with the whole picture. Keeping them in their own little
> silos will hurt you in the long run, and also potentially much sooner than
> that if two of them find they need to combine incompatible pieces.
>
> On Tue, Aug 05, 2014 at 09:00:50AM -0700, Luca Mazzaferro wrote:
> >Dear User community,
> >I would know if anyone has experience of using puppet
> >with multiple developers.
> >I try to explain better.
> >I have ONE master and some nodes attached.
> >We have more than 3 users which want to develop their module and
> deploy
> >them on different machines.
> >I know that we can define different environments and in principle
> >give one for each developer.
> >But in this case I need to give the access to the master to each one
> >and I wouldn't.
> >In principle I would that the users develop their code on their pc,
> then
> >commit
> >it via git ( for example ) and when they run puppet agent on their
> >machines
> >the master catch the new code and apply it.
> >I found the config_version variable inside the environment.conf should
> >work running a git clone inside the environments
> >before the execution on the clients.
> >Is there another way, simpler?
> >Anyone has any experience of it?
> >Thank you.
> >Regards.
> >Luca
> >
> >--
> >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 [1]puppet-users+unsubscr...@googlegroups.com.
> >To view this discussion on the web visit
> >[2]
> https://groups.google.com/d/msgid/puppet-users/e87c69cd-f182-463c-9c53-7225c9adfce5%40googlegroups.com
> .
> >For more options, visit [3]https://groups.google.com/d/optout.
> >
> > References
> >
> >Visible links
> >1. mailto:puppet-users+unsubscr...@googlegroups.com
> >2.
> https://groups.google.com/d/msgid/puppet-users/e87c69cd-f182-463c-9c53-7225c9adfce5%40googlegroups.com?utm_medium=email&utm_source=footer
> >3. 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/20140805161502.GA9324%40iniquitous.heresiarch.ca
> .
> 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/CAFt4V4%3DuaQYb7WOkU3%3DQxZP587qjrSc0-Rmx%2BfePgPrd1n6xmg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] increasing frequency of puppet agent runs during initial deployment?

[Jason Antman]

On Thu, Jul 31, 2014 at 9:21 AM, jcbollinger 
wrote:

>
>
>
>> That being said... don't run via cron.
>>
>
>
> ... if all you want it for is provisioning.  For Puppet's core use --
> ongoing configuration management -- there are a lot of advantages to
> scheduling agent runs via cron instead of running the agent as a daemon.
> Also a couple of limitations.
>
>
> John
>

Ever since I started running via MCollective, I think I was crazy to ever
have done otherwise. Especially with `mco puppet runall N` where N is the
number of concurrent nodes my master can support.

-- 
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/CAFt4V4kbUZYQxGC_axaySy%2By2ZL_h0YdemknHTyp5fEJuRFihA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] How to make puppetlabs_spec_helper ignore modules inside fixtures

[Jason Antman]

Seb,

You really shouldn't be running specs for dependent modules.

(1) If I were you, I'd really use the spec helper, and garethr's module
skeleton - https://github.com/garethr/puppet-module-skeleton
(2) looking at your code, you should just be able to
t.pattern = 'spec/(classes|defines)/*_spec.rb'

-Jason


On Tue, Aug 12, 2014 at 2:47 PM, Sebastian Otaegui  wrote:

> Hello all,
>
> I have created this module:
>
> https://github.com/Spantree/puppet-thrift and everything worked fine all
> specs ran fine.
>
> Now I using the puppetlabs/apt module and when I run the 'rake spec' it is
> trying to run the 'apt' tests, and it is failing (I think) because I am not
> providing the appropriate facts.
>
> Is there a way to ignore the rspecs inside the fixtures/modules/ directory?
>
> I tried to do this:
>
> require 'rake'require 'rspec/core/rake_task'
>
> RSpec::Core::RakeTask.new(:spec) do |t|  t.pattern = 'spec/*/*_spec.rb'end
>
>
>
> But it didn't work.
>
> Can anybody point me in the right direction here?
>
> Thanks in advance,
> Seb
>
> --
> 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/1d7b8768-0e72-40c3-97f7-623d08f028ac%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/CAFt4V4nPxPATgQVjzBdT2C5zu7B4zQbog-SSQE_o8-KKgcdFfA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] How to install GIT on puppet Server

[Jason Antman]

The module doesn't install git from source, because nobody should install
packages from source on a RedHat derivative OS. Have you read the
documentation for the git module? Or the package type, since you're
specifying the "source" parameter?


On Tue, Aug 12, 2014 at 7:17 PM, Vikas Kumar  wrote:

> Hi Satish,
>
> I was looking the flavor of Linux OS not the kernel.
>
> Run the below command to check OS major and minor version.
> facter | egrep 'operatingsystem|lsbdistid|lsbdistdescription'
>
>
> Also, the output of the command states that you do not git in your
> repository.
>
> /usr/bin/yum -d 0 -e 0 -y list git
>
>
> *Note* Red Hat Network repositories are not listed below. You must run
> this command as root to access RHN repositories.
> Error: No matching Packages to list
>
> I think *git* rpm is there by default in all RedHat based OS. Still can
> you run below commands and share the output.
>
> yum clean all
> yum repolist
> yum list all | grep git
>
>
> Regards,
> Vikas
>
> On Tuesday, 12 August 2014 20:52:39 UTC+10, Satish Katuru wrote:
>>
>> Hi Vikas,
>>
>> Please find the below information:
>>
>> Linux version: *Linux 2.6.32-358.6.2.el6.x86_64 x86_64*
>>
>>
>> Below is the output for the command
>>
>> /usr/bin/yum -d 0 -e 0 -y list git
>>
>>
>>
>> **Note* Red Hat Network repositories are not listed below. You must run
>> this command as root to access RHN repositories.Error: No matching Packages
>> to list*
>>
>>
>> On Tuesday, August 12, 2014 12:42:10 PM UTC+5:30, Vikas Kumar wrote:
>>>
>>> Hi Satish,
>>>
>>> Which flavor or version of Linux are you using ?
>>>
>>> I can try creating the scenario on my test machine and check myself.
>>>
>>> In the meantime, can you please post output of this command -
>>> /usr/bin/yum -d 0 -e 0 -y list git
>>>
>>>
>>>
>>> A small suggestion - Use code syntax for pasting logs, it makes a post
>>> much readable.
>>>
>>> Regards,
>>> Vikas
>>>
>>  --
> 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/8f0d8e9c-28ed-4ffe-9e7f-d676a73dc844%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/CAFt4V4m%2Bz_M0Ai_ed_cd1H2DdZMJFzqj0ae0PS76URdcnQGs%3DQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] use client_data/catalog/.json for nagios check?

[Jason Antman]

I've used two different ways of doing this, depending on whether or not you
have this stuff installed/running:
(1) if you have PuppetDB, just use that. I probably have a (Python) check
plugin for this somewhere if you need it.
(2) use `mco puppet status` and parse the output of that

These also have the advantage that they can be run as cron'ed passive
checks, and submit the results very efficiently.


On Tue, Jul 22, 2014 at 6:20 PM, Denmat  wrote:

> This one from RIP works ok for me:
>
> https://github.com/ripienaar/monitoring-scripts/blob/master/puppet/check_puppet.rb
>
>
> On 23 Jul 2014, at 5:47, Atom Powers  wrote:
>
> I use a script that checks if the puppet client is running and parses the
> lastrunreport for last run time and if any errors were reported applying
> the catalog.
>
>
> On Tue, Jul 22, 2014 at 12:36 PM, Bernard Clark 
> wrote:
>
>> We need to be alerted whenever a puppet report from any puppet client is
>> late. We were thinking of having Nagios monitor the last modification time
>> of a client's /var/lib/puppet/client_data/catalog/.json and alert us
>> when that file ages too much. Anyone have a better idea?
>>
>> --
>> 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/5d8181b7-6911-4af1-95dd-24331425d80e%40googlegroups.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> Perfection is just a word I use occasionally with mustard.
> --Atom Powers--
>
> --
> 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/CAF-H%3DOkfzUo9JD9Jt_s8z3zr-w5f5M%3DGrZACWc_s%2B52E0DrE4g%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/FF386C74-4A77-4EE4-BE09-62D0ACB129A1%40gmail.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/CAFt4V4%3DdCQQbG0iVE08nNV5nuEtQGyuqm8hq7qptxmHkTjFvfQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Wrap Package in a define

[Jason Antman]

For future reference...
(1) if at all possible (I assume you did this) hacking up upstream modules
is bad
(2) I'd use pip2pi (https://github.com/wolever/pip2pi) to create a mirror
of the modules you want, and then have puppet manage /root/.pip/pip.conf
(assuming puppet is running as root) and set:

[global]
index-url = /path/to/mirror




On Mon, Jul 21, 2014 at 2:25 PM, Brian Wilkins  wrote:

> Thanks David. We have taken the route of downloading the necessary
> dependencies and then explicitly setting the source for each package
> statement. We have an FTP server for our yum repo so we just added a pip
> directory and provide the ftp:// URL to pip. That seems to work.
>
>
> On Monday, July 21, 2014 5:53:01 AM UTC-4, David Schmitt wrote:
>>
>>
>> Hi Brian,
>>
>> On 2014-07-18 14:32, Brian Wilkins wrote:
>> > Hello,
>> >
>> > We are trying to use the puppet-forge graphite module located here:
>> > https://github.com/echocat/puppet-graphite/blob/master/
>> manifests/install.pp
>> > and our servers will not have access to the Internet. So we are
>> > downloading all the pip packages to a local repository and will point
>> > pip to each package. I would like to wrap the Package type so I can
>> > provide the source. How would I do this so that the package name is
>> > passed to the defined type? My intent is to not change much of the code
>> > here:
>> > https://github.com/echocat/puppet-graphite/blob/master/
>> manifests/install.pp
>> >
>> > Otherwise, I will have to comment out alot of the manifest and replace
>> > with exec statements pointing to each individual package.
>>
>> As far as I understand the current pip provider code, it won't work
>> anyways without access to the pypi repository.
>>
>> Since pip provides a way to globally configure a different index, I
>> think that would be a much better way to achieve your goal:
>>
>> > http://pip.readthedocs.org/en/latest/user_guide.html#configuration
>>
>>  From a cursory glance over the possibilities, setting an environment
>> variable to override your index location might be another way to avoid
>> poisoning the global pip config.
>>
>>
>> Regards, David
>> --
>> * Always looking for people I can help with awesome projects *
>> G+: https://plus.google.com/+DavidSchmitt
>> Blog: http://club.black.co.at/log/
>> LinkedIn: http://at.linkedin.com/in/davidschmitt
>>
>  --
> 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/f24ebad4-f27d-41aa-978a-33ca56a9b541%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/CAFt4V4k1FV6RHaomJpOVz3ReQXyYu4Bj%2BZh0-gEGwawG%3DHW%2Beg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Use MCollective to execute test automation (long running job) on lab machines

[Jason Antman]

Agreed with everything Schmitt said. This isn't what mcollective is for,
that's not how it works, there are tools made especially for this, etc. I'm
not saying it isn't possible if you jump through enough hoops. I'm just
saying it's an incredibly bad idea.


On Mon, Jul 14, 2014 at 2:41 PM, Andrii Kalytiuk 
wrote:

> Hi,
>
> I look into ways to use MCollective to *run test automation* on lab
> machines.
>
> After couple of days of research I still have a question *is MCollective
> is right tool* to perform all required routines.
>
> *So my question is:*
> *Will it be proper* to use MCollective for following operations on
> Windows nodes - using own custom agents:
>
>1. Wait for server node (virtual machine) to become responsive after
>revert
>2. Copy file with (test automation data) from network location
>3. Unzip test automation files
>4. Update content of config files on machine
>
> Have you looked into Puppet? It does exactly what you want in steps 2-4
(maybe step 1 as well, with some additional tools).

>
>1. Run command line utility to execute test automation.
>   - Takes from couple of minutes to hour or more
>   - Console output to be returned to MCollective client
>   - Output returns to client gradually (more or less shortly after it
>   is produced on server)
>   - *Is it possible to send responses to prompts of interactive
>   command line application?*
>
> No, mcollective doesn't do this. Mcollective tasks shouldn't (can't?) work
that way. AFAIK, you tell an mco server to do something, and eventually it
tells you *that the server received the request to do something* (reply).
Also, why is your testing prompting you interactively? How do you get
reproducable tests? Or examine the output later?

>
>-
>1. Archive certain files on server
>2. Copy zip file with output files to network location
>
> As I get from documentations all points except 5th can be implemented as a
> single or several command line calls.
>
> *So main questions are:*
> Is it possible to use MCollective to execute long-running command line
> utility on server and gradually return to client output of the utility as
> it is produced?
> Is it possible to implement interaction with a command line application
> which prompts for additional user inputs on server (e. g. non-silent
> installation)?
>
> Thank you.
>
> Andrii
>
> --
> 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/6a928f6f-2381-4bcc-826f-70c58a0ce579%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/CAFt4V4km4dDLL%3DGkRLLt-JhOc0EdfULbYP4uSQpU7Y4d%3Dfwd5A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: duplicated resource with an exported resource

[Jason Antman]

Just in case anyone comes by this in the future, maybe I'm missing
something, but why not keep this really simple (did you read the type
reference docs for host?):

@@host { "${::hostname}_exported" :

  name=> $::hostname,

  ensure  => present,

  ip => $secondary_ip,

}



host { $::hostname :

  ensure  => present,

  ip  => $primary_ip
}


On Tue, Jul 15, 2014 at 3:22 PM, José Luis Ledesma <
joseluis.lede...@gmail.com> wrote:

> It worked as you thought.
>
> Many thanks, perhaps the code is not so nice, but the config applied is,
> by far, better.
>
> Regards,
> El 15/07/2014 15:24, "jcbollinger"  escribió:
>
>
>>
>> On Monday, July 14, 2014 8:55:38 AM UTC-5, Kristof Willaert wrote:
>>>
>>> [snip]
>>>
>>> You will not be able to collect that resource on the node that exports
 it (you would again -- and rightfully -- get a duplicate resource
 complaint), but I think otherwise you should be ok.

>>>
>>> The documentation for exported resources suggests otherwise:
>>>
>>> Any node (including the node that exported it) can then *collect* the
>>> exported resource and manage its own copy of it. [1]
>>>
>>> I must say I haven't tried it myself, but unless I misinterpret the
>>> sentence above, it should be possible.
>>>
>>
>>
>> You're not misinterpreting the docs, but you *are* misinterpreting my
>> statement.  Although *generally* the node exporting a resource can
>> collect that resource, if the OP used the approach I described then his
>> nodes would not be able to collect the Site::Secondary_host resources they
>> declare themselves.  If they tried to collect their own, then it would
>> yield a duplicate Host resource (from the defined type body; because he
>> already, separately, declares a Host for the node itself).  The key there
>> is that -- I think -- the type's body will not be evaluated by the
>> declaring node for instances that it does not collect, even those that it
>> declares itself.
>>
>>
>> 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/e05c726c-b0ca-40be-8f5a-a38df765a9cf%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/CAF_B3ddtHrbANnKirUdvic9wgC7DxWmgtLy%3D4_TErgEmn5vMWQ%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/CAFt4V4n3EW8oWAXTf6xgTF%3DG0%2B_KnU6SHL8CJ-pE02jEXJabZw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: custom function to read inifile

[Jason Antman]

Before you get any further, you do understand that the inifile has to be on
the *master*, right? Just checking, because I've seen a lot of people
trying to write functions, and only later realizing that the data they want
is on the node, not the master.

When I've come up with issues like this (mainly JSON not ini, but whatever,
same difference for our purposes) I put the data somewhere that Puppet can
access natively (like in my ENC) and have puppet *write* files not read
them.


On Wed, Jul 23, 2014 at 6:11 PM, Ritesh Nanda 
wrote:

> Craig , i looked at that module puppetlabs-inifile, it  allows to change
> the settings in  ini file , i want to read/parse a ini file , assign a
> value to a variable.
>
> @henrik you were correct problem was with iniFile.load class . Now the
> functions looks like
>
> require_relative 'inifile'
>
> *This allows me to keep inifile.rb file inside the function directory. Is
> this correct ?*
>
> Puppet::Parser::Functions.newfunction(
>   :inireadvalue, :type => :rvalue,
>   :arity => 3,
>   :doc => "Reads an .ini file and...") do |args|
> filename   = args[0]
> section= args[1]
> key = args[2]
>
>  if !File.exist?(filename)
>
> raise(Puppet::ParseError, 'inireadvalue(): Path and file provided does not
>  exists ' +
>   'Provide the correct path')
> end
>
> fileload = IniFile.load(filename)
> data = fileload[section]
> value = data[key]
> return value
>
>
>   end
>
>
> Thanks for your help.
>
> Regards,
> Ritesh Nanda
>
>
> On Wed, Jul 23, 2014 at 2:31 PM, Craig Barr 
> wrote:
>
>> Does this  meet your
>> use case?
>>
>>
>> On Wednesday, 23 July 2014 07:36:45 UTC+10, Ritesh Nanda wrote:
>>>
>>> Hello ,
>>>
>>> I was trying to write a custom function which would run on puppet master
>>> take input a ini file , parse a section of that ini file and assign
>>> its value to a variable .
>>> Something like
>>>
>>> $test = iniread('example.ini', 'Program', 'path')
>>>
>>> This would assign the value to test variable when the functions runs on
>>> the puppet master.
>>>
>>> iniread.rb file looks like
>>>
>>> require 'rubygems'
>>> require 'inifile'
>>> module Puppet::Parser::Functions
>>>   newfunction(:iniread, :type => :rvalue) do |args|
>>> raise(Puppet::ParseError, 'inifile read(): Wrong number of arguments ' +
>>>   "given (#{args.size} for 3)") if args.size != 3
>>>
>>> filename = args[0]
>>> section = args[1]
>>> key = args[2]
>>>
>>> file = IniFile.load(filename)
>>> data = file[section]
>>> value = data[key]
>>> return value
>>>
>>>   end
>>> end
>>>
>>> It gives an error while running
>>>
>>> Error 400 on SERVER: undefined method `[]' for nil:NilClass at
>>> /etc/puppetlabs/puppet/modules/example/manifests/init.pp:45
>>>
>>> init.pp has
>>>
>>> $test =iniread("example.ini", "Program", "path")
>>>
>>>
>>> Doing that in ruby works
>>>
>>> require 'inifile'
>>> filename = ARGV[0]
>>> section = ARGV[1]
>>> key = ARGV[2]
>>> file = IniFile.load(filename)
>>> data = file[section]
>>> InstPath = data[key]
>>> puts InstPath
>>>
>>> Help to this would be really appreciated.
>>>
>>> Regards,
>>> Ritesh
>>>
>>>
>>>
>>>  --
>> 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/mNzxsAqTZ7I/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/705ed63d-1ae5-4fb5-afbc-6dfa7b579154%40googlegroups.com
>> 
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
>
>
> * With Regards  *
>
> * Ritesh Nanda*
>
>   --
> 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/CAO5CbpBOAynKgnZFOr_QVe80Dxo5ccRwrYOsy6GhGg4_rvrbjA%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-

Re: [Puppet Users] how to use conditional statements

[Jason Antman]

Puppet is idempotent. It doesn't work that way. Puppet declares intended
state. So you tell puppet "service should be running and files should be
there" and Puppet makes it so. If you have a "thing" that should be
implemented/executed in a specific way with specific ordering, that's what
custom providers (and types for them) are for.

Maybe someone else will chime in with a better solution than "write a
custom provider to do something awful", but every time I've run up against
this I've just decided that I either needed a provider for it, or the
application was broken and needed to be fixed.

-Jason


On Tue, Jul 29, 2014 at 8:58 AM, Satish Katuru 
wrote:

> Hi
>
> Here is my flow:
>
> Stop service-->copy required files from Master server-->Start service
>
> Once this is done,I am taking a copy of files on Master Server and
> removing the files from original location.
>
> I wanted to add this condition (if files are not there at that location no
> need stop and restart the service )
>
>
> The reason behind this question is for every 30 minutes deployment will be
> done on agent machine automatically.I just wanted to make sure that if
> files are there then only I have to stop and start the service.
>
>
> Thanks,
> Satish.
>
> --
> 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/e1ef43c1-fc2a-4893-9584-730d044709f3%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/CAFt4V4%3DzA0zDJdjAzuJakTPSvH05%2Bh7YxpvyXGd4echzDkU6GQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] increasing frequency of puppet agent runs during initial deployment?

[Jason Antman]

I've seen those environments. I've worked in them. A few host types in my
current environment are like that. IT IS A BUG. The only valid reason for
this is either a bug in your manifests/modules, or that things aren't
ordered properly.

That being said... don't run via cron. If you're using any sort of
provisioning system, just have that run puppet until it succeeds. If you're
not, then at host provisioning time, you could use a script that runs
puppet until it succeeds.


On Tue, Jul 29, 2014 at 11:26 AM, jcbollinger 
wrote:

>
>
> On Monday, July 28, 2014 2:20:33 PM UTC-5, Christopher Wood wrote:
>>
>> Before figuring out how to shorten the initial agent runs, I'd inquire
>> why a full configuration takes several agent runs.
>
>
> +1
>
> I have never seen or heard about an environment that *required* multiple
> Puppet runs to converge to a stable configuration.  I may have seen one or
> two where it was more *convenient* to allow two runs for convergence than
> to make the necessary arrangements for Puppet to apply a complete config to
> a new machine in just one run.  But never more than two, even for
> convenience.
>
>
> 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/e4b6cb7d-45b5-48db-95ca-0a0aca5448e5%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/CAFt4V4nJgmUoVYQ-5_Qm9UESoQmYiP0xFwn2fWvAhsG4MN6oEA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: puppetlabs_spec_helper 0.5.x breaks puppet-lint's ignore_paths ?

[Jason Antman]

 I'm also experiencing this issue. I've opened 
https://tickets.puppetlabs.com/browse/MODULES-1190 for 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/f1a1e6d6-345a-4605-a661-05415b2b5668%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] What is the execution order in a manifest file

[Jason Antman]

You should use the 'require' metaparameter, or if you absolutely need to,
explicit ordering. docs.puppetlabs.com will give you further information.

You should also read the Style Guide, and not throw all of that in one
manifest.


On Wed, Jun 25, 2014 at 8:04 AM, Malintha Adikari  wrote:

> Hi,
>
> In my manifest file there are 3 elements ( 2 defined types and one exec)
>
> define *fill_templates*($location) {
> file { "$location/$name/":
> ensure  => present,
> owner   => 'root',
> group   => 'root',
> mode=> '0777',
> content => template("config/${name}.erb"),
> }
>
> }
>
> *fill_templates { $filelist: location=>$agentLocation}*
>
> exec { "unzip_pack":
> command => "unzip ${product_pack}",
> cwd => $agentLocation,
> path  => $command_path,
> logoutput => true,
> timeout => 3600,
> require => File["${agentLocation}/${product_pack}"],
> }
>
>
>
> $foo = [{"addr" => $source, "port" =>
> $destination},
>   {"addr" => "bat", "port" => "2"}]
>
> *  testmod::bar {$foo:} *
>
>   define *testmod*::bar ()
> {
> $var1 =
> $name["addr"]
> $var2 =
> $name["port"]
> notify
> {"**${var1}_${var2}***":
> }
>
> When I execute this manifest what is the order of the above 3 elements
> execution. I have noticed the they are executed in mixed order. How can I
> define the order of execution in this kind of scenario ?
>
> Regards,
> Malintha Adikari
>   }
>
> --
> 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/fcdb2227-918e-4273-a5da-6dd29ca5%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/CAFt4V4no5BJhgcFk%3DUSaSoOB6zP1Y1CNGd9qnES0Y6T%2B4HfPEA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: Open puppet port(s) to the internet

[Jason Antman]

FWIW, two thoughts on this:
1) Tunnel over SSH or VPN.
2) Is it feasible to *not* use a puppetmaster for this, and rather have
something on the laptops (cronjob? small daemon?) that pulls down your
config repository and runs masterless puppet locally?

-Jason


On Wed, Jun 18, 2014 at 10:40 AM, Neil - Puppet List <
maillist-pup...@iamafreeman.com> wrote:

> Hi
>
> Running puppet on port 443 might be a good move if you expect your laptops
> to be using cafe hotel airport style wifi
>
> sslh might be a suitable tool to proxy for puppet I've not tried it though.
>
> Regards
>
> Neil
>  On 18 Jun 2014 14:30, "jcbollinger"  wrote:
>
>>
>>
>> On Tuesday, June 17, 2014 12:19:08 PM UTC-5, jmp242 wrote:
>>>
>>> I probably don't really understand much about how puppet connects to the
>>> clients, but is there a big security risk about opening it up to the
>>> internet so laptops can get their configuration... If it's "safe enough"
>>> for any value of safe, what ports does it use?
>>>
>>> Thanks,
>>>
>>
>>
>> In normal operation, Puppet  (the master) *doesn't* connect to clients
>> -- the clients connect to it (on port 8140), thereby establishing a two-way
>> communication channel.
>>
>> Client-side firewalls need to allow outgoing traffic to that port, and
>> accept incoming traffic belonging to an established connection to that
>> port.  Those permissions can be narrowed to specific destination networks
>> or machines, if needed.  For its part, the master needs to accept
>> connections on port 8140 from all client machines; that can be narrowed to
>> traffic originating on specific networks, if you wish.
>>
>> Each end of the conversation between agent and master authenticates to
>> the other via SSL certificate.  Spencer understated the security there: on
>> the web, most SSL connections are authenticated only on one end, so
>> Puppet's communications are even better secured.
>>
>> With that said, if you want laptops in the field to be able to retrieve
>> their configuration, then you have the alternative of requiring them to
>> establish a VPN connection to your internal network in order to do so
>> (especially if users will want / need to use VPN anyway), or of just
>> letting them go without syncing until they return home.  The Puppet service
>> itself is pretty well secured, but allowing connections from anywhere on
>> the internet increases your exposure to network-level attacks.
>>
>>
>> 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/e0d19ab8-de5e-4205-b774-b37b1b595643%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/CAAohVBfNtx6igp__7Koivb18r_onQ0A0BUZeMpVyeTct1%2B-s8w%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/CAFt4V4%3DQfYtyA1pMu6AKtW7jf9D9r9yANsKT1-uE05tHBqw4jQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: Moving from manifest files to ENC script - not working...

[Jason Antman]

Yes, I have an idea.

1) Read the documentation: 
http://docs.puppetlabs.com/guides/external_nodes.html
2) If that doesn't help, post your ENC code, with specific examples of 
output and problems that you're having.


On 06/17/2014 07:49 AM, shlo.af...@gmail.com wrote:


Hi,

I understood  ENC can work without the PuppetDB installation.
I cannot make ENC work and I cannot find a log or any way to debug it, 
so I can find the problem.


any idea are welcome.
Thanks.
--
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/85498348-93a0-49ff-bdc5-589f76e7ee79%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/53A02D79.50005%40jasonantman.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] having issue when trying to install java using rpm

[Jason Antman]

"That's not how it works".

In the output below, you can clearly see that Puppet is executing 
`*/bin/rpm -i 
puppet:///development/java_rpm/files/jdk-7u25-linux-x64.rpm*`. Why would 
that work? "puppet:///" means nothing to RPM, and "puppet:///" is not a 
valid 'source' for the Package type.


You have two options:
1) the correct option, create a Yum repository somewhere with the 
package in it, and install from that.

2) Serve that file over HTTP from somewhere, and install from there.
2) Use a File resource first to put that on the machine, and have the 
Package resource install that, and reference that path.


I'd highly recommend against doing it this way. There's no reason that a 
giant binary (like an RPM) should be inside a puppet module - it means 
your source control repo for puppet (or that module) will be huge, and 
Puppet isn't really designed to serve large files. There are existing 
methods of deploying RPMs (Yum).


-Jason

On 06/13/2014 01:17 PM, Supriya Uppalapati wrote:


Hi,

I am getting the issue when i modifyied the code like this

class java_rpm::install {
$version = hiera("javaversion")

package { $version:
provider => rpm,
source => "puppet:///development/java_rpm/files/$version",
ensure => installed,
}
}
MY file is here:
pwd
/etc/puppetlabs/puppet/environments/development/modules/java_rpm/files

*In my /var/lib/hiera*

classes:
- 'cis'
- 'java_versions'
- 'java_rpm'

javaversion: jdk-7u25-linux-x64.rpm

**

**

*Error: Execution of '/bin/rpm -i 
puppet:///development/java_rpm/files/jdk-7u25-linux-x64.rpm' returned 
1: error: open of 
puppet:///development/java_rpm/files/jdk-7u25-linux-x64.rpm failed: No 
such file or directory*


**

*Error: 
/Stage[main]/Java_rpm::Install/Package[jdk-7u25-linux-x64.rpm]/ensure: 
change from absent to present failed: Execution of '/bin/rpm -i 
puppet:///development/java_rpm/files/jdk-7u25-linux-x64.rpm' returned 
1: error: open of 
puppet:///development/java_rpm/files/jdk-7u25-linux-x64.rpm failed: No 
such file or directory*


Let me know

--
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/c25a25f1-2aaa-4596-a8d9-b66a8331fcbc%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/53A02BD1.4090804%40jasonantman.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Package Resource, Versioning and Yum

[Jason Antman]

Joseph,

See https://tickets.puppetlabs.com/browse/PUP-682

I'm going to try and get the pull request rebased, but at best this will 
be in puppet4.


-Jason

On 06/12/2014 02:44 PM, Joseph Swick wrote:

Hi list,
I'm working on a little addition to an internal module we use to ensure
our puppet clients have a consistent configuration to also ensure the
correct version of puppet is installed on the system and run into a bit
of semantics issue as I thought that "ensure => 'version.num'" was a
more correct way of specifying the version of a package, rather than
doing it in the name of the resource.

Here's a few snippets of code:

Common class opening:

class puppet_mw::client (
   ...
   $manage_versions  = true,
   $puppet_version   = '3.6.2',
   $facter_version   = '2.0.2',
   $hiera_version= '1.3.4',
   ...
) {

This works:

   if $manage_versions {
 package { "puppet-${puppet_version}":
   ensure => present,
 }
 package { "facter-${facter_version}":
   ensure => present,
 }
 package { "hiera-${hiera_version}":
   ensure => present,
 }
   }


This however, does not:

   if $manage_versions {
 package { 'puppet':
   ensure => ${puppet_version},
 }
 package { 'facter':
   ensure => ${facter_version},
 }
 package { 'hiera':
   ensure => ${hiera_version},
 }
   }

As it generates this error:

Error: Could not update: Failed to update to version 3.6.2, got version
3.6.2-1.el6 instead
Wrapped exception:
Failed to update to version 3.6.2, got version 3.6.2-1.el6 instead
Error: /Stage[main]/Puppet_mw::Client/Package[puppet]/ensure: change
from 3.6.2-1.el6 to 3.6.2 failed: Could not update: Failed to update to
version 3.6.2, got version 3.6.2-1.el6 instead
Error: Could not update: Failed to update to version 2.0.2, got version
2.0.2-1.el6 instead
Wrapped exception:
Failed to update to version 2.0.2, got version 2.0.2-1.el6 instead
Error: /Stage[main]/Puppet_mw::Client/Package[facter]/ensure: change
from 1.7.5-1.el6 to 2.0.2 failed: Could not update: Failed to update to
version 2.0.2, got version 2.0.2-1.el6 instead
Error: Could not update: Failed to update to version 1.3.4, got version
1.3.4-1.el6 instead
Wrapped exception:
Failed to update to version 1.3.4, got version 1.3.4-1.el6 instead
Error: /Stage[main]/Puppet_mw::Client/Package[hiera]/ensure: change from
1.3.2-1.el6 to 1.3.4 failed: Could not update: Failed to update to
version 1.3.4, got version 1.3.4-1.el6 instead

Which lead me to this, but will get messy to ensure compatibility with
different Linux versions:

   if $manage_versions {
 case $::osfamily {
   'RedHat': { $os_string = "-1.el${::operatingsystemmajrelease}" }
   default : { $os_string = undef }
 }

 package { 'puppet':
   ensure => "${puppet_version}${os_string}",
 }
 package { 'facter':
   ensure => "${facter_version}${os_string}",
 }
 package { 'hiera':
   ensure => "${hiera_version}${os_string}",
 }
   }

Running 'yum install puppet-3.6.2' works as desired, but adding
'allow_virutal => true,' to the package resource doesn't change the
previous error.

Is this working as designed for the Yum provider for the package
resource or is this a bug with the provider?  For some reason, I want to
think this has been discussed on the list before, but couldn't find the
relevant thread.

It appears I may be running up against this bug:

https://tickets.puppetlabs.com/browse/PUP-1244

TIA.



--
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/53A02951.9030007%40jasonantman.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Pattern for Associating Module versions with Nodes

[Jason Antman]

I can think of 2 ways of doing this, none of which are terribly nice:
1) use a separate Environment with the new version of the module, and start
running nodes against that. Once you get them all moved over to the new
environment, roll out the new module version to the production environment,
and switch them all back to that.
2) Simply disable runs on the nodes that you don't want on the new module
version, and then re-enable as you go.

That being said, trying to deploy Puppet modules like this is a bit of a
kludge. Personally, I'm an advocate of separating nodes into logical groups
and running each in an environment, or on a separate master.

In my current setup, we have N groups of "development" systems (on one
master, one Environment each), about N/10 groups of "test/QA" systems (on a
second master, one environment each) and a whole bunch of production
systems (on a third master, all in the production environment). For module
upgrades, we deploy it to one of the dev environments, test it, deploy it
to one of the test/QA environments, test it, and then merge it back to
master, and deploy it to production and everywhere else.

-Jason


On Tue, May 27, 2014 at 12:24 AM, Nitin Sharma 
wrote:

> Hi Abbas,
>
> I am wondering if you have found a solution for the requirement yet and if
> so, could you please share it.
>
> On Friday, March 8, 2013 9:43:24 AM UTC+11, Mohamed Abbas wrote:
>>
>>  On 3/7/13 1:51 PM, Nan Liu wrote:
>>
>> On Thu, Mar 7, 2013 at 12:42 PM, Mohamed Abbas 
>> wrote:
>>
>>> I'm wondering what is the canonical way of associating "specific"
>>> versions of a module to a node? Is there a way of doing this in puppet? Let
>>> me explain a "Use Case" of what I'm trying to accomplish:
>>>
>>> Say we have created a puppet model called apache to manage and configure
>>> apache webserver.
>>> We have the apache module under version control and there are several
>>> versions.
>>> We use puppet to apply apache-1.0.3 across an entire "environment"
>>> We want to be able to do a rolling upgrade across that entire
>>> environment, where some nodes in the environment have apache-1.0.3 and
>>> other have apache-1.1.2.
>>>
>>> From what I understand of puppet, there is no way of associating a
>>> specific version of a module to a specific node. The only way of doing that
>>> would be to "embed" a version tag in the module/class name. However that is
>>> ugly and does not work well with version control systems.
>>>
>>> Any suggestions of to accomplish this using puppet?
>>>
>>
>>  Github's boxen project powered by librarian-puppet, or r10k:
>> https://github.com/adrienthebo/r10k are good examples using Puppetfile
>> for module version control.
>>
>>
>> Thanks Nan. I looked at both and they address a different defined-problem
>> than the one I'm trying to address. What librarian-puppet and the boxen and
>> r10k solution you mentioned allow you to do is(per my understanding and
>> experience with using librarian-puppet):
>>
>>- To populate a modules sub-directory dynamically by using a
>>"Puppetfile" where you can pull different modules from different sources
>>and being able to specify which version to pull in. Once the modules
>>directory is populated, what is available to you to use in Puppet is still
>>a *single *version of that module.
>>
>> The defined-problem I'm trying to see if puppet addresses or create a new
>> solution to address it:
>>
>>- Having multiple instances of a module of different version number
>>available in the modules sub-directory where I can freely associate
>>different 2 different nodes to differing versions of the same module.
>>
>>
>> Thanks,
>> Mohamed Abbas
>>
>  --
> 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/aadf2f46-5b83-4b2c-8a78-bb6123d9bd2b%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/CAFt4V4mx8QinqaZM0r51miwJtEx4ZdiQ%2BzaTRxaig%2BgLR8ORQA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: Change to issue tracking for Forge & PL Module projects

[Jason Antman]

Is there any update on the timeline for Module issue migration to Jira?

I opened https://github.com/puppetlabs/puppetlabs-mcollective/issues/124 at
the beginning of March. This has now become more important to me, so I was
going to look up my issue description and try to submit a PR (it should be
a relatively trivial fix), but the link to the issue no longer exists, so I
can't seem to find the details that I originally put there.

If the migration isn't imminent, does anyone know how to find the content
of the issue that I opened, which seems to have now fallen off the face of
the earth?

Thanks,
Jason Antman


On Fri, Mar 21, 2014 at 2:16 PM, Heidi Pio  wrote:

> Hi Everyone,
>
> Quick introduction:  I'm the Engineering Project Manager of the Puppet
> Labs Forge.
>
> And a quick update to let you know that the Puppet Labs Forge and Module
> issue migrations from Redmine and GitHub are now complete.   GitHub issues
> for each module repo have been turned off.
>
> Puppet Labs Forge issues can now be found here:
> https://tickets.puppetlabs.com/browse/FORGE
> And Puppet Labs Module issues can be found here:
> https://tickets.puppetlabs.com/browse/MODULES
>
> The pull request process will not change, however, the Puppet Forge
> Community Pull Request Review meeting has moved to Thursdays at 10am PST.
>  Ashley Penney has graciously offered to send out weekly updates for those
> meetings via the Puppet-Dev list.
>
> Please feel free to contact me if you have any questions about this
> migration or the pull request process. Thanks and have a great weekend!
>
>
>
> On Monday, December 16, 2013 7:48:34 AM UTC-8, Ryan Coleman wrote:
> As Eric Sorenson noted earlier [1], issue tracking for most projects at
> Puppet Labs are moving to JIRA. This includes the Puppet Forge and the
> Puppet Labs modules on the Forge.
>
>
> As of this morning, Forge issues in Redmine have been set to read-only and
> have been migrated into the FORGE project in tickets.puppetlabs.com. Each
> Redmine ticket will point you to its companion JIRA ticket. Here's an
> example http://projects.puppetlabs.com/issues/5033 ->
> https://tickets.puppetlabs.com/browse/FORGE-27
>
>
> Issue tracking for Puppet Labs Forge modules are also moving. Most are
> moving from GitHub Issues but some were still being tracked in Redmine.
> This morning, we will update the 'Report Issues' link on each module page
> to point to JIRA. Please start filing new issues here:
> https://tickets.puppetlabs.com/browse/MODULES. We're still sorting out
> the software to migrate existing issues without losing critical
> information. Once that's ready, it'll work much like the Forge migration.
>
>
> I'll be spending some of my holiday curled up with hot chocolate, caring
> for each of the newly migrated issues. I'll update their states, ensure
> they're properly linked to internal work and try to give you some idea
> where they fit into 2014. If you have an issue you care deeply about, I
> suggest you follow it into JIRA and start watching it.
>
>
> I hope you find this transition fairly painless. Please let me know if you
> have any questions, concerns or suggestions.
>
>
> [1] https://groups.google.com/d/topic/puppet-users/4lV1cT6Li-M/discussion
>
>
> --
>
> Ryan Coleman | Modules & Forge | ryanycoleman on twitter & #puppet IRC
>
>  --
> 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/969b4116-4558-4766-9d91-772a27d054c6%40googlegroups.com<https://groups.google.com/d/msgid/puppet-users/969b4116-4558-4766-9d91-772a27d054c6%40googlegroups.com?utm_medium=email&utm_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/CAFt4V4kO%2BfXogw3D%2B4wLjY4JD47v3%2BuQWRUQfpoGK%3DjEbpM2Rw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Why is the environment setting limited to alphanumeric characters only?

[Jason Antman]

Matt,

I don't remember the technical details on why it exists, but it does. 
No, there aren't any plans to relax it that I'm aware of...


Yeah, we use git branches as environments, and we essentially do 
's/[^A-Za-z0-9_]/_/g' on the branch names to get environment names.


-Jason

On 02/19/2014 05:52 AM, Matthew Burgess wrote:

Hi,

Our infrastructure design has the environment that a server lives in 
embedded in its FQDN:


hostname.seccomp-environment.local

Where seccomp is the 'security compartment' (i.e. the kind of data it 
houses) and env is the environment name.


I set my puppet.conf up so that 'environment = sc-env1' and got the 
following error back from the master:


Error: Could not retrieve catalog from remote server: Error 400 on 
SERVER: The environment must be purely alphanumeric, not 'sc-env1'


I can kind of understand there being some limitations around allowed 
characters (e.g. $, #, %), but I'd have thought that a hyphen would be 
a) pretty safe and b) quite a common use case.  Reading the fine 
manual 
(http://docs.puppetlabs.com/guides/environment.html#naming-environments) 
that actually mentions that underscores are allowed too; It's a shame 
the error message doesn't allude to that (see PUP-1395).  So, for the 
time being I'll translate our hyphens to underscores to workaround the 
limitation.


Does anyone know why this restriction exists, and if there are any 
plans to relax the restrictions?


Kind Regards,

Matt.
--
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/CAKUTv3JneenHvUE7EKj%3DmHRNioGNa5cwrrOfJg0n%3D1Ps4oOVCw%40mail.gmail.com.

For more options, visit https://groups.google.com/groups/opt_out.


--
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/5304B4B4.1070503%40jasonantman.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] Nagios default files being overwritten

[Jason Antman]

Agreed with what Matthias said. Puppet's naginator stuff doesn't play 
very well with non-Puppet nagios configurations. Essentially, you have 
to pick one of:
- remove the default template from that file, and create it with Puppet 
elsewhere

- put all of the contents of that file in Puppet
- totally remove all of the default object configuration, and have 
Puppet do everything (what I do)


On the other hand, I don't use templates in Nagios anymore, I find them 
to be redundant. I use a combination of defines and parameterized 
classes (hiera would be good here too, though I don't use it) and have 
Puppet write out complete definitions for hosts/services/etc without any 
templates. I find that makes it much more clear to look at one resource 
in Puppet and know what it does, and reduces the likelihood that a 
template will get modified and have unintended consequences for objects 
that use it.


-Jason

On 02/11/2014 11:14 AM, Matthias Saou wrote:

On Tue, 11 Feb 2014 06:53:42 -0800 (PST)
druide.st...@gmail.com wrote:


I have a strange problem here. Most of my Nagios configuration are
from file {} directive, but I also need to modify a couple of Nagios'
default configuration. To do this, I use classes like this:

class nagios::gabarits {

nagios_host { 'linux-server':
  use => 'generic-host',

[...]

  target => '/etc/nagios/objects/templates.cfg',
  ensure => present,
}

  }

Problem is: it replace the content
of /etc/nagios/objects/templates.cfg with the new host definition,
but everything else in the file is gone!

I think that's the expected behaviour.
The proper fix is to also declare the other nagios resources you want
to see in that file.

That's more or less how I solved it in my own module :
https://github.com/thias/puppet-nagios/blob/master/manifests/server.pp#L550
(feel free to copy/paste those lines!)

Though I did "move" all of the resources to their default files and
stopped using the objects/templates.cfg file.

HTH,
Matthias



--
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/52FAA665.8080703%40jasonantman.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] puppet random notification confusion

[Jason Antman]

I seem to be pointing someone to this every week. You may want to refer 
to John Bollinger's 2014-01-03 reply to the "wondering if I want to[sic] 
much now" thread, which gives some excellent descriptions on 'how not to 
Puppet':

https://groups.google.com/d/msg/puppet-users/IGqjPpVCrKA/VcUKiV3xfPkJ

As Denmat said, "that's not how Puppet works." Puppet is not a bash 
script, it's a declarative language to describe the desired 
configuration of something. On resources that absolutely must have an 
order dependency, you can use explicit ordering (->) or even better, the 
require parameter. Aside from variable resolution, manifests aren't 
executed in a defined order (you should really spend some time reading 
through docs.puppetlabs.com, especially w/r/t catalog compilation and 
evaluation).


-Jason

On 02/10/2014 03:19 AM, Muhammad Yousuf Khan wrote:
i am being through a exercise on docs.puppetlabs.com 

and i am confuse with the notification output. as it shows last 
message first and first message at last.

i just need to know why the output notifications are random

here is my .pp file.

@puppet:/etc/puppetlabs/puppet# cat  text.pp

file {'/tmp/test1':
  ensure  => file,
  content => "Hi.\n",
}
notify {"this is 1":}

   file {'/tmp/test2':
  ensure => directory,
  mode   => 0644,
}

file {'/tmp/test3':
  ensure => link,
  target => '/tmp/test1',
}

file {'/tmp/test2/insidedir':
  ensure => file,
  content => 'infor put by me',
}

user {'katie':
  ensure => absent,
}

notify {"I'm notifying you.":}
notify {"this is 2":}
notify {"So am I!":}
notify {"this is 3":}

---
here is the output

Notice: Compiled catalog for puppet.mycompany.com 
 in environment production in 0.55 seconds

Notice: this is 2
Notice: /Stage[main]//Notify[this is 2]/message: defined 'message' as 
'this is 2'

Notice: this is 3
Notice: /Stage[main]//Notify[this is 3]/message: defined 'message' as 
'this is 3'

Notice: So am I!
Notice: /Stage[main]//Notify[So am I!]/message: defined 'message' as 
'So am I!'

Notice: I'm notifying you.
Notice: /Stage[main]//Notify[I'm notifying you.]/message: defined 
'message' as 'I'm notifying you.'

Notice: this is 1
Notice: /Stage[main]//Notify[this is 1]/message: defined 'message' as 
'this is 1'

Notice: Finished catalog run in 0.49 seconds


so the question is why the notification outputs are so random.

Thanks,

MYK

--
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/CAGWVfMmp6tN_qHd1bRmrqp%2BoMi7QXARqDZf6KEWxnpGGLqUShQ%40mail.gmail.com.

For more options, visit https://groups.google.com/groups/opt_out.


--
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/52F9137B.4030601%40jasonantman.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] can puppet manage puppet agents or puppetmasters?

[Jason Antman]

There are some issues with Puppet restarting (or stopping) itself. 
Beyond that, yes, I use puppet modules to manage the configuration of 
all of my masters and agents.


There's a puppetlabs-puppet module, but it's horribly out of date. At 
the moment, I'm using a fork (https://github.com/jbouse/puppetlabs-puppet).


I use an ENC; to do the initial bootstrap of a new Puppet master, I have 
a frozen copy of the YAML returned by my ENC, and a puppet.conf that 
uses it in local, masterless mode.


-Jason

On 02/08/2014 06:53 PM, Larry Fast wrote:

https://ask.puppetlabs.com/question/4694/updating-puppet-agents/

I'm looking at this thread from ask.puppetlabs and so far the the only 
answer seems to be - don't use puppet to manage puppet.  I'm asking 
the broader community because I'm still naively hopeful that puppet 
can manage its own installations.  Is there anything in Puppet 
Enterprise that supports this? Is there a best practice for how to 
update or reconfigure puppet installations? Or is this problem too 
self referencial and completely out of scope for the puppet system?





--
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/06df5e93-cf9c-4f53-b06c-9413b5346a1a%40googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.


--
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/52F8C627.70402%40jasonantman.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] Please help with control/ordering issue

[Jason Antman]

If it uses RabbitMQ, I'd very very strongly advise that you just use the 
puppetlabs-rabbitmq module to configure the rabbitmq portion.


-Jason

On 02/05/2014 02:27 PM, D C wrote:

The application does use rabbitmq which is the cause for my woes.

The chaining arrows will work to enforce the order,  but it doesn't 
help with the onlyif portion...

Class['myapp::phase1'] only if [ ! -e /path/to/puppet.phase ]


The alternative which I was trying to avoid was to go and dig through 
every item in each of the classes.
For some items i will have to add an only if.  Others will be just 
fine by using the regular before and require.  This should work but 
now I have to consider a bunch of test scenarios.



I'll take a look at that rabbit class to see what they did



Thanks,
Dan


On Wed, Feb 5, 2014 at 12:32 PM, Jason Antman <mailto:ja...@jasonantman.com>> wrote:


On 02/05/2014 08:57 AM, dc12...@gmail.com
<mailto:dc12...@gmail.com> wrote:
> Thanks, I will take a look at that post.
> I haven't been able to find the "proper" way to do some of these
things.
>
> Initially I had this running as a single class,  working only with
> requires, before, and notify.
>
>  This is where I ran into trouble,   maybe you know of an alternate
> way to achieve this.
>
> During my initial setup,  I start with a simple package, file
service
> relationship.
> Next i need to add some users into the service which was just added.
> For this, the service needs to be running   (ensure => running).
>
> However,  after that initial installation is done.  I want the admin
> to have the ability to stop the service, without worrying that
puppet
> is going to turn it back on.
> So i got rid of ensure=>running,  and instead used an Exec[]
> (refreshonly) to start my service.  The Package notifies the exec
This is a common problem. It's been the problem with what I call "old
world" thinking every time I've done a new Puppet deployment at a shop
that isn't used to doing things in a sane, infrastructure-as-code way.
Why do you want to stop a service that should be running? Either the
service should be running, or it shouldn't.

If there's an emergency, the admin should either (a) complete
their work
in < a puppet run interval, or (b) `puppet agent --disable` (which
ideally also throws some monitoring alerts) and stop the service. The
way I've generally approached this problem is by finding out under
what
conditions an admin would have to stop the service, and teaching
puppet
to handle them. That being said, I can't say I can think of many
services I have that I actually *want* stopped, ever.
>
> Now to add users.
> I cannot "require" the Exec, because that only happens if after the
> RPM is installed
>
> I keep running into cases where if I fix A, then B  breaks.  If
i fix
> B, then C breaks.  if I fix C then A breaks again..
> This is why I broke it into phases.
So I'll admit that, especially with proprietary software, it can
be very
difficult to shoehorn broken installation processes into a sane
framework (Puppet).

On a side note, the process you're talking about is strikingly similar
to how one goes about installing and setting up RabbitMQ (at least
1.x)
- install the RPM, start the service, but then to add users you
need to
have the admin plugin, and to make that active you need to restart the
service. It's entirely possible to do though - you might benefit from
some of the patterns used in
https://github.com/puppetlabs/puppetlabs-rabbitmq
>
>
>
>
> --
> 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
<mailto:puppet-users%2bunsubscr...@googlegroups.com>.
> To view this discussion on the web visit
>

https://groups.google.com/d/msgid/puppet-users/896ed69c-06d9-424e-b218-a0c117233196%40googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.


--
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
<mailto:puppet-users%2bunsubscr...@googlegroups.com>.
To view this discussion on the web visit

https://groups.google.com/d/msgid/puppet-users/52F275CA.9090107%40ja

Re: [Puppet Users] Please help with control/ordering issue

[Jason Antman]

On 02/05/2014 08:57 AM, dc12...@gmail.com wrote:
> Thanks, I will take a look at that post.
> I haven't been able to find the "proper" way to do some of these things.
>
> Initially I had this running as a single class,  working only with
> requires, before, and notify.
>
>  This is where I ran into trouble,   maybe you know of an alternate
> way to achieve this.
>
> During my initial setup,  I start with a simple package, file service
> relationship.
> Next i need to add some users into the service which was just added. 
> For this, the service needs to be running   (ensure => running).
>
> However,  after that initial installation is done.  I want the admin
> to have the ability to stop the service, without worrying that puppet
> is going to turn it back on.
> So i got rid of ensure=>running,  and instead used an Exec[]
> (refreshonly) to start my service.  The Package notifies the exec
This is a common problem. It's been the problem with what I call "old
world" thinking every time I've done a new Puppet deployment at a shop
that isn't used to doing things in a sane, infrastructure-as-code way.
Why do you want to stop a service that should be running? Either the
service should be running, or it shouldn't.

If there's an emergency, the admin should either (a) complete their work
in < a puppet run interval, or (b) `puppet agent --disable` (which
ideally also throws some monitoring alerts) and stop the service. The
way I've generally approached this problem is by finding out under what
conditions an admin would have to stop the service, and teaching puppet
to handle them. That being said, I can't say I can think of many
services I have that I actually *want* stopped, ever.
>
> Now to add users.
> I cannot "require" the Exec, because that only happens if after the
> RPM is installed
>
> I keep running into cases where if I fix A, then B  breaks.  If i fix
> B, then C breaks.  if I fix C then A breaks again..
> This is why I broke it into phases.
So I'll admit that, especially with proprietary software, it can be very
difficult to shoehorn broken installation processes into a sane
framework (Puppet).

On a side note, the process you're talking about is strikingly similar
to how one goes about installing and setting up RabbitMQ (at least 1.x)
- install the RPM, start the service, but then to add users you need to
have the admin plugin, and to make that active you need to restart the
service. It's entirely possible to do though - you might benefit from
some of the patterns used in
https://github.com/puppetlabs/puppetlabs-rabbitmq
>
>
>
>
> -- 
> 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/896ed69c-06d9-424e-b218-a0c117233196%40googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.


-- 
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/52F275CA.9090107%40jasonantman.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] Please help with control/ordering issue

[Jason Antman]

Unnamed poster,

Succinctly: You're trying to write a bash script in Puppet. That's not
how it works, that's not what it's designed for, that's not how it
should be used.

However, luckily, there's a really simple and easy way to do what you're
trying to in Puppet:

Class['myapp::phase1'] -> Class['myapp::phase2'] ->
Class['myapp::phase3']

If there are *specific* things that you need to make sure happen before
a given action (like making sure a package is installed before a config
file is created/changed), that's what "requires" is for.

You may want to refer to John Bollinger's 2014-01-03 reply to the
"wondering if I want to[sic] much now" thread, which gives some
excellent descriptions on 'how not to Puppet':
https://groups.google.com/d/msg/puppet-users/IGqjPpVCrKA/VcUKiV3xfPkJ

-Jason

On 02/04/2014 06:11 PM, dc12...@gmail.com wrote:
> Hi, im trying to work some logic into a puppet class and I'm not sure
> the best way to do it.  For this application, I have an installation
> phase, a setup phase, and then a maintenance phase.
>
> My current method of maintaining this is to call the relevant subclass
> using "include".  I then  have to go comment out two of the 3 includes
> depending on which phase i'm on.  This of course means that I have to
> shut off puppet on all the nodes im not directly working on.
>
> I would like to use the following logic in my class to control this. 
> Could somebody help me with the proper syntax to get this working?
>
>
> class myapp {
>
>   Class['myapp::phase1'] only if [ ! -e /path/to/puppet.phase ]
> # myapp::phase1 will echo 'phase2' into /path/to/puppet.phase 
> once all requirements are met
>
>   Class['myapp::phase2'] only if [ $(cat /path/to/puppet.phase) ==
> 'phase2' ]
> # myapp::phase2 will echo 'phase3' into /path/to/puppet.phase 
> once all requirements are met
>
>   Class['myapp::phase3'] only if [ $(cat /path/to/puppet.phase) ==
> 'phase3' ]
> }
>
> -- 
> 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/2c4124a2-dfd1-4006-b5c0-b66e026dfe5e%40googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.


-- 
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/52F22996.9040704%40jasonantman.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] [JOBS] systems and automation/tooking engineers - Atlanta, GA, USA or remote in US

[Jason Antman]

Ahhh. I suppose I was just being naive and thinking that the recruiters
hadn't found out about this list yet... wishful thinking.

Thanks.

On 02/04/2014 02:04 PM, Ken Barber wrote:
> Jason,
>
> The policy afaik is still what was laid down here:
> https://groups.google.com/forum/#!msg/puppet-users/yC0TxrTd0aE/_ffh9H55ssAJ
>
> So these kind of job postings are welcome. FYI we moderate the other
> kind usually before most people see them.
>
> ken.
>
> On Tue, Feb 4, 2014 at 6:55 PM, Jason Antman  wrote:
>> CMG Technology is hiring systems and automation/tooling engineers (and
>> Python developers). We're a web shop that runs the web and mobile
>> presences for 70+ newspaper/tv/radio properties, based off of a
>> Python/Django application (supposedly the largest in production
>> anywhere) serving around 10M page views per day. The company offers
>> excellent benefits, and our workforce is largely split between Atlanta,
>> GA and full-time remotes (within the US).
>>
>> We're committed to Puppet as a technology and DevOps as a culture; we're
>> well on the road to having a fully-puppetized infrastructure both in the
>> data center and with cloud providers, we deploy application code at
>> least daily, and we're trying to do cool stuff and scale.
>>
>> We're looking for talented, passionate system engineers and
>> automation/tooling engineers. Puppet is certainly a big plus, but these
>> aren't pure-puppet roles. Our high-level projects at the moment include
>> speeding up deployments (which means everything from production-like
>> local dev VMs to work with Jenkins, CI, automated testing, and fast
>> production deploys/restarts), increasing automation of infrastructure
>> (we've still got an amount that's not puppetized, but we're working fast
>> to change that), automated testing of Puppet changes, and increasing
>> visibility into our infrastructure (graphite, logstash, puppetized
>> nagios/icinga).
>>
>> On the dev side it's all Python, and ops is partial to Python as well,
>> but we know we're too light in Ruby for how much we rely on Puppet, and
>> would like to change that. We're pretty dedicated to the DevOps culture;
>> not only does dev and ops work and play together, and work extremely
>> well as one team, but developers have the same access to our puppet git
>> repo as engineers, and a few of us engineers have pulled development
>> tickets for our main application.
>>
>> A sample of some of the tech we're working with, pulled from our kanban
>> backlog:
>> Puppet3 / PuppetDB, Python, Jenkins, Selenium, NodeMeister (our in-house
>> ENC), Postgres, Memcached, Solr4, ZooKeeper, F5 Viprion, RabbitMQ, KVM,
>> AWS, Icinga, Graphite, Logstash, git, Vagrant.
>>
>> The job descriptions, and a bit about the company and our group, are
>> available at:
>> http://cmgd-jobs.readthedocs.org/en/latest/
>>
>> Please feel free to ping me with any questions, and to pass this along
>> to anyone you know who may be interested. If you're interested, pass
>> along a resume and any other references/resources, and I'll get back to you.
>>
>> Thanks,
>> Jason Antman
>>
>> PS - I hope the community guidelines are still correct, and job postings
>> are welcome here. I've seen very few, but we're hiring multiple
>> positions (scaling out development by about 20%, and the ops/automation
>> teams likewise), so we're trying hard to find the best...
>>
>> --
>>
>> Jason Antman | Systems Engineer | CMGdigital
>> jason.ant...@coxinc.com | p: 678-645-4155
>>
>> --
>> 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/52F13795.8090904%40jasonantman.com.
>> For more options, visit https://groups.google.com/groups/opt_out.


-- 
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/52F13EDC.7030202%40jasonantman.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] [JOBS] systems and automation/tooking engineers - Atlanta, GA, USA or remote in US

[Jason Antman]

CMG Technology is hiring systems and automation/tooling engineers (and
Python developers). We're a web shop that runs the web and mobile
presences for 70+ newspaper/tv/radio properties, based off of a
Python/Django application (supposedly the largest in production
anywhere) serving around 10M page views per day. The company offers
excellent benefits, and our workforce is largely split between Atlanta,
GA and full-time remotes (within the US).

We're committed to Puppet as a technology and DevOps as a culture; we're
well on the road to having a fully-puppetized infrastructure both in the
data center and with cloud providers, we deploy application code at
least daily, and we're trying to do cool stuff and scale.

We're looking for talented, passionate system engineers and
automation/tooling engineers. Puppet is certainly a big plus, but these
aren't pure-puppet roles. Our high-level projects at the moment include
speeding up deployments (which means everything from production-like
local dev VMs to work with Jenkins, CI, automated testing, and fast
production deploys/restarts), increasing automation of infrastructure
(we've still got an amount that's not puppetized, but we're working fast
to change that), automated testing of Puppet changes, and increasing
visibility into our infrastructure (graphite, logstash, puppetized
nagios/icinga).

On the dev side it's all Python, and ops is partial to Python as well,
but we know we're too light in Ruby for how much we rely on Puppet, and
would like to change that. We're pretty dedicated to the DevOps culture;
not only does dev and ops work and play together, and work extremely
well as one team, but developers have the same access to our puppet git
repo as engineers, and a few of us engineers have pulled development
tickets for our main application.

A sample of some of the tech we're working with, pulled from our kanban
backlog:
Puppet3 / PuppetDB, Python, Jenkins, Selenium, NodeMeister (our in-house
ENC), Postgres, Memcached, Solr4, ZooKeeper, F5 Viprion, RabbitMQ, KVM,
AWS, Icinga, Graphite, Logstash, git, Vagrant.

The job descriptions, and a bit about the company and our group, are
available at:
http://cmgd-jobs.readthedocs.org/en/latest/

Please feel free to ping me with any questions, and to pass this along
to anyone you know who may be interested. If you're interested, pass
along a resume and any other references/resources, and I'll get back to you.

Thanks,
Jason Antman

PS - I hope the community guidelines are still correct, and job postings
are welcome here. I've seen very few, but we're hiring multiple
positions (scaling out development by about 20%, and the ops/automation
teams likewise), so we're trying hard to find the best...

-- 

Jason Antman | Systems Engineer | CMGdigital
jason.ant...@coxinc.com | p: 678-645-4155

-- 
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/52F13795.8090904%40jasonantman.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] Pupppet syslog "unrecognised escape sequence" in string

[Jason Antman]

Your exec resource has a double-quoted string.

1) You're not doing variable interpolation, so that should be a
single-quoted string (per the accepted style).
2) Puppet *happens* to allow "\#". The docs on Puppet string types and
escaping
(https://docs.puppetlabs.com/puppet/3/reference/lang_datatypes.html#double-quoted-strings)
clearly list the allowed escape sequences. As \# isn't one of them, you
should be doubling the leading "\" to escape it.

If you do keep that as a double-quoted string, you need to escape $ as well.

-Jason

On 02/04/2014 11:15 AM, Andreas Dvorak wrote:
> Dear all,
>
> I have several exec resources that work fine, but the puppet master
> throws a syslog message
>
> "Unrecognised escape sequence \# in file
> /data/git/simulation/modules/base_modification/manifests/only_solaris.pp
> at line 14"
>
> 14: exec{ "/bin/sed '\#^/home#d' /etc/auto_master > /tmp/sed.tmp.$$ &&
> mv /tmp/sed.tmp.$$ /etc/auto_master":
> 15:onlyif => "/bin/grep '^/home' /etc/auto_master"
> 16:  }
>
> I do not want to filter that mesage, but how can tell puppet this is
> fine or do I need to change the exec resource.
>
> 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/df83f496-54cb-4c65-9382-dd907c0393d9%40googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.


-- 
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/52F123A6.4040205%40jasonantman.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] Puppet vs "typical" release management / change management

[Jason Antman]

Steve,

I'll leave it up to others to answer your question more directly, as I'm 
not sure I really can - it's been a while since I worked in an ITIL 
shop. What I will say, though, since inevitably *someone* will, is that 
ITIL contains some good concepts and some bad ones. Overall, I'd never 
work in an ITIL shop again, I find it far too restrictive and slow.


When you mentioned "the devops approach", are you referring to agile and 
deploying/releasing very often? Or... something else?


In my opinion (and yes there are very smart people who feel otherwise) 
ITIL is a band-aid for having poor review processes, poor testing, and 
people who either don't know what they're doing or can't take 
responsibility. I work in a web shop that deploys application code about 
twice a day, which most of us consider to be painfully slow. We treat 
Puppet as "infrastructure as code" - we make a change, have a git branch 
peer-reviewed, deploy to a development server and test there (which will 
ideally be automated in the future, via both rspec and server-spec, and 
some tests against monitoring), assuming the tests pass we push to an 
identical test environment, and if it passes there too, we push to 
production.


So, to cut short the ITIL-bashing (under the assumption that you 
probably didn't choose ITIL for your organization, and any more of it 
will have you cursing my name), if by "devops" you meant rapid 
deployment/release or even continuous deployment/release, then I'd go so 
far as to say it's totally in conflict with the low-confidence, 
slow-moving CAB approach of ITIL.


The other thing I should mention is that we're a pretty strong devops 
shop - culturally (as is the meaning of devops) and in practice. We work 
extremely closely with dev, engineers/ops are involved in all dev 
tickets from the first elaboration, ops is included on most dev code 
reviews and vice versa. That's probably a requirement to make things 
work smoothly as I mentioned above.


-Jason

On 02/04/2014 05:05 AM, Steven James wrote:

Hi there.

I'm look to see if anybody has any advice to share around how the 
implementation of Puppet affects the "typical"  ITIL based release 
management and change management processes.


From a change perspective, I'm thinking that the whole risk thing 
associate with the CAB for example, should get a whole lot better as a 
result of version controlled infrastructure manifests, ability to 
provide infrastructure code diffs, noop runs against bare metal, with 
the option of running a few noop runs against current patch set...will 
probably help.


How else does the ITIL base change process have to typically (er) 
change...to accommodate the devops approach?


Similar question for release management. How does the introduction of 
Puppet typically affect the release management process?


Any input greatly appreciated.

SteveJames
--
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/CAB_ORUv5NbgL-L4SattZ5y5V9G0r4BHgfVx6Pd-WVp8frHcdXg%40mail.gmail.com.

For more options, visit https://groups.google.com/groups/opt_out.


--
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/52F0E6E9.5040309%40jasonantman.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] ENC - how to set order of operations?

[Jason Antman]

Disregard some of what I said. Sorry for the confusion. Stages can only 
be used on classes not individual resources, so that won't work as 
cleanly with forge modules (or anything that isn't specifically setup to 
use stages).


On 02/04/2014 07:43 AM, Jason Antman wrote:

Jon,

I've been using ENCs for quite a while, and have never used them with 
site manifests (or any other manifests outside of modules). At the 
moment, when I do things like that, I either do them inside a class 
(i.e. put what you have in a wrapper class), or use "require" on all 
resource instances.


My plan in the near future, which AFAIK is at least close to best 
practice and is (at least in my opinion) the most elegant and "right" 
way to do this, the is to use run stages to handle all Package 
resources in a "setup" stage, and then add a stage before that that 
handles repository setup. Though this will probably also require a 
site.pp to setup the stage for all Package resources.


For more information on run stages, see:
- http://docs.puppetlabs.com/puppet/3/reference/lang_run_stages.html
- the default stages setup by puppetlabs-stdlib - 
https://github.com/puppetlabs/puppetlabs-stdlib/blob/master/manifests/stages.pp


-Jason

On 02/03/2014 01:51 PM, Jon Yeargers wrote:
So if a given node is named in both an ENC and the site manifest... 
it will use both? IE If I have some definitions that I want to send 
everywhere and others that are node specific.. I can use both types 
of node entries?


On Monday, February 3, 2014 10:14:52 AM UTC-8, Dan Bode wrote:




On Mon, Feb 3, 2014 at 9:45 AM, Jon Yeargers > wrote:

Right. So how would I declare this dependency setup if I stop
using node files?


Even if you use an ENC, Puppet will still consult your site
manifest, so using an ENC does not preclude you from setting
resource dependencies via collection in your site manifest.



On Monday, February 3, 2014 9:33:40 AM UTC-8, Jose Luis
Ledesma wrote:

Hi

Perhaps  I'm confused but an ENC stores node definition
and not collector nor dependencies...doesn't it?

Regards,

El 03/02/2014 16:13, "Jon Yeargers" 
escribió:

I need to convert my resource based system to ENC.
It's mostly straightforward but I'm not sure how to
handle operations like these:

|Class['apt'] -> Package<| |>|

-- 
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/b6324c21-3725-480d-b2ab-33ee48577ba6%40googlegroups.com

<https://groups.google.com/d/msgid/puppet-users/b6324c21-3725-480d-b2ab-33ee48577ba6%40googlegroups.com>.
For more options, visit
https://groups.google.com/groups/opt_out
<https://groups.google.com/groups/opt_out>.

-- 
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/89c4d5d6-1f79-454c-8d22-1e1fb9ce15d6%40googlegroups.com

<https://groups.google.com/d/msgid/puppet-users/89c4d5d6-1f79-454c-8d22-1e1fb9ce15d6%40googlegroups.com>.


For more options, visit
https://groups.google.com/groups/opt_out
<https://groups.google.com/groups/opt_out>.


--
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/d0568d5a-450f-45e3-9d4e-7d85e2e07d60%40googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.


--
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/52F0E059.7000602%40jasonantman.com.

For more options, visit https://groups.google.com/groups/opt_out.


--
You received this message because you are

Re: [Puppet Users] ENC - how to set order of operations?

[Jason Antman]

Jon,

I've been using ENCs for quite a while, and have never used them with 
site manifests (or any other manifests outside of modules). At the 
moment, when I do things like that, I either do them inside a class 
(i.e. put what you have in a wrapper class), or use "require" on all 
resource instances.


My plan in the near future, which AFAIK is at least close to best 
practice and is (at least in my opinion) the most elegant and "right" 
way to do this, the is to use run stages to handle all Package resources 
in a "setup" stage, and then add a stage before that that handles 
repository setup. Though this will probably also require a site.pp to 
setup the stage for all Package resources.


For more information on run stages, see:
- http://docs.puppetlabs.com/puppet/3/reference/lang_run_stages.html
- the default stages setup by puppetlabs-stdlib - 
https://github.com/puppetlabs/puppetlabs-stdlib/blob/master/manifests/stages.pp


-Jason

On 02/03/2014 01:51 PM, Jon Yeargers wrote:
So if a given node is named in both an ENC and the site manifest... it 
will use both? IE If I have some definitions that I want to send 
everywhere and others that are node specific.. I can use both types of 
node entries?


On Monday, February 3, 2014 10:14:52 AM UTC-8, Dan Bode wrote:




On Mon, Feb 3, 2014 at 9:45 AM, Jon Yeargers > wrote:

Right. So how would I declare this dependency setup if I stop
using node files?


Even if you use an ENC, Puppet will still consult your site
manifest, so using an ENC does not preclude you from setting
resource dependencies via collection in your site manifest.



On Monday, February 3, 2014 9:33:40 AM UTC-8, Jose Luis
Ledesma wrote:

Hi

Perhaps  I'm confused but an ENC stores node definition
and not collector nor dependencies...doesn't it?

Regards,

El 03/02/2014 16:13, "Jon Yeargers" 
escribió:

I need to convert my resource based system to ENC.
It's mostly straightforward but I'm not sure how to
handle operations like these:

|Class['apt'] -> Package<| |>|

-- 
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/b6324c21-3725-480d-b2ab-33ee48577ba6%40googlegroups.com

.
For more options, visit
https://groups.google.com/groups/opt_out
.

-- 
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/89c4d5d6-1f79-454c-8d22-1e1fb9ce15d6%40googlegroups.com

.


For more options, visit
https://groups.google.com/groups/opt_out
.


--
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/d0568d5a-450f-45e3-9d4e-7d85e2e07d60%40googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.


--
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/52F0E059.7000602%40jasonantman.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] puppet jobs list?

[Jason Antman]

Thanks to both Chris and Peter for their tips/advice.

I'm familiar with the ThoughtWorks DevOps hiring presentation Yes, 
cultivating talent is good preferred. We've already got some good puppet 
knowledge on the team; we're not so much looking to hire "because we 
need Puppet knowledge" as we're looking to grow our engineering and 
automation teams from ~11 people to almost 20, and we've made a big 
enough investment in Puppet that hiring at least one specifically for 
advanced Puppet skills is desired.


Thanks,
Jason

On 02/01/2014 10:46 AM, Christopher Wood wrote:

No idea on job boards these days, but in 2008 I was hired as a systems 
administrator based on my application to a job posted on workopolis.com. (I 
hadn't heard of puppet at that point.)

I notice that places I read like http://highscalability.com offer sponsored Job 
Openings posts, for example:

http://highscalability.com/display/Search?moduleId=4876569&searchQuery=job+openings

Also more companies are running their own infrastructure blogs, with an "if you like 
this we're hiring" tagline. To wit:

http://word.bitly.com/post/74839060954/ten-things-to-monitor

But finally, a puppetconf 2013 presentation suggested you have your own 
existing talent do things, which sounds like your best bet:

http://www.slideshare.net/PuppetLabs/stophiringstartgrowing-130823160712phpapp01

On Sat, Feb 01, 2014 at 10:14:09AM -0500, Jason Antman wrote:

Is there a puppet jobs list or board anywhere? (not jobs at PL, jobs
dealing with Puppet)

If not, where would you advertise/post (or look, I guess) for engineers
with strong puppet skills, both on the usage/admin side, and skilled
ruby devs (preferably with some Puppet experience)?

We'er hiring, and having abysmal luck with wherever our internal and
external recruiters have posted.

Thanks for any tips/ideas,
Jason

--

Jason Antman | Systems Engineer | CMGdigital - Atlanta, GA, USA
jason.ant...@coxinc.com | p: 678-645-4155


--
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/52ED0F41.6060607%40jasonantman.com.
For more options, visit https://groups.google.com/groups/opt_out.


--
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/52EF97A8.6050802%40jasonantman.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] puppet jobs list?

[Jason Antman]

Is there a puppet jobs list or board anywhere? (not jobs at PL, jobs
dealing with Puppet)

If not, where would you advertise/post (or look, I guess) for engineers
with strong puppet skills, both on the usage/admin side, and skilled
ruby devs (preferably with some Puppet experience)?

We'er hiring, and having abysmal luck with wherever our internal and
external recruiters have posted.

Thanks for any tips/ideas,
Jason

-- 

Jason Antman | Systems Engineer | CMGdigital - Atlanta, GA, USA
jason.ant...@coxinc.com | p: 678-645-4155


-- 
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/52ED0F41.6060607%40jasonantman.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] What is the best replacement for Puppet Dashboard ?

[Jason Antman]

That issue should be fixed "soon", I'm told. The reports do get sent to
puppetboard, but the report processor throws an unhandled exception
because it references one of the 'metrics' hash fields, which is empty
in failed reports (this should be fixed in master to log an error
message instead). However, the bigger issue is that (a) puppet reports
only include per-resource statuses, not an overall status, so there's
nothing in the current report format that indicates that it was a failed
run, let alone why, and (b) there's no place to store that information
in the PuppetDB schema (yet) once it makes it into the reports.

If you're interested in this issue, you should watch the following issues:
[PDB-16] Store status for reports - Puppet Labs Tickets -
https://tickets.puppetlabs.com/browse/PDB-16
[PDB-36] Add agent run failure information to reports - Puppet Labs
Tickets - https://tickets.puppetlabs.com/browse/PDB-36
[PUP-283] Improve agent error reporting - Puppet Labs Tickets -
https://tickets.puppetlabs.com/browse/PUP-283
[PUP-916] Document report format changes for improved agent reporting -
Puppet Labs Tickets - https://tickets.puppetlabs.com/browse/PUP-916

-Jason

On 01/30/2014 07:59 AM, Klavs Klavsen wrote:
> I use puppetboard too - it's really great, and much lighter on the
> database. A big improvement on puppet-dashboard.
>
> Only one issue remains, that means I must keep my puppet-dashboard..
> There's a bug in the puppetdb-terminus - so nodes which manifest fails
> compilation fails - does NOT get a report send to puppetboard, so you
> can't catch failing compilation failures :(
>
> Odlly enough, puppet does send the http reports when there's a failed
> compilation - so puppet-dashboard knows about them.
> -- 
> 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/008d0d13-10f1-496c-8589-a451df72a0b1%40googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.


-- 
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/52EAFEA3.20401%40jasonantman.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] What is the best replacement for Puppet Dashboard ?

[Jason Antman]

For the reporting side, I'm using a Python project called PuppetBoard at
the moment - https://github.com/nedap/puppetboard - and it does
everything I liked about Dashboard, and also loads pages in a not just
reasonable but fast amount of time. It pulls directly from PuppetDB.

In terms of the ENC side, I'm currently using a Python/Django ENC (
https://github.com/jantman/nodemeister/tree/develop ) which can itself
be installed with a module (
https://github.com/jantman/puppet-nodemeister/tree/install_fixes ). It's
feature-complete on the ENC side, including support for inheritance and
overrides/exclusions, and actually supports parameterized classes (and
global params of any data type you can push into the yaml). We're using
it in production, but it's really still proof of concept - there's a
bunch of annoying things like selects ordered by ID instead of name,
having to input param values and class params as JSON, etc. And its only
interface is currently the Django Admin, which is pretty awful looking.

I took over the code from someone else, so I'm in the process of taking
it from 0 tests to full-ish coverage, and then building out the long
list of features we have. One of those is integration with PuppetBoard,
to make this an all-in-one ENC and reporting/dashboard solution.

It's not ready for prime time yet, but if anyone is interested in
looking at it or submitting PRs, that would be greatly appreciated.

-Jason

PS - As an aside, we wrote this mainly because we did *not* want
Foreman. What we wanted was Puppet Dashboard's ENC features (nodes and
groups, and boxes to type stuff in, but no "magic") with support for
parameterized classes and deep data structures, class/param overrides at
any level, class/param exclusions, and a simple REST API for all of it.

On 01/28/2014 08:51 AM, Thomas Bendler wrote:
> As far as I know, there is nothing available yet that can compare with
> foreman in terms of functionality. There are some reporting projects
> available, but if you want to use the dashboard as an ENC as well,
> there is know alternative to foreman.
>
> Regards Thomas
>
>
> 2014-01-28 kaustubh chaudhari  >
>
> Hi All,
>
> As we all know Puppet Dashboard is now EOL, with that said what is
> the best replacement for the same? We do need a graphical way of
> managing and reporting!
>
> Any thoughts or suggestion! I am looking at Forman, but havent
> explored it yet!
>
> -Kaustubh
> -- 
> 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/15cfd564-c8eb-493e-8db6-4b2247da1e95%40googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
>
> -- 
> Linux ... enjoy the ride!
> -- 
> 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/CAELoU1OfHkmwsYQB2TJzd6V-6PSmCOgsAWZ2BX0m1ygUFGR%2Bgw%40mail.gmail.com.
> For more options, visit https://groups.google.com/groups/opt_out.


-- 
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/52E8E945.1060606%40jasonantman.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] DashboardQuery

[Jason Antman]

I haven't used a dashboard version newer than... 2 years old or so... 
but as of that version, and the version of Console that shipped with 
Puppet Enterprise 2.5, no, this isn't possible. It's been a feature 
request for years, and is one of the main factors that drove me to 
develop my own ENC.


-Jason

On 01/24/2014 06:39 AM, kaustubh chaudhari wrote:

Hi,

Is there a way to track which admin did what task in dashboard.

I have a admin team who will be using Dashboard, i am worried that i 
will not be able to track who did what?


Is there a way to track it ?

Can some one redirect me to the appropriate documentation ?

-Kaustubh
--
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/b532f951-841a-4ec2-bb40-7d656c78f71a%40googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.


--
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/52E2579D.1030401%40jasonantman.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] roll back update

[Jason Antman]

There's nothing existing that I know of that works in the GUI-based way
you seem to be talking about. Because, well, we *nix people usually
don't do that.

I've really only worked on RPM-based systems, so I'm not sure if this is
still applicable in the debian world...

There are 2 types of updates I do

1) updating one package or a set of packages (like, updating Puppet from
3.1.0 to 3.4.1) which I do with the "ensure" parameter on the Package
type. Some stuff is wrapped up in classes, and this can be done through
an ENC (parameterized classes, or global params if need be) or Hiera.
I'll change the version on one node, test it, then an environment, test
it, and eventually apply it everywhere. If you need to downgrade/roll
back, that *can* work... might work better in the apt/deb world than it
does in yum/rpm.

2) Full system updates/upgrades, what RHEL-derivatives term as
"distribution upgrades", i.e. updating all packages from CentOS 6.3 to
6.4. I rebuild the box. No reason to mess with doing this through the
distro, I just shut it down, clean the cert in puppet, do a fresh PXE
boot (and kickstart) and let Puppet do its thing. This has the added
benefit of reducing entropy, and even providing a nice DR test (like if
you just log in and poweroff immediately...)

-Jason

On 01/22/2014 09:31 AM, Muhammad Yousuf Khan wrote:
> Hello All,
>
> i have seen so many apt modules on puppet forge website. they are more
> like changing source list path defining. HTTP proxy blah blah but what
> i want is a bit more.
> is there any apt module  which can help me to update only selective
> updates (like in Microsoft Wsus does, it list down all the updates and
> people can select and apply those patches on selective nodes and if
> they find it problematic then can remotely uninstall it too.i want
> this to be done on my Debian server farm and and i also want to roll
> back as needed (for example if any securety or OS update creating
> problem of some kind i can roll it back with puppet live
> management/manual run).
> i dont know how practical it is. however as i have already got the
> concept of Wsus therefore my mind is trying to think of wsus like
> puppet module.
> Please help.
> thanks,
> MYK
> -- 
> 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/46482f37-c6e1-4242-b87e-f689a3c11016%40googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.


-- 
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/52E04645.5010106%40jasonantman.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] Puppet failed run: How to find?

[Jason Antman]

Kaustubh,

The *easiest* method would be to use PuppetDB, but until a feature
request (https://tickets.puppetlabs.com/browse/PDB-16) is finished, it
only stores successful reports, not failed ones. Hopefully that ticket
will get closed soon, but it would probably be at least weeks until it
gets released.

If you're comfortable with it, you can hook into the Puppet Dashboard
database to pull out the information you want. I don't think there are
any real documents about it, because the database isn't really intended
to be used by anything other than Dashboard itself. But the schema is
pretty stable. You should be able to just connect to MySQL as the same
user that Dashboard uses and find what you need - the schema is pretty
straightforward. If you need a rough example, you can take a look at a
Nagios check I wrote that uses the Dashboard DB
(https://github.com/jantman/nagios-scripts/blob/master/check_puppet_dashboard_node.pl)
though it may be for an older version of Dashboard, so some things may
have changed.

The last thing you could do, which is probably the most time consuming,
is to implement your own custom report processor in Ruby to do whatever
you want with the reports. Documentation on this can be found in the
Reporting Guide, at http://docs.puppetlabs.com/guides/reporting.html

-Jason


On 01/17/2014 07:20 AM, kaustubh chaudhari wrote:
> Hey Jason,
>
> Thanks for the email!
>
> Yes i am using Open Source Puppet! 3.3.2 and dashboard version 1.2.23.
>
> I would appreciate if you can redirect me or share a link regarding
> the options that you mentioned.
>
> -Kaustubh
> -- 
> 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/8ead04a4-d72c-47a3-8b4a-31ec7b4fd25a%40googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

-- 
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/52D92307.807%40jasonantman.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] Dynamic lookup deprecation warning

[Jason Antman]

Andrea,

Ok, now I see your question more clearly, about the missing information.
I've seen this before as well, but don't remember why. I *believe* (but
may be totally wrong) it's something about included or required classes,
and that by time the dynamic lookup is evaluated, the source line where
it occurred is no longer known.

Someone else will probably chime in and correct me if my memory was
totally inaccurate.

-Jason

On 01/17/2014 07:19 AM, Andrea Cappelli wrote:
> Il 17/01/2014 13:12, Jason Antman ha scritto:
>> On 01/16/2014 11:56 AM, Andrea Cappelli wrote:
>>> Hi,
>>> I'm searching through the logs of my master for the warning in the
>>> subject, to move to Puppet3
>>>
>>> Sometimes in the warning the manifest name isn't showed up, thereis a
>>> reason?
>>>
>>> Thu Jan 16 14:58:02 +0100 2014 Puppet (warning): Dynamic lookup of
>>> $mailaddr is deprecated. For more information, see
>>> http://docs.puppetlabs.com/guides/scope_and_puppet.html. To see the
>>> change in behavior, use the --debug flag.
>> Have you tried running with the --debug flag as suggested?
>
> Using --debug doesn't give me more info on the path where the error
> is, only adds info about what changed. My problem is that I don't
> know  (exactly) where to find ythe manifests
>
>> Have you tried just grepping your modules/manifests for "$mailaddr" ???
>
> Sure, and with some work I can find all problems, I was just wondering
> why in some cases the path is showed and in some others it isn't
>
>
>> There's a specific location: Dynamic lookup of $domain at
>> /path/to/a/file/dotpp.pp/:127
>
> I pick up 2 lines form my log file to show that for some warning the
> path is reported (as in this case) but in other case (the former log
> line) it isn't
>
>
> Thanks for your help
>

-- 
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/52D92121.40205%40jasonantman.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] Puppet failed run: How to find?

[Jason Antman]

Kaustubh,

There are many, many ways to do this. Perhaps you could tell us what
version of Puppet you're running? By "dash board" I assume you mean the
open source Puppet Dashboard? Or are you running Puppet Enterprise?

The best way that I could tell you to do this is by using a custom
report processor, or by pulling the data out of the Puppet Dashboard
database (or PuppetDB, which will make this even easier). For
information on how to do that, see docs.puppetlabs.com.

-Jason

On 01/17/2014 02:35 AM, kaustubh chaudhari wrote:
> Hi All,
>
> How can i find all the failed puppet run in last 30 days!
>
> In dash board i can see if the agent run is failing, but if it has
> recovered it will be green again.
>
> Practically it not possible to see the Daily run status and look for a
> red mark if i have 3000 servers.
>
> Is there a way i can see all the failed reports for last 30 days!
>
> Kaustubh
> -- 
> 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/c4d6aca5-4ed8-4f31-91bb-a9a47b0a788b%40googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

-- 
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/52D91EA5.1070609%40jasonantman.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] Dynamic lookup deprecation warning

[Jason Antman]

On 01/16/2014 11:56 AM, Andrea Cappelli wrote:
> Hi,
> I'm searching through the logs of my master for the warning in the
> subject, to move to Puppet3
>
> Sometimes in the warning the manifest name isn't showed up, thereis a
> reason?
>
> Thu Jan 16 14:58:02 +0100 2014 Puppet (warning): Dynamic lookup of
> $mailaddr is deprecated. For more information, see
> http://docs.puppetlabs.com/guides/scope_and_puppet.html. To see the
> change in behavior, use the --debug flag.
Have you tried running with the --debug flag as suggested?

Have you tried just grepping your modules/manifests for "$mailaddr" ???
>
> Thu Jan 16 17:09:07 +0100 2014 Puppet (warning): Dynamic lookup of
> $domain at /path/to/a/file/dotpp.pp/:127 is deprecated. For more
> information, see
> http://docs.puppetlabs.com/guides/scope_and_puppet.html. To see the
> change in behavior, use the --debug flag.
There's a specific location:
Dynamic lookup of $domain at /path/to/a/file/dotpp.pp/:127
>
> How can I easy discover where the dynamic lookup occurs in the first
> case?
>
> Thank you
>

-- 
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/52D91E17.9060404%40jasonantman.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] Re: Puppet calls the ENC twice for some nodes.

[Jason Antman]

James,

I vaguely remember seeing this 'node_terminus called twice' thing in the
past. The simple answer, though I know it's not what people want to
hear, is that the ENC should always return the right information. If you
want to modify the content of the catalog based on something that
happens between runs (which, by the way, I would highly suggest against,
and suggest that if you're doing that, something in your puppet
configuration is amiss), you should be checking somewhere like PuppetDB,
not changing it based on how many times the ENC script is run. Aside
from the problem you're having now, what happens if there's a timeout,
or some other failure after the ENC script is called but before the
catalog is applied?

-Jason

On 01/14/2014 06:20 PM, James Ellis wrote:
> Hi, chanced across this discussion when I noticed an ENC was being
> called twice. I understand I may not be using the ENC terminus exactly
> as it's been designed, but it's unexpected that it was called twice.
> Also worth noting that I can't see a note about the ENC being called
> twice here: http://docs.puppetlabs.com/guides/external_nodes.html
>
> In my case, I'm using an ENC to push virtual host changes to an agent
> running a web server, the YAML returned by the ENC uses
> create_resources to dynamically add resources to the catalogue.
> I observed via logging in the ENC script that on the first run, the
> ENC was excecuted but the catalogue was not applied, on the second run
> the catalogue was applied on the agent.
> This causes problems where we use an API to dynamically apply
> resources to a catalogue (1st run gets the catalogue resources,
> returns 'OK' to the API, 2nd run then tries to get resources but gets
> nothing as the 'OK'  sent to the API has effectively modified the
> resources to be applied).
>
> I've worked around this, for now, by using a lock file, so that the
> 'OK' API call is only run once but this still applies two calls to the
> API to dynamically get resources for the catalogue, where only one is
> required. I double checked the master and the agent configs, and the
> master only shows the ENC being referenced once and there is one
>  agent being run, only.
>
> Based on this, is there any way the agent can be set to call the ENC
> once only ? The only argument to the script is the agent hostname and
> there is no apparent difference in the environment of the first and
> second ENC calls.
>
> Using 3.4 O/S on ubuntu with the following agent command (run as root
> manually to debug) :
> puppet agent --no-usecacheonfailure --onetime --no-daemonize --server
> valid.server --verbose
>
>
> Thanks
> James
>
>
> On Monday, 23 September 2013 23:59:45 UTC+10, jcbollinger wrote:
>
>
>
> On Friday, September 20, 2013 12:05:17 PM UTC-5, Greg Sutcliffe
> wrote:
>
> Is this puppet3? As I recall, in puppet3, the master makes a
> separate call to the enc to determine the environment the
> should authoritatively be in. Once that's established, it
> makes a second call to get the classes and parameters.
>
>
> Not exactly, but that may well be the right track.  It would be
> pointless for the master to run the ENC more than once for catalog
> compilation, for it would have no reason to expect that the ENC's
> output would change.  HOWEVER, the master's file server may need
> to run the ENC again to determine the environment from which to
> serve 'source'd files.
>
>
> 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/373455ff-43f4-4f27-8667-ab896c240ea6%40googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

-- 
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/52D5E717.1060604%40jasonantman.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] The Future - ENCs vs Hiera?

[Jason Antman]

I guess I hit a bit of a nomenclature issue here. By "ENC" I didn't just
mean the node_terminus script, but the whole app - i.e. "ENC" as in the
way Dashboard is an ENC...

Though your comment does remind me that Hiera can now be more than "a
directory full of YAML files"... I guess I'll start doing some research
into hiera backends, and what they can (could possibly) do for me...

Thanks
-Jason

On 01/04/2014 10:43 AM, Peter Meier wrote:
> > But as I'm starting down the road of writing *another* ENC -
> > hopefully "a good one" this time - and more and more people whose
> > advice and knowledge I've respected for years say "use Hiera", I'm
> > starting to wonder if either (a) I'm totally missing something, or
> > (b) the community is increasingly ignoring a subset of us who, in
> > fact, don't want every bit of configuration data committed to a git
> > repo and/or like web UIs for certain things and/or need to
> > manipulate that data via an API.
>
> What you need to do is to write a tool that can act as an interface
> for a datastore for your server data.
>
> Your datastore then can then be used either by an ENC or hiera (write
> your own backend, dump the data in a supported hiera format, ...).
>
> Hiera has various advantages over an ENC and all the things that you
> can do with an ENC are also possible within hiera, but not the other
> way round.
>
> Hence, if you build your interface the way that it can be used by both
> techniques you're on the safe side and very flexible (you could even
> use it in a mix mode). And actually if you think a little bit further,
> it's actually not a big thing to support both ways of handing data
> over to puppet.
>
> ~pete
>
>


-- 
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/52C83661.7010005%40jasonantman.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] The Future - ENCs vs Hiera?

[Jason Antman]

After digressing into this discussion on #puppet last night, I was
wondering what the community feelings are on ENCs vs Hiera...

I know that Dashboard/Console still exists, but have heard rumors (for
years) of it being either replaced by something else, or totally
rewritten. Then there's Foreman, and a bunch of us with homegrown ENCs.
On the other hand, it seems that the bleeding edge of the community, or
many of those who are most active and knowledgeable, eschew the ENC idea
and generally respond with "use Hiera".

- Am I right that a community consensus seems to be forming around "ENCs
are bad" or "Don't use ENCs", use Hiera instead, essentially for
everyone other than Puppet Enterprise users who get a supported Console
install?
- If so, is this because of some actual failing of ENCs, or is it
because the currently available ENCs fail in certain areas?

I'm a fan of ENCs. I'm just starting work on my... third... that will
hopefully become a real thing, not just some in-house script. I like the
promise of being able to integrate report processing and *certain*
configuration on one screen in a web interface, hook it up to other
tools, give fine-grained access control (i.e. on the parameter level,
theoretically), and (unlike Hiera) easily see every class/param applied
to my node in one place. I also like - really, need - the fact that I
can change configuration data in my ENC via its API, from Jenkins or
arbitrary cli scripts...

But as I'm starting down the road of writing *another* ENC - hopefully
"a good one" this time - and more and more people whose advice and
knowledge I've respected for years say "use Hiera", I'm starting to
wonder if either (a) I'm totally missing something, or (b) the community
is increasingly ignoring a subset of us who, in fact, don't want every
bit of configuration data committed to a git repo and/or like web UIs
for certain things and/or need to manipulate that data via an API.

I'm sure (hope) I'll get more than a few informed responses to this, and
probably a bit of a holy war too. But I'm starting to question the way
I've looked at this for a long time (and ENC is a good thing).

Thanks,
Jason / jantman

-- 
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/52C810D2.20501%40jasonantman.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] ENC in Nodejs Error

[Jason Antman]

I *think* that "Empty response" is the issue here... your script appears
to be sending back YAML with just an (empty) classes hash and an (empty)
parameters hash. Try putting something in parameters (at least). Also
make sure that it's actually writing to STDOUT, not STDERR.

Assuming neither of those are the problem...

- Are you running the script as the same user that Puppet runs as? With
the same path?
- Does puppet.conf have the absolute path to the script?
- Are you *sure* you're calling it the same way puppet is? If you run
your puppetmaster in --debug mode, when a node checks in for its
catalog, you should see a log entry with the full path and arguments to
the command that's being run, like:
Debug: Executing '/etc/puppet/my_terminus.sh node_hostname.example.com'
- Are the permissions right (the script needs to be executable)?

Generally when I've had problems like this, they've been either
permissions-related, or path-related (i.e. your script is #!/usr/bin/env
node, which assumes that node is actually in puppet's path). I'd
recommend doing a "sudo su - username" to the user that Puppet runs as,
confirming your env and path, and then trying the script.

-Jason

On 01/03/2014 09:16 AM, Jordan Cabral wrote:
> Hi,
> Im writing a simple ENC in Nodejs.
> When I run the script manually with some hostname it returns a valid
> YAML (tested on http://yaml-online-parser.appspot.com/)
> But when I run it from puppet I gen an error "Could not find node
> 'xxx'; cannot compile" in the client
> and "Empty response for hosname from exec terminus" when debugging the
> master
>
>
> I tested with a simple bash scipt with empty class and work ok:
> 
> #!/bin/sh
>
> echo '---
> parameters:
> '
>
> exit 0
>
> 
>
>
>
>
> *_Nodejs script example:_*
> 
> #!/usr/bin/env node
>
> var yaml = require('js-yaml');
>
> //Initialize ENC classes
> var nodeParameters = {};
> var nodeClasses = {};
>
> /*
> Fill parameters and classes objects
> */
>
> var nodeConfig = {classes: nodeClasses, parameters: nodeParameters};
> console.log(yaml.safeDump(nodeConfig));
> process.exit(0);
> 
>
>
> Some idea about what i'm doing wrong, or how can debug this error?
>
> Thanks!
> -- 
> 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/7976eb3c-1f20-4d2c-98f4-3e19b33a8eca%40googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

-- 
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/52C80E0B.2020005%40jasonantman.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] Re: wondering if I want to much now.

[Jason Antman]

This is one of the best descriptions of how to do things in Puppet (or
maybe how not to) that I've seen, and touches on a *lot* of common
misunderstandings.

I think I might have to keep a short url to the archive of this handy...

Thanks, John.

On 01/03/2014 10:35 AM, jcbollinger wrote:
>
>
> On Thursday, January 2, 2014 8:28:33 AM UTC-6, Jelle B. wrote:
>
> Hi all,
>
> I have been kinda stuck  with the following few issues (all
> related to one and other)
>
> What I want ot ddo is define a couple of standard actions in
> puppet that I can use across all my classes.
> So for example I define a exec for apt-get update , or a reload.
> When built in to a class it works fine I would just have to
> redeclare it with an other name in the next class and I want to
> get away from it.
>
>
>
> Part of your problem may be that you have a wrong conception of Puppet
> DSL.  The DSL is not a scripting language; in fact, it is not an
> imperative language at all.  There are no "actions" in it.  You need
> to discard the mindset that you are telling Puppet what to do. 
> Instead, embrace the concept that you are describing to Puppet what
> state it needs to achieve.
>
>  
>
> Now I have started working on importing it via my site.pp but I
> can not define say the exec for "service $service_name reload", it
> will generate an error when I include it : Must pass service_name
> to Class[Defaults] (class defaults being the collective class I
> brought all these snippets together)
>
>
>
> With respect to services in particular, you are likely to be better
> off relying on the Service resource than to roll your own service
> management via Exec resources.
>
>  
>
> So question one am I on the right path in creating this , using
> the top scope prinocipal in my design for this.
>
>
>
> I think not, but it's hard to tell because I don't know what you mean
> by "using the top-scope principal".  On the other hand, you are right
> to be trying to consolidate redundant declarations and to avoid
> repeating yourself.
>
>  
>
> Second question how do I pass a variable in this setup , as I can
> not include the class in site.pp as it will generate the "must
> pass error" but just doing an import in my site.pp and then an
> include in my module init.pp does not actually work either but
> then silentlly. 
>
>
>
> The "import" function and the "include" function do very different
> things.  You use "import" to persuade Puppet to parse a /manifest
> file/ that it otherwise would not parse (because it's in the wrong
> place for the autoloader to find it or because there is nothing to
> trigger the autoloader to load it in the first place).  That has
> little to do with declaring classes on the target node, and there are
> very few good use cases for it in modern Puppet.  Instead, put your
> classes and defined types in modules, laid out appropriately for
> autoloading.
>
> The "include" function, on the other hand, instructs Puppet that the
> named /class/ must be included in the target node's catalog.  That is
> sometimes referred to as "declaring" the class.  This form of class
> declaration does not explicitly specify any class parameters, which
> can be useful.
>
> In your case, however, it appears that your class has a defined
> parameter with no default value.  If you must use class parameters --
> a discussion that I will omit for now -- then you must ensure that
> each parameter of each declared class is assigned a value exactly
> once.  Parameter values can come from these places (from highest
> precedence to lowest):
>
>   * from a parameterized-style class declaration or ENC-based class
> declaration
>   * from hiera via automated data binding (Puppet 3+ only)
>   * from a default value specified in the class itself
>
> I predict that you will be inclined to use parameterized-style class
> declarations, but I urge you to avoid them.  They will cause you
> grief.  Instead, avoid parameterization where it is unneeded, define
> sensible default parameter values, and use Hiera to provide parameter
> overrides where necessary.
>
>  
>
> I am missing somethign I think just not sure what and where .
>
>
>
> You are missing several things, I suspect.  Among them may be that
>
>   * classes are idempotent -- declaring the same class more than once
> has no different meaning than declaring it exactly once
>   * defined types and custom functions are therefore better vehicles
> for parameterized declarations that you want to reuse within the
> scope of the same node's catalog 
>   * Puppet terminology incorporates some words from the
> object-oriented programming world that may mislead people with OO
> programming background.  In particular,
>   o a Puppet "class" is not a model or type for objects, rather it
> represents a classification of the target node.  There are no
> class instances, or if that's too a

Re: [Puppet Users] MCollective/Puppet - one-time run with other options

[Jason Antman]

Thanks for the lengthy explanation. I suppose that, for one thing, I
didn't understand the algorithm that was used in puppetcommander. The
one thing that will complicate this for me is my horribly poor ruby
skills, coupled with the fact that the MCo python bindings appear to be
abandoned (though I found what appears to be a not-yet-complete
replacement for them at https://github.com/rafaduran/python-mcollective).

Understood about the 3 variables, and I can more or less pick 2 of 3. At
the moment I'm running in daemon mode with splay = false, so I'm not
terribly worried about concurrency (as a matter of fact, my test
environment has 25 nodes and 21 of them appear to be running within the
same minute); my end goal is to have all my nodes running every 30
minutes and be as evenly dispersed as practical within that timeframe.

For the time being, as I have some more pressing issues, I'm going to
give up on the "evenly dispersed" part, and opt to use runall with a
concurrency of 10, and revisit this when my infrastructure grows to the
point that it becomes a problem (or when I finally pull the ticket to
fix this). I just did a "mco puppet runall 10" in my 25-node test
environment, and the mco command completed in 57 seconds. The puppet
master looked perfectly happy with that.

Thanks for all of the advice.

-Jason

On 12/31/2013 11:58 AM, R.I.Pienaar wrote:
>
> - Original Message -
>> From: "Jose Luis Ledesma" 
>> To: puppet-users@googlegroups.com
>> Sent: Tuesday, December 31, 2013 4:51:04 PM
>> Subject: Re: [Puppet Users] MCollective/Puppet - one-time run with other 
>> options
>>
>> The problem about using runall/concurrency is that you cannot know when it
>> will finish, so setting it on the crontab could be a source of a problems if
>> it has not yet finished when the next run is schedulee
> You could just use a lock file and not run then.  Or wait or whatever.  
>
> There are 3 variables:
>
>  - how many nodes are running
>  - how often they run
>  - how long to sleep between them
>
> you cannot optimise all 3 these variables, the old puppetcommander would skip
> nodes that it cannot run in the time so it would always finish in the 
> allocated
> time.  This had the draw back that if you miss-specify your max run time or 
> just
> can't be bothered to monitor it over time as you added nodes you can end up 
> with
> nodes that just never run.
>
> the new runall algorithm will run all nodes as quick as it can, but cannot 
> guarantee
> it will finish within your half an hour.  This is the better algo since all 
> your nodes
> will run and your master will not be DOS'd. But the important thing is that 
> all nodes
> do get a run.
>
> So now you have to just decide what is important for you.  If you would like 
> to know
> when your concurrency and run times are such that it can't finish in 30 
> minutes given
> your master resources just make your cronjob write a lock file and notify 
> when the
> next one finds a lock - you should then look why, maybe your manifests have 
> gotten
> so slow that it cant possibly finish anymore.
>
> Or just run the thing in a loop forever let it make best efforts without 
> killing your
> master - in this case a simple daemon will work.
>
>
>> --
>> 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/cff5bbd6-c856-44c7-836c-9e98355eb2c7%40googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>

-- 
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/52C30F4F.7010300%40jasonantman.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] MCollective/Puppet - one-time run with other options

[Jason Antman]

Christian - we don't use puppet just to "make changes", we use it as
(IMO) it was intended - to prevent divergence. We want it running every
30 minutes to make sure things stay how the manifests/modules say.

Jose - I think that may be the way I go, but I'm going to see if I can
get something (perhaps RIP's puppetcommander, or something like it) to
evenly balance the nodes.

Thanks,
Jason

On 12/31/2013 09:32 AM, Cristian Falcas wrote:
> Hi,
>
> At my work place we have puppet stopped completely. We only run it via
> mco when we update the manifests. But this implies that you don't use
> exported resources.
>
> regards,
> Cristian Falcas
>
> On Tue, Dec 31, 2013 at 3:32 PM, Jose Luis Ledesma
>  wrote:
>> Hello,
>>
>>We have puppet only in the lab's servers, we are planning to deploy to
>> production in the near future. I found myself thinking about the same
>> question some time ago.
>>
>>What we were thinking is, why to run puppet agent on every node? In fact
>> puppetlabs says about setting the puppet agent in the crontab... What we
>> have done in the laboratory is to disable puppet agent, and run it always
>> from the puppetmaster/mco-client crontab  in the next way:
>>
>> 0 * * * * /usr/bin/mco puppet runonce --noop --splaylimit 900
>>
>>
>>     I don't know if it's the best solution for productive-environment,
>> opinions?
>>
>> regards,
>>
>>
>> El martes, 31 de diciembre de 2013 13:50:11 UTC+1, Jason Antman escribió:
>>> I also forgot the scariest option, which seems apt to break things:
>>> - have mcollective stop the daemon
>>> - mco puppet runonce
>>> - have mcollective start the daemon back up
>>>
>>> -jason
>>>
>>> On 12/31/2013 07:42 AM, Jason Antman wrote:
>>>> Hello,
>>>>
>>>> I've recently learned that my plans to use the puppet agent mcollective
>>>> plugin to trigger one-time runs against a different environment, with
>>>> the daemon running in the background, don't work because of how the
>>>> agent plugin works (SIGUSR1 to the daemon if running).
>>>>
>>>> My original intent was as follows:
>>>> I have a bunch of puppet nodes dedicated to testing new
>>>> manifests/modules. Normally they, like all of my other nodes, run in
>>>> daemon mode against the production environment. I have a Jenkins job
>>>> that does some static testing of a specific branch of our puppet repo,
>>>> and then checks out that branch as an environment on the master and
>>>> (should/tries to) run `mco puppet runonce --environment `.
>>>>
>>>> So, while I think the "runonce" name is pretty misleading if it can't
>>>> handle running when there's a daemon, I understand the limitations
>>>> behind it. Now I'm looking for any suggestions on how to achieve what
>>>> I'm trying to. I've been able to come up with a few options... if anyone
>>>> has other suggestions, or opinions, please pass them along...
>>>>
>>>> 1) https://tickets.puppetlabs.com/browse/PUP-1319 (formerly redmine
>>>> 5153) "Ability to run --onetime in the background while a daemon is
>>>> idle" implies that running "--onetime --no-deamonize --foreground" works
>>>> fine while there's a backgrounded daemon. So all that would be needed is
>>>> a change to the mco puppet plugin to explicitly add an option to allow
>>>> this? I manually run "puppet agent -t --environment foo" all the time
>>>> while the daemon is running, and it works fine.
>>>>
>>>> 2) As suggested by chris spence, I could stop using daemon mode and
>>>> start using cron to trigger periodic runs. I've been running in daemon
>>>> mode for a lng time, but I guess with the deprecation of `puppet
>>>> kick`, it's no longer needed. The remaining issue is how to spread out
>>>> runs of all my nodes to minimize load on the master, and how to run at
>>>> boot, which are solvable problems though more complex than "service
>>>> puppet enable true". Any suggestions for how to spread out the runs? I'm
>>>> using a custom ENC, so I suppose I could do it there as a param for
>>>> cron, but I'm open to nicer solutions.
>>>>
>>>> 3) Going by R. I.'s blog post from 2010 (yeah a bit dated)
>>>>
>>>> http://www.devc

Re: [Puppet Users] MCollective/Puppet - one-time run with other options

[Jason Antman]

I also forgot the scariest option, which seems apt to break things:
- have mcollective stop the daemon
- mco puppet runonce
- have mcollective start the daemon back up

-jason

On 12/31/2013 07:42 AM, Jason Antman wrote:
> Hello,
>
> I've recently learned that my plans to use the puppet agent mcollective
> plugin to trigger one-time runs against a different environment, with
> the daemon running in the background, don't work because of how the
> agent plugin works (SIGUSR1 to the daemon if running).
>
> My original intent was as follows:
> I have a bunch of puppet nodes dedicated to testing new
> manifests/modules. Normally they, like all of my other nodes, run in
> daemon mode against the production environment. I have a Jenkins job
> that does some static testing of a specific branch of our puppet repo,
> and then checks out that branch as an environment on the master and
> (should/tries to) run `mco puppet runonce --environment `.
>
> So, while I think the "runonce" name is pretty misleading if it can't
> handle running when there's a daemon, I understand the limitations
> behind it. Now I'm looking for any suggestions on how to achieve what
> I'm trying to. I've been able to come up with a few options... if anyone
> has other suggestions, or opinions, please pass them along...
>
> 1) https://tickets.puppetlabs.com/browse/PUP-1319 (formerly redmine
> 5153) "Ability to run --onetime in the background while a daemon is
> idle" implies that running "--onetime --no-deamonize --foreground" works
> fine while there's a backgrounded daemon. So all that would be needed is
> a change to the mco puppet plugin to explicitly add an option to allow
> this? I manually run "puppet agent -t --environment foo" all the time
> while the daemon is running, and it works fine.
>
> 2) As suggested by chris spence, I could stop using daemon mode and
> start using cron to trigger periodic runs. I've been running in daemon
> mode for a lng time, but I guess with the deprecation of `puppet
> kick`, it's no longer needed. The remaining issue is how to spread out
> runs of all my nodes to minimize load on the master, and how to run at
> boot, which are solvable problems though more complex than "service
> puppet enable true". Any suggestions for how to spread out the runs? I'm
> using a custom ENC, so I suppose I could do it there as a param for
> cron, but I'm open to nicer solutions.
>
> 3) Going by R. I.'s blog post from 2010 (yeah a bit dated)
> http://www.devco.net/archives/2010/03/17/scheduling_puppet_with_mcollective.php
> about puppetcommander.rb, I could use something mco-based to schedule
> the runs. Though AFAIK this means running *that* controller either via
> cron on the master, or as a daemon somewhere (I assume the former would
> be preferable and easier).
>
> Any thoughts/suggestions?
>
> My main concerns are:
> 1) running 300+ nodes every 30 minutes, with load on the master
> distributed as evenly as possible.
> 2) Jenkins being able to force a given node or list of nodes to run
> immediately against an arbitrary environment.
>
> Thanks for any suggestions/feedback,
> J Antman
>

-- 
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/52C2BD83.2050805%40jasonantman.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] MCollective/Puppet - one-time run with other options

[Jason Antman]

Hello,

I've recently learned that my plans to use the puppet agent mcollective
plugin to trigger one-time runs against a different environment, with
the daemon running in the background, don't work because of how the
agent plugin works (SIGUSR1 to the daemon if running).

My original intent was as follows:
I have a bunch of puppet nodes dedicated to testing new
manifests/modules. Normally they, like all of my other nodes, run in
daemon mode against the production environment. I have a Jenkins job
that does some static testing of a specific branch of our puppet repo,
and then checks out that branch as an environment on the master and
(should/tries to) run `mco puppet runonce --environment `.

So, while I think the "runonce" name is pretty misleading if it can't
handle running when there's a daemon, I understand the limitations
behind it. Now I'm looking for any suggestions on how to achieve what
I'm trying to. I've been able to come up with a few options... if anyone
has other suggestions, or opinions, please pass them along...

1) https://tickets.puppetlabs.com/browse/PUP-1319 (formerly redmine
5153) "Ability to run --onetime in the background while a daemon is
idle" implies that running "--onetime --no-deamonize --foreground" works
fine while there's a backgrounded daemon. So all that would be needed is
a change to the mco puppet plugin to explicitly add an option to allow
this? I manually run "puppet agent -t --environment foo" all the time
while the daemon is running, and it works fine.

2) As suggested by chris spence, I could stop using daemon mode and
start using cron to trigger periodic runs. I've been running in daemon
mode for a lng time, but I guess with the deprecation of `puppet
kick`, it's no longer needed. The remaining issue is how to spread out
runs of all my nodes to minimize load on the master, and how to run at
boot, which are solvable problems though more complex than "service
puppet enable true". Any suggestions for how to spread out the runs? I'm
using a custom ENC, so I suppose I could do it there as a param for
cron, but I'm open to nicer solutions.

3) Going by R. I.'s blog post from 2010 (yeah a bit dated)
http://www.devco.net/archives/2010/03/17/scheduling_puppet_with_mcollective.php
about puppetcommander.rb, I could use something mco-based to schedule
the runs. Though AFAIK this means running *that* controller either via
cron on the master, or as a daemon somewhere (I assume the former would
be preferable and easier).

Any thoughts/suggestions?

My main concerns are:
1) running 300+ nodes every 30 minutes, with load on the master
distributed as evenly as possible.
2) Jenkins being able to force a given node or list of nodes to run
immediately against an arbitrary environment.

Thanks for any suggestions/feedback,
J Antman

-- 
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/52C2BBC0.1050804%40jasonantman.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] external node classifier with a back-end

[Jason Antman]

Stuart,

I know this took a while, but there were some bureaucratic hoops to be
jumped through first.

Our Python/Django (Postgres-backed) ENC, or what exists of it so far, is
now at https://github.com/coxmediagroup/nodemeister

Be advised this is horribly Alpha, doesn't really have any tests yet,
and relies on an internal python module. In other words, for the time
being, it's really there as code to look at only, I wouldn't expect you
to get it installed and running without some serious Python knowledge.

-Jason

On 12/06/2013 12:59 PM, Stuart Cracraft wrote:
> HI Jason,
>
> No I have no hesitations at all and yes, I would enjoy seeing your
> Postgres code
> and learning from it and can share back.
>
> So the thought here is to have all the configuration data, client
> data, node data, in
> a Postgres database (the one on the Puppet Master) and used downline
> by all the various
> Linux apps which need it, including Puppet.
>
> I take it (hopefully) this is not too unusual and bizarre in the world
> of Puppet.
>
>
> On Thursday, December 5, 2013 4:16:10 AM UTC-8, Jason Antman wrote:
>
> PuppetDB isn't an ENC. PuppetDB does, however, use Postgres
> (unless you use the embedded database, which you shouldn't).
> Puppet Dashboard is an ENC, but ironically, uses MySQL not Postgres.
>
> Stuart,
>
> Starting *another* ENC thread a day later isn't likely to get you
> many more responses than the two to your last question. I assumed,
> given your lack of response to my reply, that you're not terribly
> interested in sharing what you need an ENC to do... As I
> mentioned, I'm working on getting a Python/Django
> (Postgres-backed) ENC ready for release... if you want to see the
> current code, that could be arranged, though it's not really up to
> the "just run this puppet module and it installs the ENC" stage yet.
>
> -jantman
>
> On 12/04/2013 05:10 PM, Stuart Cracraft wrote:
>> Hi Ygor/Dan,
>>
>> Postgres has better DR.
>>
>> We like Postgres.
>>
>> Stuart
>>
>> On Wednesday, December 4, 2013 2:03:10 PM UTC-8, Ygor wrote:
>>
>> Isn't that what PuppetDB is ?
>>
>> �Sometimes I think the surest sign that intelligent life
>> exists elsewhere in the universe is that none of it has tried
>> to contact us.�
>> Bill Waterson (Calvin & Hobbes)
>>
>> 
>> 
>> *From: *"Stuart Cracraft" 
>> *To: *puppet...@googlegroups.com
>> *Sent: *Wednesday, December 4, 2013 4:33:51 PM
>> *Subject: *[Puppet Users] external node classifier with a
>> back-end
>>
>>
>> Hi everybody!
>>
>> Anyone have a back-ended external node classifier to a
>> Postgres database
>> they could throw my way?
>>
>> Stuart
>>
>>
>> -- 
>> 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/7781bed3-7e5a-46e2-8949-e00bfac0fbd0%40googlegroups.com
>> 
>> <https://groups.google.com/d/msgid/puppet-users/7781bed3-7e5a-46e2-8949-e00bfac0fbd0%40googlegroups.com>.
>> For more options, visit
>> https://groups.google.com/groups/opt_out
>> <https://groups.google.com/groups/opt_out>.
>>
>> -- 
>> 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/c642f1be-1121-4ab9-b56a-29b54809140f%40googlegroups.com
>> 
>> <https://groups.google.com/d/msgid/puppet-users/c642f1be-1121-4ab9-b56a-29b54809140f%40googlegroups.com>.
>> For more options, visit https://groups.google.com/groups/opt_out
>> <https://groups.google.com/groups/opt_out>.
>
> -- 
> You received this message because you are subscribed to the Google
> Groups "Puppet Users" group.
> To u

Re: [Puppet Users] ruby visual debuggers/ide's for Linux

[Jason Antman]

Since you're asking about a Ruby IDE, not a Puppet IDE, perhaps this 
question would be better asked of a Ruby list, or even better, a search 
engine...


On 12/24/2013 06:21 PM, Stuart Cracraft wrote:

Hi,

Is there a plain-text visual debugger ide for Linux for Ruby anyone 
can mention?


Stuart

--
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/b15a63ee-164e-4bb6-bbe4-829c67a91655%40googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.


--
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/52BB0AC6.2010802%40jasonantman.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] One big manifest?

[Jason Antman]

Peter,

I looked at puphpet a bit, and had it generate a sample config for me. The 
puppet manifests that it outputs are VERY far from anything that could be 
called "best practices". The 'all one .pp file' paradigm leads me to believe 
they're not even intended to be read or modified by a human, but just used 
withun the puphpet ecosystem.

The good news is that most of the modules that puphpet uses are widely used 
forge modules. They have many many more options and functionality than puphpet 
exposes.

My advice would be that if you've outgrown what puphpet does, you throw out the 
manifests that it generates (though you can certainly use the same forge/github 
modules that it uses) and write new manifests in whatever way makes sense to 
you. Or, use that one giant manifest as a starting point, and break it up into 
your own manifests and/or modules however makes the most sense 
(docs.puppetlabs.com has a gresat reference and some good tutorials.

You can probably even keep the rest of the output of puphpet if you need the 
vagrant configs, etc but just replace or heavily edit the puppet directory.

PS - if you're managing a "growing number of servers", you should probably look 
into either running an actual puppeg master, or at least keeping all your 
puppet stuff in version control (git seems to be the most popular in the puppet 
world by far).

Hope that helps,
jantman


Sent from my Verizon Wireless 4G LTE smartphone

 Original message 
From: Peter Nijssen  
Date: 2013/12/21  08:00  (GMT-05:00) 
To: puppet-users@googlegroups.com 
Subject: Re: [Puppet Users] One big manifest? 
 
Thanks for your answer.
I've only been a week now in the world of puppet. I started to use it, because 
I am charmed with the puppet + vagrant combination as a developer. Also, we 
currently are managing a growing number of servers by hand and I believe puppet 
can be a nice answer to keep everything consistent and up 2 date.

I've used the puphpet gui interface which works quiet nice. In the end, it 
offers me too less functionality and I want to stay more in control. So I 
started to explore puppet a bit more. I wrote my own basic modules, based on 
this box I found:
https://github.com/bryannielsen/Laravel4-Vagrant
I believe it's a nice example of how you can easily write your own modules.

However, I have also been using the default modules through puppet forge.  In 
the end, it makes it easier for you since almost everything can be done through 
it and is probably done in the best possible way. However, I noticed then that 
configuring those default modules happens in the general site.pp manifest, 
which can become quiet lenghty. That doesn't feel like a best practice either.

So, at one hand I could write my own custom modules which exactly do what I 
want and it is configured within those modules, or I could use the default 
modules from the puppet forge and do the whole configuration within the site.pp.
That's my currently my view, but maybe I am missing something or I should 
something different.

I'll see if I can dive further into some puppet books and guides :)

Op vrijdag 20 december 2013 23:09:47 UTC+1 schreef Johan De Wit:
This is just a question with so many answers.

have you tried the puppet enterprise quick start guide ?

It is a good way to learn the concepts and get you started quickly.

Get in touch with local puppet users.  Looks to me you are dutch   
speaking, so get in touch with the dutch or belgian puppet user group.   

https://puppetlabs.com/community/PUG for the list.

Just start writing a simple module, learn 'puppet apply' for test/execute your 
module.

grts

jo












On 12/20/2013 07:15 PM, Peter Nijssen wrote:
I read that document, however, it doesn't provide me the answer.

Should I write, in general, my own modules? Or should I use predefined modules?
And I if use predefined modules, should the configuration of those modules 
happen all in site.pp? (Which sounds me like a big file which is getting harder 
to read the more you need to configure). In the modules itself? Or do you have 
to write modules which will start those modules?

Op vrijdag 20 december 2013 19:04:33 UTC+1 schreef Christopher Wood:  
Looks like you might want to start here: 

http://docs.puppetlabs.com/puppet/latest/reference/modules_fundamentals.html 

Also check up on how to do hiera lookups from within puppet3. 

Other than that, structuring your modules tends to be a bit site-dependent. 

On Fri, Dec 20, 2013 at 08:38:03AM -0800, Peter Nijssen wrote: 
>    Hi, 
>    I started to use vagrant with [1]puphpet. Very nice. However, the gui of 
>    puphpet gives me too few options, so I want to configure everything 
>    myself. 
>    So, I decided to write everything from scratch, using modules. Modules 
>    like apache, mysql, php, phpmyadmin which are in the puppet forge etc etc. 
>    Now I need to configure those parts like which mods enabled for apache. 
>    Which vhost files. etc

Re: [Puppet Users] Re: Failed to submit 'replace facts'

[Jason Antman]

Harshita,

That error message sounds like your certificate problem is with
PuppetDB, not the agent to the master.

the master is learn.localdomain.pem and the windows agent is the one
with the utterly useless hostname (igtggn*)?

Every node (master and agent alike) will always generate their own
certificate when they start, if it isn't there yet. The fact that ca.pem
is on the agent looks promising. But until you see the igtggn* cert show
up on the *master* it doesn't mean they've authenticated.

Is there any way to view the logs/output of the agent on windows? If
this were a unix agent, I'd run it with --debug to figure out what's
happening. If you're able to do that, posting the log output would give
us a little more information to help you...

-jantman

On 12/20/2013 06:56 AM, Harshita Sinha wrote:
> Hi All,
> I again attempted to execute the command puppet agent --test --verbose
> --server learn.localdomain,and I continue to get the same error :(
>
> Surprisingly, I found that the certificates are created both in
> Windows agent and the Master . 
> The files created in master under the
> folder /etc/puppetlabs/puppet/ssl/certs are  (1) ca.pem and
>  (2) learn.localdomain.pem
> The files created in Windows agent under the folder
> path C:\ProgramData\PuppetLabs\puppet\etc\ssl\certs are (1) ca.pem and
> (2) igtggn11002.interglobetechnologies.com.pem
>
> I assume they are certificates that are created after Master and agent
> have had a hand shake .
>
> Can you please guide me, what is the next step I should do to resolve
> the replace facts ? What should I do ?
>
> Thanks,
> Harshita
>
>
> Thanks and Regards,
> Harshita
> +91-9711099504
>
>
> On Fri, Dec 20, 2013 at 3:16 PM, Harshita Sinha  > wrote:
>
> Hi All,
> Following the instructions
> on 
> http://www.copperykeenclaws.com/setting-up-puppet-on-windows/#comment-1201 I
> was able to connect Windows Agent to Puppet Master.
>
> Since my VM got disconnected, I thought of again connecting again
> and  I cleared all the certificates from Windows-Agent as well as
> Unix-Master.
> I cleared ca.pem file from the Agent, and ca.pem
> and learn.localdomain.pem from the master.
>
> After deleting all the certificates, I attempted to execute the
> command
> puppet agent --test --verbose --server learn.localdomain .
>
> I got response as 
> *Info: Caching certificate for ca*
> *Info: Caching certificate for
> igtggn11002.interglobetechnologies.com
> *
> *Info: Retrieving plugin*
> *Info: Loading facts in
> C:/ProgramData/PuppetLabs/puppet/var/lib/facter/concat_ba**sedir.rb*
> *Info: Loading facts in
> C:/ProgramData/PuppetLabs/puppet/var/lib/facter/custom_au**th_conf.rb*
> *Info: Loading facts in
> C:/ProgramData/PuppetLabs/puppet/var/lib/facter/facter_do**t_d.rb*
> *Info: Loading facts in
> C:/ProgramData/PuppetLabs/puppet/var/lib/facter/ip6tables**_version.rb*
> *Info: Loading facts in
> 
> C:/ProgramData/PuppetLabs/puppet/var/lib/facter/iptables_**persistent_version.rb*
> *Info: Loading facts in
> C:/ProgramData/PuppetLabs/puppet/var/lib/facter/iptables_**version.rb*
> *Info: Loading facts in
> C:/ProgramData/PuppetLabs/puppet/var/lib/facter/pe_versio**n.rb*
> *Info: Loading facts in
> 
> C:/ProgramData/PuppetLabs/puppet/var/lib/facter/postgres_**default_version.rb*
> *Info: Loading facts in
> 
> C:/ProgramData/PuppetLabs/puppet/var/lib/facter/puppetdb_**server_status.rb*
> *Info: Loading facts in
> C:/ProgramData/PuppetLabs/puppet/var/lib/facter/puppet_va**rdir.rb*
> *Info: Loading facts in
> C:/ProgramData/PuppetLabs/puppet/var/lib/facter/root_home**.rb*
> *Info: Loading facts in
> C:/ProgramData/PuppetLabs/puppet/var/lib/facter/windows.r**b*
> Error: Could not retrieve catalog from remote server: Error 400 on
> SERVER: Faile*
> d to submit 'replace facts' command for
> igtggn11002.interglobetechnologies.com
>  t
> **
> o PuppetDB at learn.localdomain:8081: SSL_connect SYSCALL
> returned=5 errno=0 sta
> *
> te=SSLv3 read finished A
> Warning: Not using cache on failed catalog
> Error: Could not retrieve catalog; skipping run
>
> Why is it not attempting to create the new certificate ? Why is it
> caching for ca, when I already deleted ca.pem ?
>
> RESTART PUPPET AGENT
> I refered the
> link 
> https://ask.puppetlabs.com/question/3853/error-400-on-server-failed-to-submit-replace-facts-command-connection-refused/
>  and
> tried to restart my agent but I get an error as
> *C:\Program Files (x86)\Puppet Labs\Puppet Enterprise\bin>service
> pe-puppet resta**rt*
> *'service' is not recognized as an internal or external command,*
> *operable program or batch file.*
> *
> *
>
>
> Thank

Re: [Puppet Users] Package management

[Jason Antman]

Michael,


Yes, package resources (like all resources) need to be checked before 
puppet can do anything with them. I'm not quite sure what you mean by 
"use yaml with a single command" - puppet Package resources must be 
specified with one single package name, there's no way around this that 
I'm aware of. I think you may be misunderstanding something.


What distribution/OS are you on? What provider is being used for these 
packages? Can you provide the output of a --verbose or --debug run?


The real issue here, AFAIK, is that whatever package provider you're 
using doesn't seem to be prefetching the resources, which leads to this 
amazingly long query time. Also, taking a full 2 seconds for a package 
check sounds really wrong - once again, something that seems to point to 
prefetch not working (of course there are some cases where it's 
impossible, but those are generally edge cases AFAIK).


-jantman


On 12/18/2013 11:03 PM, Michael Bauer wrote:


Hi,

I want to manage about 200 packages with Puppet and I want a separate 
"package"-resource for each package. The problem is: Every time, the 
Puppet-Agent does a "run" / "apply", he checks every 200 packages. 
Each package-check needs about 2 seconds. Altogether it takes about 
400 seconds, which is to much. I want the check to only few seconds. I 
heard that it would be possible if I use yaml with using a single 
command which contains all the desired packages. But I don't know how 
to do it.


Hopefully someone can help.

Thanks

--
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/108cb765-add9-4f0b-ad2e-fa521836ec8b%40googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.


--
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/52B2E585.8060800%40jasonantman.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] get a *structured* version of the puppet agent output

[Jason Antman]

Stuart,

You have *very* specific requirements here. In these situations, there
are generally three options:
1) find someone else who's done it and use theirs
2) learn how to do it yourself
3) pay someone else to do it
4) don't do it

You posted your question (which I assume you researched before posting,
and did not find an appropriate solution) and nobody has yet stepped
forward to say "I have that," though you have been given many examples,
some very detailed, and haven't given back any indication that you tried
them. If the prices that PL charges for consulting are too expensive,
and the same is true for hiring some random ruby coder, I think either
you (or someone at your company) need to learn ruby, or reassess how you
are using Puppet and your requirements. From your many previous posts,
it seems like you're asking things of puppet that are relatively uncommon.

There have been some very good responses in this thread, including the
(IMO) best, which is to use PuppetDB and its API, in which case you also
wouldn't be restricted to Ruby. What have you tried so far? What issues
do you have with the various options?

This list has over 6,600 members, and you alone are responsible for a
whopping 10% (yes, one in ten) of the posts in the last month. If you
feel that the responses you receive are not adequate, perhaps you should
be more judicious in how quickly you appeal to the community for an
answer, how much detail you give (specifically "I tried this  and seem to be experiencing this "),
and give a better indication that you've actually tried the suggested
solutions, and what the results were.

On 12/18/2013 02:46 PM, Stuart Cracraft wrote:
> It's too expensive given our small company.
>
> On Wednesday, December 18, 2013 11:25:31 AM UTC-8, Ygor wrote:
>
> Try this link:
>
> http://puppetlabs.com/services/consulting
> 
>
> “Sometimes I think the surest sign that intelligent life exists
> elsewhere in the universe is that none of it has tried to contact us.”
> Bill Waterson (Calvin & Hobbes)
>
> 
> *From: *"Stuart Cracraft" >
> *To: *puppet...@googlegroups.com 
> *Sent: *Wednesday, December 18, 2013 1:01:42 PM
> *Subject: *Re: [Puppet Users] get a *structured* version of the
> puppet agent output
>
>
> thanks.
>
> who is your contact?
>
> I am not getting the help I need.
>
> > On Dec 18, 2013, at 10:00 AM, Jason Slagle  > wrote:
> >
> > Hi Stuart,
> >
> > Puppet Labs has a large professional service department that you
> might want to engage with these very specific requests.  I'm sure
> they can give you a hand with whatever you need done.
> >
> > Jason
> >
> >> On 12/18/2013 12:55 PM, Stuart Cracraft wrote:
> >> What we are looking for is a Ruby program which takes the
> contents of
> >>
> >>   /var/lib/puppet/reports/*/*.yaml
> >>
> >> and reports in detail on everything changed or proposed for
> change if in
> >> noop mode
> >> (file permissions, modes, user creates, etc.)
> >>
> >> Stuart
> >
> > --
> > 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/cHpZlKkPmr4/unsubscribe
> .
> > To unsubscribe from this group and all its topics, send an email
> to puppet-users...@googlegroups.com .
> > To view this discussion on the web visit
> 
> https://groups.google.com/d/msgid/puppet-users/52B1E2AB.7060909%40tacorp.net
> 
> .
> > For more options, visit https://groups.google.com/groups/opt_out
> .
>
> -- 
> 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/36C6B660-92B8-4056-B82D-789C1B0AE7ED%40me.com
> 
> .
> For more options, visit https://groups.google.com/groups/opt_out
> .
>
> -- 
> 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/65902161-3831-4b46-8

Re: [Puppet Users] Puppet Labs issue tracker migration 16 Dec 2013

[Jason Antman]

I've gone through and migrated most of the issues I was watching (and 
still care about) that weren't already.


I ran into 4 issues that show up with a message of:

"This issue is currently not available for export. If you are 
experiencing the issue described below, please file a new ticket in 
JIRA. Once a new ticket has been created, please add a link to it that 
points back to this Redmine ticket."


Should I do so, or is there a better way of handling this?

The issues in question are 4240, 13602, 17439 and 22902.

Thanks,
j antman

On 12/10/2013 01:51 PM, Eric Sorenson wrote:
Hi, as I mailed about a little while ago[1], we're migrating issue 
tracking for Puppet Labs projects from Redmine to JIRA.


After working through the tooling and integration concerns, we're 
going to make the switch on 16th of December.


More info on how this will work:

* Everybody needs to create a new account on JIRA, since we can’t 
migrate passwords from redmine to jira.
* If you were watching redmine bugs to track their progress, you will 
be notified via email with the new location of the bug in JIRA. You'll 
need to set yourself up to watch the bug in JIRA with your 
newly-created account.
* Some older issues that we think are obsolete will not be migrated, 
but if we made a mistake and forgot to include your favorite bug, 
there will be a link on each Redmine issue where you can migrate it 
with a single click.
* The Redmine instance will remain up and read-only, because there's a 
ton of back history, outgoing links, google indexing, etc that is 
quite valuable to keep.
* Projects that use github issues will also migrate, but pull request 
workflow remains as-is.


Please let me know if you have any additional questions.

[1] https://groups.google.com/d/topic/puppet-users/4lV1cT6Li-M/discussion



--
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/52AF5676.7060401%40jasonantman.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] Puppet and MCollective

[Jason Antman]

It's great that you're using Puppet and MCollective and trying to get 
them setup everywhere, and there are some really easy ways to do that 
when provisioning a new VM - either through templates or the build 
process. Personally, I have Puppet baked in to our base installs (we 
actually don't use templates, we kickstart each machine via Cobbler) and 
use Puppet to install MCollective.


If you're wondering about *existing* VMs that for some reason you can't 
just rebuild... what about a good, old-fashioned ssh-in-a-for-loop?


-jantman

On 12/12/2013 11:54 AM, ro001 wrote:



Hi,

I am writing scripts for deployment of our software and I am also 
using MCollective on linux.


I hope to use MCollective in order to reduce the requirement of 
opening a putty session to each VM and running the puppet agent 
manually the first time (when its registers/ creates keys etc). The 
problem I see with this is that I need to log in to each machine and 
install/configure mcollective (server.cfg & client.cfg), so for this 
reason I do not save myself very much effort by using mcollective.


I am using vms so I can add mcollective to the vm template, but I wont 
know the name of mcollective/activemq machine nor would I know the 
name of the machine at that point.


How do you guys deploy mcollective?  It seems abit like a chicken/egg 
scenario!




--
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/d1e0fc41-6558-4abf-bcc3-1a19e418d6f5%40googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.


--
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/52AAF890.7010706%40jasonantman.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] external node classifier with a back-end

[Jason Antman]

So you're looking to put Puppet data and "other data" for other
applications in ONE database? That doesn't sound terribly safe...

How is this data getting into the database? What types of functionality
do you need? Just something like Dashboard with nodes and groups that
can have params and classes? Inheritance? Exclusions?

If all you want is a database that stores classes/params for nodes, and
uses them on a 1:1 basis, this is a trivial problem and is really just
an issue of writing a tool to get data into the database. The "hard"
part of an ENC is handling things like groups, multiple inheritance,
overrides, exclusions, etc.

I'm still not clear on the functionality and interface that you want for
this, and I'm also unclear on the distinction between what you call
"configuration data", "client data" and "node data".

-Jason

On 12/06/2013 12:59 PM, Stuart Cracraft wrote:
> HI Jason,
>
> No I have no hesitations at all and yes, I would enjoy seeing your
> Postgres code
> and learning from it and can share back.
>
> So the thought here is to have all the configuration data, client
> data, node data, in
> a Postgres database (the one on the Puppet Master) and used downline
> by all the various
> Linux apps which need it, including Puppet.
>
> I take it (hopefully) this is not too unusual and bizarre in the world
> of Puppet.
>
>
> On Thursday, December 5, 2013 4:16:10 AM UTC-8, Jason Antman wrote:
>
> PuppetDB isn't an ENC. PuppetDB does, however, use Postgres
> (unless you use the embedded database, which you shouldn't).
> Puppet Dashboard is an ENC, but ironically, uses MySQL not Postgres.
>
> Stuart,
>
> Starting *another* ENC thread a day later isn't likely to get you
> many more responses than the two to your last question. I assumed,
> given your lack of response to my reply, that you're not terribly
> interested in sharing what you need an ENC to do... As I
> mentioned, I'm working on getting a Python/Django
> (Postgres-backed) ENC ready for release... if you want to see the
> current code, that could be arranged, though it's not really up to
> the "just run this puppet module and it installs the ENC" stage yet.
>
> -jantman
>
> On 12/04/2013 05:10 PM, Stuart Cracraft wrote:
>> Hi Ygor/Dan,
>>
>> Postgres has better DR.
>>
>> We like Postgres.
>>
>> Stuart
>>
>> On Wednesday, December 4, 2013 2:03:10 PM UTC-8, Ygor wrote:
>>
>> Isn't that what PuppetDB is ?
>>
>> �Sometimes I think the surest sign that intelligent life
>> exists elsewhere in the universe is that none of it has tried
>> to contact us.�
>> Bill Waterson (Calvin & Hobbes)
>>
>> 
>> 
>> *From: *"Stuart Cracraft" 
>> *To: *puppet...@googlegroups.com
>> *Sent: *Wednesday, December 4, 2013 4:33:51 PM
>> *Subject: *[Puppet Users] external node classifier with a
>> back-end
>>
>>
>> Hi everybody!
>>
>> Anyone have a back-ended external node classifier to a
>> Postgres database
>> they could throw my way?
>>
>> Stuart
>>
>>
>> -- 
>> 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/7781bed3-7e5a-46e2-8949-e00bfac0fbd0%40googlegroups.com
>> 
>> <https://groups.google.com/d/msgid/puppet-users/7781bed3-7e5a-46e2-8949-e00bfac0fbd0%40googlegroups.com>.
>> For more options, visit
>> https://groups.google.com/groups/opt_out
>> <https://groups.google.com/groups/opt_out>.
>>
>> -- 
>> 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/c642f1be-1121-4ab9-b56a-29b54809140f%40googlegroups.com
>> 
>> <https://groups

Re: [Puppet Users] testing and exported (nagios) resources

[Jason Antman]

On 12/04/2013 08:22 AM, Felix Frank wrote:

Hi,

I must be missing an essential piece here.

All three of your puppet stack nodes must be present in each instance,
no? The production master manages all three masters, normally. To change
monitoring of either of them, you update the production manifests.
What do you mean by "present in each instance"? Each stack is 
self-contained - it has its own ENC, PuppetDB, and Master. Each stack's 
master manages itself and its stack, out of a "production" environment 
(git master). The logic behind this is that if the production stack 
suffers an outage (i.e. hardware failure) the ENC data is imported to 
the test stack, and nodes are seamlessly moved over. Yes, I'm aware of 
the tradeoff that certain things aren't constrained by environment, and 
bad code in one environment on the dev or test masters could bring down 
that stack.


I'm not just worried about monitoring the puppet stack itself, I'm also 
worried about monitoring the nodes. I.e. the dev stack has a bunch of 
VMs that exist to test code, and they need to be monitored in Nagios.


Of course, if you implement some new monitoring feature on the dev
master, you must have that node run puppet against its local dev master
to export resources, then the nagios server also against the dev master
to import them. But that is just the usual dev workflow, I assume.
Yeah, that's understood. But what about the production monitoring? I'd 
need to run all of the nodes in the environment against the production 
master to actually export the nagios configs to the nagios server... or 
else I'd need (what I'm asking about) some way of exporting the Nagios 
configs from the dev and test masters to the Nagios server, but only for 
one environment (broken in puppet... exported resources don't work this 
way) or only when manually requested...


So I suspect things aren't so simple for you. I just don't see in what
manner.

Thanks in advance for any clarification,
Felix

On 12/03/2013 02:39 AM, Jason Antman wrote:

Hello,

I have 3 puppet stacks (master, puppetdb, enc) - dev, test/qa and prod.
Dev is used for initial development and testing of code (including
puppet), which is then promoted to test and then prod.

I'd like to start using the nagios types to configure monitoring, via
exported resources (yes I'm aware of the issues with the builtins, but
they'll have to do for now). I only have one Nagios server, and I'd like
to reliably monitor at least some stuff on the dev and test puppet
nodes. So... setting up all 3 puppet stacks to export resources that are
realized somehow on the Nagios server isn't a possibility, as bad
manifests/modules could affect the monitoring of one of the dev or test
hosts.

What's the safe way to "freeze" exported resources, or prevent them from
being changed? The best that I can come up with so far is to have the
nagios server connected to the production puppetmaster, and when I want
to update the (exported resource) monitoring configuration for one of
the dev or test nodes, have to do a one-time run on each node in
question against the prod puppet master.

Any other thoughts or theories?

Thanks,
Jason Antman


--
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/52A0A207.8080406%40jasonantman.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] external node classifier with a back-end

[Jason Antman]

PuppetDB isn't an ENC. PuppetDB does, however, use Postgres (unless you 
use the embedded database, which you shouldn't). Puppet Dashboard is an 
ENC, but ironically, uses MySQL not Postgres.


Stuart,

Starting *another* ENC thread a day later isn't likely to get you many 
more responses than the two to your last question. I assumed, given your 
lack of response to my reply, that you're not terribly interested in 
sharing what you need an ENC to do... As I mentioned, I'm working on 
getting a Python/Django (Postgres-backed) ENC ready for release... if 
you want to see the current code, that could be arranged, though it's 
not really up to the "just run this puppet module and it installs the 
ENC" stage yet.


-jantman

On 12/04/2013 05:10 PM, Stuart Cracraft wrote:

Hi Ygor/Dan,

Postgres has better DR.

We like Postgres.

Stuart

On Wednesday, December 4, 2013 2:03:10 PM UTC-8, Ygor wrote:

Isn't that what PuppetDB is ?

“Sometimes I think the surest sign that intelligent life exists
elsewhere in the universe is that none of it has tried to contact us.”
Bill Waterson (Calvin & Hobbes)


*From: *"Stuart Cracraft" >
*To: *puppet...@googlegroups.com 
*Sent: *Wednesday, December 4, 2013 4:33:51 PM
*Subject: *[Puppet Users] external node classifier with a back-end


Hi everybody!

Anyone have a back-ended external node classifier to a Postgres
database
they could throw my way?

Stuart


-- 
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/7781bed3-7e5a-46e2-8949-e00bfac0fbd0%40googlegroups.com

.
For more options, visit https://groups.google.com/groups/opt_out
.

--
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/c642f1be-1121-4ab9-b56a-29b54809140f%40googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.


--
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/52A06E8A.4040804%40jasonantman.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] external node classifiers

[Jason Antman]

Stuart,

Yes, many of us use ENCs, though it seems to be mostly limited to larger
shops; these days many people are moving in the direction of hiera
instead. I've been using various ENCs for the past ~4 years.

There are relatively few good choices for already-written ENCs. (well,
if you just want a simple script, you can write it yourself; most of the
"ENCs" that are available provide a web interface for configuring
everything). The most popular options that I know of are Puppet
Dashboard (aka Console in Puppet Enterprise) and Foreman. The current
version of Dashboard (IMHO) has some serious issues, though PL is
actively working on them and I'm told that big improvements can be
expected. Foreman is good, solid software but does a LOT in terms of
provisioning, DNS and DHCP control, etc. as well as a lot of internal
logic about setting variables and classes, etc. so I feel that it's a
bit much if all you want is a plain-and-simple ENC.

I'm in the process of polishing up my company's internal ENC, and plan
on releasing it on github. It's a python/Django app that supports
multiple inheritance and overrides, class and parameter exclusions, and
has full support for parameterized classes and deep data structures.

That being said, I've also written ENCs in the past that were quite
simple - type in a hostname, check off some boxes for classes and
groups, and you're done.

As to samples - unfortunately, no, I don't... but you just need some
script that prints valid YAML according to the spec. Without knowing
more about how you want it to work, I can't provide much of an example.

"My current question is how do you use the ENC definitions within the
classes?"

Well, most of the ENCs I've used in the past (Puppet Dashboard included)
just return a list of classes to apply to the node, and a list of
parameters. The parameters are passed to puppet as top-scope variables.
So your ENC defines a parameter called, say, httpd_version, and
somewhere in your httpd class, you use $::httpd_version. Of course then
you really need to follow the params.pp pattern to declare a default
value, and validate what the ENC passes in. This pattern really sucks.

Lately, especially since puppet3 came out, I've been using an ENC that
supports parameterized classes. So I don't do anything special in my
classes (in fact much of what I use are modules from the Forge), and I
just tell the enc what classes I want, and the parameters that I want
passed in to them. This allows me to use many of the forge modules
(especially the puppetlabs ones) straight from my ENC.

I'd be happy to provide a bit more advice if you have more specific
questions.

-Jason


On 12/03/2013 06:50 PM, Stuart Cracraft wrote:
> Hi,
>
> I'd like to use ENC::
>
>   http://docs.puppetlabs.com/guides/external_nodes.html
>
> to keep hardwired customizations away from our classes and other files
> as much as possible
> particularly for the node name, but potentially as esoteric as a
> machine configuration, file
> permission, service name, etc - to keep the classes as flexible and
> general as possible.
>
> My questions:
>
>   + have you done the above?
>   + what were your learnings
>   + do you have sample puppet_node_classifier's you can share?
>   + how to use the definitions from ENC via the pm's puppet.conf's
> linkage to the ENC
>
>[main]
>:
>node_terminus = exec
>external_nodes = /usr/local/bin/puppet_node_classifier
>:
>
> My current question is how do you use the ENC definitions within the
> classes?
>
> Is this adequately described in-depth in the yet-to-be-published
> Puppet book?
>
> Stuart
>
> -- 
> 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/7b5670b1-8ca6-4d63-bb38-3d0e5f5bfae6%40googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

-- 
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/529F2359.4060801%40jasonantman.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] testing and exported (nagios) resources

[Jason Antman]

Hello,

I have 3 puppet stacks (master, puppetdb, enc) - dev, test/qa and prod.
Dev is used for initial development and testing of code (including
puppet), which is then promoted to test and then prod.

I'd like to start using the nagios types to configure monitoring, via
exported resources (yes I'm aware of the issues with the builtins, but
they'll have to do for now). I only have one Nagios server, and I'd like
to reliably monitor at least some stuff on the dev and test puppet
nodes. So... setting up all 3 puppet stacks to export resources that are
realized somehow on the Nagios server isn't a possibility, as bad
manifests/modules could affect the monitoring of one of the dev or test
hosts.

What's the safe way to "freeze" exported resources, or prevent them from
being changed? The best that I can come up with so far is to have the
nagios server connected to the production puppetmaster, and when I want
to update the (exported resource) monitoring configuration for one of
the dev or test nodes, have to do a one-time run on each node in
question against the prod puppet master.

Any other thoughts or theories?

Thanks,
Jason Antman

-- 
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/529D363C.4030202%40jasonantman.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] init script status checks and puppet

[Jason Antman]

David,

What distro/OS are you running on? Have you tried looking
in$APP_DIR/log/app.log ?

That init script is not compliant with the Fedora/RedHat spec, so I'm
not sure if that would have anything to do with it (or, if you're on a
modern version of a Fedora/RHEL derivative, systemd/upstart take-over...)

What are the "minor variations for [your] environment"? They could
certainly be the problem, so it would be helpful if you could
pastebin/dpaste/gist the actual script you're running.

Here's a pattern I've often used for things like this (note this is from
memory, so syntax may need to be adjusted a bit):

1) change the path to the init script (your File resource) to
/etc/init.d/node.orig
2) As it *looks* to me like it should work for this script, change the
first line of the script to "#!/bin/bash -x" which will run print bash
debugging information as commands are run (same as set -x).
3) manually, give /etc/init.d/node this content:

#!/bin/bash

date >> /var/log/node-wrapper.log
echo "Args: $@" >> /var/log/node-wrapper.log
# this next line executes /etc/init.d/node with the same args as this
script, and logs all output
/etc/init.d/node.orig "$@" 2>&1 >> /var/log/node-wrapper.log
ret=$?
echo "exited $ret" >> /var/log/node-wrapper.log
exit $?
EOF

That will at least give you a log of the date/time, arguments,
output/stderr, and exit code.

-Jason

On 11/22/2013 05:23 PM, David Ashby wrote:
> I've been experiencing some odd behavior with puppet and checking the
> status of running processes. Let me see if I can explain it:
>
> I have a very simple node.js socket server I'm attempting to
> puppetize. It is managed through an init.d script with start, stop,
> status, and restart. The init.d script runs perfectly fine as any
> other user in the system. However, when puppet attempts to check
> status or start the server, it fails and reports it received '1' on exit.
>
> I don't believe that the script has any hidden requirements of
> environment variables that aren't getting transferred around -- like I
> said, it's /very/ simple. Additionally, adding debugging echo
> statements to the script to try and prove that it's executing at all
> don't appear to fire, either. It has the same permissions as plenty of
> other functioning init scripts. I'm pretty much at my wit's end on
> this one.
>
> Relevant code:
>
> class service::nodesocketserver {
>  file { '/etc/init.d/node':
> ensure => present,
> owner  => 'root',
> group  => 'root',
> mode   => '0755',
> source => 'puppet:///modules/nodejs/node',
>   }
>
>   service { 'node':
> ensure => running,
> enable => true,
> hasstatus  => true,
> hasrestart => true,
> require=> File['/etc/init.d/node'],
>   }
> }
>
> /etc/init.d/node is https://github.com/chovy/node-startup with some
> minor variations for my specific environment.
>
> Again, everything works great when I run it manually but falls down
> when I throw puppet at it. Any advice, more debugging angles I could take?
> -- 
> 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/70dbf595-112a-4649-8798-7d78c7b7cc5c%40googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

-- 
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/52920743.6090207%40jasonantman.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] cannot find puppet_node_classifier

[Jason Antman]

As far as I know, "/usr/bin/puppet_node_classifier" is supposed to be 
the path to your ENC script.


What ENC are you trying to use? Either your ENC documentation should 
tell you how to configure this (Puppet Dashboard/Console, Foreman, etc.) 
or if you're writing your own ENC, this should be the path to your node 
terminus script.


On 11/21/2013 05:36 AM, shlo.af...@gmail.com wrote:



Hi,
I'm trying to learn configure puppet nodes using ENC. The instruction 
tell to add to puppet.conf the line:

external_nodes = /usr/bin/puppet_node_classifier

I cannot find  puppet_node_classifier anywhere in my system. I have 
puppet 3.3.1 installed.

What I need to install in order to have it?
Thanks.

--
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/a66813f4-f0d6-4b8d-b792-d4910993c892%40googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.


--
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/528DFDB8.7000802%40jasonantman.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] package conflict resolution method:

[Jason Antman]

Matt,

I can't speak for exactly what John was implying, but I've been working
on something similar recently, and facing more or less the same problems
that you're implying below, so I'll give you my take on it.

1) Yes, it means factoring "all" possibly-shared resources out into
discrete classes. The definition of "all" is flexible depending on how
fine-grained your package management needs to be, and how willing you
are to possibly have some "extra" packages floating around.

2) Including modules from the Forge is another beast. At this point, at
$work, we're moving in the direction of *only* writing our own modules
if there isn't a suitable Forge module. So, we've ended up with a few
cases where we have two conflicting modules that can't be used on the
same node (usually a Forge module that is intended to replace an older
in-house module as it's phased out).

The "proper" way to manage this is when you add a Forge module that
replaces existing functionality, you should remove any existing
declarations of those resources and replace them with a require, or
something like that.

A specific example... we recently started using the
puppetlabs-postgresql Forge module
(https://github.com/puppetlabs/puppetlabs-postgresql/). It has a
postgresql::lib::python class that installs the python-psycopg2 package
(the python postgres driver), and a postgresql::lib::devel class that
installs postgresql-devel. So, when we decided we were going to use the
new Forge module, we grepped through all of our existing modules, and
replaced any Package resources for these packages with "require
postgresql::lib::python" and "require postgresql::lib::devel", respectively.

I assume I speak for many in saying that I hope that with the
ever-increasing usefulness of the Forge, the community begins to
converge on a single "canonical" module for a given use case or package.

-jason antman

On 11/19/2013 02:48 PM, Matt Simmons wrote:
> Hi John, 
>
> I'm new around here, but I'm also in the same situation as Tom, who
> started this thread. 
>
> I was wondering if you could expound a little bit on the better
> solution that you mention. I write what I could refer to as "third
> grade puppet", but I'd like to get better. 
>
> When you suggest factoring out these resources into separate classes
> and modules, do you mean that, in essence, all possibly-shared
> resources should be in discrete modules or classes? How does that jive
> with modules included from Puppet Forge? Doesn't that mean refactoring
> everything you include there, as well? 
>
> Thanks, and sorry for what I'm sure is an overly-basic question,  
>
> --Matt Simmons 
>
>
> -- 
> 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/7f66b5b7-6e20-4835-a057-b62c1add08e7%40googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

-- 
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/528CAF44.1050205%40jasonantman.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] Re: Continuous Integration Questions for Modules

[Jason Antman]

I've got to agree with JuanBrein, I've been using puppet since 0.24.5
and I don't remember ever seeing a problem like this. How are you
deploying your modules?

Even if you have a "time consuming" deploy process (i.e. not just a git
fetch and pull), and inconsistent state on disk is a valid concern, you
could easily bypass this by staging the deploy to a path and then either
renaming or switching symlinks to instantly activate the newly deployed
code/artifact.

-jantman

On 11/20/2013 06:39 AM, JuanBrein wrote:
> Have you seen such a problems or is just an assumption? I've worked on
> a few puppet implementations and changing puppet master manifests on
> the go has never been an issue.
>
> I might be misunderstanding your question, can you develop more around
> your deployment process?
>
> On Tuesday, November 19, 2013 9:01:27 PM UTC, gilbertc777 wrote:
>
> Hi All,
>
> Using Jenkins to perform CI as well as automated deployment of
> puppet modules to our master.
>
> One thing that I am trying to figure out, is what is the best way
> when deploying the modules to have puppet not "error" out
> communication wise if nodes happen to check in while the
> deployment is ongoing.  I thought of using mcollective to stop
> puppet on all the nodes, then roll the new modules, then restart
> (puppet is in splay mode so should not overwhelm it).
>
> Any thoughts/suggestions are appreciated!
>
> Thanks!
>
> Chuck
>
> -- 
> 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/7c7871f0-186e-4f02-9e5a-ba497dd1de4a%40googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

-- 
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/528CAB19.8070900%40jasonantman.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] Yum Related Versioning Issue

[Jason Antman]

I'll wager that Michael is correct here (based on what he says, not just
his knowledge of packaging).

Can you provide the actual, full names of the package in question, or
the rpm -qi output?

My guess, based on having the same problem, is that if
ensure => '5.35.0-3_el5'
is failing, then you'll have success with
ensure => '5.35.0-3_el5.x86_64'

I can't find the supporting documentation at the moment, but based on
how the package is built (well, the values of certain fields/parameters
in the spec file), there are only certain substrings of the full package
name (packagename-X.Y.Z-release.dist.arch) that yum recognizes.

My memory of this is that you can either specify the version (X.Y.Z) or
you have to specify *everything* in the package
name/version/release/dist/arch. Or you can specify "name.arch" and a
version, as Michael suggested.

-jantman


On 11/19/2013 05:09 PM, Michael Stahnke wrote:
> Sometimes yum (and things calling it) do better when using
> package-name.arch like  openldap-libs.i386 vs openldap-libs.x86_64 if
> that makes sense. I think that's what's happening.
>
> On Tue, Nov 19, 2013 at 5:43 AM, Dan White  wrote:
>> Did you try
>>
>> yum update --verbose 
>>
>> as suggested ?
>>
>>
>> “Sometimes I think the surest sign that intelligent life exists elsewhere in
>> the universe is that none of it has tried to contact us.”
>> Bill Waterson (Calvin & Hobbes)
>>
>> 
>> From: "Richie Rees" 
>> To: puppet-users@googlegroups.com
>> Sent: Tuesday, November 19, 2013 8:33:35 AM
>> Subject: Re: [Puppet Users] Yum Related Versioning Issue
>>
>>
>> Hello again Ygor,
>>
>> Its a 64 bit internal  package, its only built for the 64 bit platform.
>> there are a number of different versions in the repo but none of the same
>> major build so can't see why it would be getting confused.
>>
>> Thanks,
>>
>> Richie.
>>
>>
>>
>> On Tuesday, 19 November 2013 13:23:47 UTC, Ygor wrote:
>>> Details, please.
>>>
>>> What is the package in question ?
>>>
>>> Are you running 32 bit or 64 bit ?
>>>
>>> “Sometimes I think the surest sign that intelligent life exists elsewhere
>>> in the universe is that none of it has tried to contact us.”
>>> Bill Waterson (Calvin & Hobbes)
>>>
>>> 
>>> From: "Richie Rees" 
>>> To: puppet...@googlegroups.com
>>> Sent: Tuesday, November 19, 2013 4:48:48 AM
>>> Subject: [Puppet Users] Yum Related Versioning Issue
>>>
>>> Hi All,
>>>
>>> Come to borrow some of your collective wisdom again,  Seeing a problem
>>> installing an rpm using a fairly basic class on a RHEL 5 box using yum as
>>> the provider, I am seeing the following error message :-
>>>
>>> Error: Could not update: Failed to update to version 5.35.0-3_el5 , got
>>> version 5.35.0-3_el5 instead
>>>
>>> This is reported as a fail so all the resources that are dependent on the
>>> package installing including the service and config files are not set as the
>>> class states they should be.
>>>
>>> --
>>> 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/4e79b8ce-ee3d-4b01-a28c-32ce3e401838%40googlegroups.com.
>>> For more options, visit https://groups.google.com/groups/opt_out.
>> --
>> 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/11708b3a-6ad4-40b5-afa6-ca3d52c844e5%40googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>> --
>> 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/545694092.4619408.1384868583959.JavaMail.root%40sz0126a.westchester.pa.mail.comcast.net.
>>
>> For more options, visit https://groups.google.com/groups/opt_out.

-- 
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/528CA98B.5090007%40jasonantman.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] Run 'puppet facts' in ENC

[Jason Antman]

The "right" way would probably be to query PuppetDB if you're using it.

If you're not using it, the `puppet facts` face (at least in terms of 
querying by node) seems to just be a CLI for the Inventory Service REST 
API, which is documented at 
http://docs.puppetlabs.com/guides/inventory_service.html - so you should 
just query that directly.


-jantman

On 11/17/2013 09:19 PM, Alexander Luetjen wrote:

Hi,

In an ENC I try to run 'puppet facts find ' to retrieve more 
information about a node.


However, the execution of 'puppet facts' fails with the following 
error message:


Error: could not initialize global default settings: couldn't find 
HOME environment -- expanding `~/.puppet'


What's correct way to access facts about a node in an ENC?

Thanks,
Alex
--
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/e98ad6d8-4824-497a-8595-29d497c3cd1b%40googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.


--
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/528A140C.8010102%40jasonantman.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] some good books

[Jason Antman]

I haven't read the new edition, but the last was good.

As much as I hate to say this (for all of the people who write Puppet 
books) I've found that things are changing fast enough that I usually 
recommend one or two books for a beginner to get the ropes, and then 
after that, rely on the online documentation, the community (here and 
#puppet), and the many modules on the Forge and GitHub to answer more 
advanced questions and keep up with what people are doing.


-jantman

On 11/15/2013 04:15 PM, Stuart Cracraft wrote:

Good stuff! I've ordered the print copy.

On Friday, November 15, 2013 1:01:06 PM UTC-8, Rich Burroughs wrote:

The new Pro Puppet is likely to be great, I haven't read it yet.
It's updated for 3.x.

http://www.apress.com/9781430260400



Rich

On Thursday, November 14, 2013, Stuart Cracraft wrote:

Hi,
I have some books on Puppet, none of which impresses me.
What are the Puppet books you have and why do you think they
are good.
Don't you think they are out-of-date?
Stuart
-- 
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/519b5ca9-b10f-4df4-91e8-fa486aff9478%40googlegroups.com

.
For more options, visit
https://groups.google.com/groups/opt_out
.

--
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/7617c94b-f055-4d43-8bec-7a2980976bc5%40googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.


--
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/5286A1C0.7090604%40jasonantman.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] Puppet dashboard web interface

[Jason Antman]

Oh wow. I shouldn't comment before I have my coffee. Yes you have it
exactly right, if you call the parameter "env", it will show up as
"$::env". I've fixed the example below.

-jantman

On 11/13/2013 08:50 AM, Thomas RICOU wrote:
> Hi, I think you understood quite well my question even if  I was not
> so clear... ;)
>
> Anyway, according to what you say, let's say that my (ENC) group is
> named 'DEVEL' and the var named 'env' is set to 'devel'. I add the
> node 'foo.example.com' to the 'DEVEL' group. Shouldn't the var be
> named '::env' instead of '::foo' ? Because when I addthe node
> 'bar.example.com' to that same group, the variable will be '::env' or
> '::bar' ?
>
> Thx
> Tom
>
> Le mercredi 13 novembre 2013 13:29:44 UTC+1, Jason Antman a écrit :
>
> Tom,
>
> I'm not sure I totally understand your question; I've also never
> used an
> ENC (like dashboard) with default.pp, only with modules.
>
> If you set a parameter called "env" on a group in Dashboard, and then
> add node "foo.example.com <http://foo.example.com>" to that group,
> the parameter will available
> in puppet as a top-scope/global variable, i.e. $::env.
>
> Is that what you were asking?
>
> -jantman
>
> On 11/13/2013 06:54 AM, Thomas RICOU wrote:
> > Hi
> >
> > I'm kinda noobish to puppet and I can't find an answer to my
> question.
> > What can I can do with the dashboard groups ? In fact I'm
> interested
> > in setting a var "env" to a value in ['devel','valid','prod']. this
> > value should be set only once when I create a new virtual machine
> > using a puppet agent. The thing is that this machine will use a
> > "default" node configuration which needs to know the value of the
> > "env" var. For some reasons, I don' t want to create a node file
> per
> > machine setting this param so I searched for something very easy
> to do
> > so. I found the "Groups" I saw in the dashboard web interface
> and in
> > which I created that "env" var but I can't figure out how to get
> it's
> > value back in default.pp node file.
> >
> > Am I completely wrong using these Groups?
> >
> > Thanks
> >
> > Tom
> > --
> > 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/d267b355-fc88-4f23-b60e-dffcb7f12de1%40googlegroups.com
> 
> <https://groups.google.com/d/msgid/puppet-users/d267b355-fc88-4f23-b60e-dffcb7f12de1%40googlegroups.com>.
>
> > For more options, visit https://groups.google.com/groups/opt_out
> <https://groups.google.com/groups/opt_out>.
>
> -- 
> 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/ba237ea7-16d8-406c-b9de-27ef2728e1ec%40googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

-- 
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/5283D54B.3040907%40jasonantman.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] Puppet dashboard web interface

[Jason Antman]

Tom,

I'm not sure I totally understand your question; I've also never used an
ENC (like dashboard) with default.pp, only with modules.

If you set a parameter called "env" on a group in Dashboard, and then
add node "foo.example.com" to that group, the parameter will available
in puppet as a top-scope/global variable, i.e. $::foo.

Is that what you were asking?

-jantman

On 11/13/2013 06:54 AM, Thomas RICOU wrote:
> Hi
>
> I'm kinda noobish to puppet and I can't find an answer to my question.
> What can I can do with the dashboard groups ? In fact I'm interested
> in setting a var "env" to a value in ['devel','valid','prod']. this
> value should be set only once when I create a new virtual machine
> using a puppet agent. The thing is that this machine will use a
> "default" node configuration which needs to know the value of the
> "env" var. For some reasons, I don' t want to create a node file per
> machine setting this param so I searched for something very easy to do
> so. I found the "Groups" I saw in the dashboard web interface and in
> which I created that "env" var but I can't figure out how to get it's
> value back in default.pp node file.
>
> Am I completely wrong using these Groups?
>
> Thanks
>
> Tom
> -- 
> 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/d267b355-fc88-4f23-b60e-dffcb7f12de1%40googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

-- 
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/528370B8.2090103%40jasonantman.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] Migrating from Puppet open-source to Puppet Enterprise

[Jason Antman]

You definitely *can* move PuppetDB to another host, but I think you'd
either be mostly on your own doing it, or need to reach out to support.
AFAIK it's not supported by the installer, and I don't remember seeing
documentation on it.

The hardest part would probably be moving PuppetDB's database, but aside
from that, it's really just a matter of telling the PE installer to put
PuppetDB on the new host, and then changing some configuration files to
point to the new host.

If you happen to be building this out on VMs, I'd recommend splitting
them from the start, and just adding resources as needed. But if you're
looking to purchase PE, I imagine that puppet labs support would be able
to give you some advice on this.

-jantman

On 11/07/2013 07:26 PM, Forrie wrote:
> We have perhaps 40 to 50 systems, give or take, that are mostly under
> Puppet management (not all).   After having spent some time doing my
> own thing with open-source, I'm looking into migrating to PE.
>
> One question I have is relative to initial deployment -- if I decide
> to keep PuppetDB on the same server as Master, can I later migrate
> that role off onto another host?I don't believe we have enough
> traffic yet to justify breaking this all down (yet) -- and this will
> greatly simplify things.
>
> I also have the daunting task of re-writing all my individual
> manifests into proper modules :-)
>
> Thanks!
>
> -- 
> 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/672ddcd1-19e4-4641-a27e-b5972e4c864d%40googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

-- 
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/527CD719.3020209%40jasonantman.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] Compile catalog against tagged version of a git repo?

[Jason Antman]

Well, yes and no. There's no feature that directly supports "compile 
using this git tag/branch/hash", because puppet doesn't "know" about 
git, it just operates on a directory (modulepath). What most people do 
is check out the git tag/brach/hash to a directory on the puppetmaster, 
and use that as an environment (see 
http://docs.puppetlabs.com/guides/environment.html and 
http://puppetlabs.com/blog/git-workflow-and-puppet-environments). If you 
need something more automated, you can always use a git hook to create 
the directory and do the checkout on your puppetmaster. Then you'll just 
specify the correct environment name when you run your agent.


I'm in the process of doing a puppet3 rollout that makes heavy use of 
this process. I'm planning on writing a series of blog posts detailing 
it, but haven't really gotten started yet. If you need some more 
specific instructions, I can try to provide some.


-jantman

On 11/03/2013 07:59 PM, Schofield wrote:
I'm wondering if there is any feature that will allow puppet to 
compile a catalog against a specific tag of a git repo?

--
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/2e941022-133c-4008-8b23-52a0492c9bf6%40googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.


--
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/52779C98.9060901%40jasonantman.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] python virtualenv module

[Jason Antman]

Taj,

I've considered that option as well, but that prevents the
list-to-multiple-resources language functionality from working. i.e.

$requirements ['tox', 'pytest', 'coverage']
python::package { $requirements }

-jantman

On 11/02/2013 01:59 AM, Sirtaj Singh Kang wrote:
>
> On 11/2/2013 3:31 AM, Jason Antman wrote:
> [snip]
>> package installation - but the module (or at least our version of it)
>> doesn't handle requirements files, and uses a define to pip install
>> packages, so a given package can only be installed in one venv on a
>> node.
>
> I have a hacked-up python virtualenv module, since I hadn't seen any
> when I started out. I got around the singleton define problem you've
> outlined by adding an optional package name parameter, which defaults
> to the name of the define. This way you can keep the old behaviour for
> simple cases:
>
> python::virtualenv::package {
> '':
> venv => ''
> }
>
> but in the case where you want the same package in two environments,
> you use a globally unique resource name and use the optional param:
>
> python::virtualenv::package {
> '-':
> venv => '',
> package_name => ''
> }
>
> When these defines are called internally (as a side effect of
> installing dependencies for an app, for example), I always use the
> latter format.
>
> That doesn't fix the requirements.txt problem, of course. I've been
> looking at that too, but I don't feel that a pure puppet DSL solution
> is necessarily the right way to approach it. A custom ruby plugin
> might be a better solution.
>
> -Taj.
>

-- 
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/527553F9.8090801%40jasonantman.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] How to determine puppet environment when using passenger

[Jason Antman]

Derek,

In most circumstances, yes, you should be running puppet commands as
root (via sudo). Running via sudo seems to be the standard, and the best
practice, in Linux environments. You could use some other methods if you
have a... unusual... environment, but running puppet commands as a
normal user will both look in the user's home directory by default, and
won't be able to do most things that puppet normally does, as it will
need root privileges to do things like installing packages and altering
system-wide configuration files. It's been a while since I've looked,
but the puppet documentation (http://docs.puppetlabs.com/puppet/) should
cover this.

-jantman

On 11/01/2013 06:01 PM, Derek Cole wrote:
> Hello,
> I am trying to figure out what the best way to use puppet when I am
> using passenger. I noticed that if I log in as my normal user on
> Ubuntu 12.04, and run "puppet config print" it gives me the incorrect
> configuration than what I think I am running when I am using
> apache/passenger/puppet
>
> For example, it shows my confdir as being in my users homedir/.puppet
> instead of /etc/puppet
>
> When i log in as root, and run the command, everything looks correct.
> Am I just supposed to work in root all the time when I am running
> puppet's commands? I noticed this is also a problem when I am having a
> custom modulepath..if I run puppet install module as a user, it puts
> it in my home dir, instead of in the configured modulepath i have in
> my puppet.conf
>
> Please advise -
>
> Thanks!
> -- 
> 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/589c9a47-3318-46ee-94e4-85c286fec780%40googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

-- 
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/5274625F.5060007%40jasonantman.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] Monitoring services

[Jason Antman]

Yasha,

Interesting. When it says the status has changed from stopped to
running, it should be calling the restart command. Can you post the
puppet agent --debug output somewhere, either attached or pastebin/etc.?
And perhaps the init script itself?

So you're using one init script for multiple instances. Have you
considered using separate init scripts (templated by Puppet?) and
separate Service resources for each instance (i.e. "service1",
"service2", or something like that)? Controlling multiple instances via
one init script is possible, and I've seen it done at a lot of places,
but it usually adds to confusion, and increases the possibility of
problems (like this one).

-Jason

On 11/01/2013 06:02 PM, Yasha Zislin wrote:
> Jantman,
>
> The problem is that init status script does return 0 when puppet
> checks the service. Since I have one of the two instances of service
> running, init script returns 0 and that's not cool.
> Multiple instances just run with different parameters like interface.
> So when you look at ps auxf, you would see two entries. When you run
> init status script, it returns two PIDs.
>
> After I posted this question, I got an idea.
> I've tweaked my init script so when one instance dies, return value is
> non-zero. Or in fact it is 3 which means that service is dead.
>
> Now the problem is that puppet doesnt restart it for some reason. It
> states that service status has changed from "stopped" to "running" but
> the service restart command does not get initiated.
>
> P.S. Thanks nikolavp for response but I need to get this working with
> puppet.
>
>
>
> On Friday, November 1, 2013 5:17:25 PM UTC-4, Jason Antman wrote:
>
> Yasha,
>
> What distribution are you running? Is there any chance that you've
> specified somewhere a non-default provider for the Service type?
>
> I'm confused... this doesn't seem to be a Puppet issue to me. You
> include "hasstatus => true"... so Puppet should restart the
> service if
> your init script returns non-0. Are you sure your init script is
> returning non-zero to trigger the restart?
>
> How are you configuring the multiple instances? The myApp::service
> class
> that you show below can only be applied once on a given node.
>
> -jantman
>
> On 11/01/2013 11:41 AM, Yasha Zislin wrote:
> > Hello,
> >
> > I have multiple instances of a service running on linux server.
> This
> > service has status, restart, start and stop init scripts.
> > One of the instances keeps dying for unknown reasons (probably
> network
> > related).
> > I have puppet configured to monitor the service but it doesnt
> consider
> > it to be down when one of the instances dies.
> >
> > Is there a way to configure puppet to initiate restart when one
> of the
> > instances dies?
> >
> > Here is my current config
> >
> > class myApp::service {
> >   service { "myService":
> > ensure => running,
> > hasstatus  => true,
> > hasrestart => true,
> > enable => true,
> >   }
> > }
> >
> > Thanks.
> > --
> > 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/5de0eace-4117-4ac1-8cd2-23e6efc17237%40googlegroups.com
> 
> <https://groups.google.com/d/msgid/puppet-users/5de0eace-4117-4ac1-8cd2-23e6efc17237%40googlegroups.com>.
>
> > For more options, visit https://groups.google.com/groups/opt_out
> <https://groups.google.com/groups/opt_out>.
>
> -- 
> 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/cd959b13-bc2f-44c1-8cf5-30f0521cd723%40googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

-- 
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/5274615A.4070601%40jasonantman.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] python virtualenv module

[Jason Antman]

Hello, community,

I work for a python/Django shop (we run supposedly one of the largest
Django apps out there), and we're just starting to use Puppet for
handling python stuff (and hopefully application deploys, eventually).
We're currently using a hacked up version of Mozilla RelEng's excellent
and quite helpful python module to handle virtualenv creation and pip
package installation - but the module (or at least our version of it)
doesn't handle requirements files, and uses a define to pip install
packages, so a given package can only be installed in one venv on a node.

Is anyone aware of a better, more complete python/virtualenv module?
I've seen stankevich/python on the forge, which handles requirements
files but doesn't fix the issue with only being able to install a given
package once per node (which, AFAIK, can be fixed with a native provider
but not a defined type). If not, does anyone have interest in
collaborating or contributing to a more feature-complete
python/virtualenv module?

If anyone's interested in collaborating, or can suggest an existing
module (stankevich's? or moz releng?) to start with, I've spoken with
one of the pip/virtualenv maintainers and he's interested in finding
something suitable that could become the "official" module.

Thanks for any advice, input or suggestions,
Jason Antman
jantman

(ccing djmitche as I can't find a mozilla releng email list)

-- 
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/527424AE.30902%40jasonantman.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] package conflict resolution method:

[Jason Antman]

Tom,

I've actually been working with similar issues lately (and am in the
process of working on a virtualenv module).

I have a python module that includes classes for the common dependencies
(i.e. "require python::pyyaml") and have been pretty happy with that
pattern so far, but if you want, I believe the stdlib ensure_packages()
can also do this.

-jantman

On 11/01/2013 05:03 PM, Tom Noonan wrote:
> Hello, list:
>   I have two puppet modules that are unrelated to each other, but
> both have (unrelated) Python scripts that parse YAML.  As such, both
> have a block like the following in their manifests for the PyYAML script
> dependency:
>
>   package { 'PyYAML':
> ensure  => installed,
>   }
>
>   If I try and include both modules on the same server this
> causes an obvious conflict as the PyYAML package is now defined in two
> different package{} blocks.
>   Can the list please advise on what best practice is in this
> case?  I'd prefer not to create a whole other module just to do a class
> dependency for PyYAML, but if that is best practice so be it.  Please
> let me know if I'm overlooking any other solutions.  Thanks!
>
> --Tom N.
>
>
>

-- 
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/52741ADE.7030504%40jasonantman.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] Monitoring services

[Jason Antman]

Yasha,

What distribution are you running? Is there any chance that you've
specified somewhere a non-default provider for the Service type?

I'm confused... this doesn't seem to be a Puppet issue to me. You
include "hasstatus => true"... so Puppet should restart the service if
your init script returns non-0. Are you sure your init script is
returning non-zero to trigger the restart?

How are you configuring the multiple instances? The myApp::service class
that you show below can only be applied once on a given node.

-jantman

On 11/01/2013 11:41 AM, Yasha Zislin wrote:
> Hello,
>
> I have multiple instances of a service running on linux server. This
> service has status, restart, start and stop init scripts.
> One of the instances keeps dying for unknown reasons (probably network
> related).
> I have puppet configured to monitor the service but it doesnt consider
> it to be down when one of the instances dies.
>
> Is there a way to configure puppet to initiate restart when one of the
> instances dies?
>
> Here is my current config
>
> class myApp::service {
>   service { "myService":
> ensure => running,
> hasstatus  => true,
> hasrestart => true,
> enable => true,
>   }
> }
>
> Thanks.
> -- 
> 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/5de0eace-4117-4ac1-8cd2-23e6efc17237%40googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

-- 
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/52741A65.90607%40jasonantman.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] What's the best practice to manage software updates using puppet ?

[Jason Antman]

We use largely the same solution as Jo but with an ENC.

Packages that we really don't care about are usually just ensure => 
present, so every machine built from a given release should have the 
same version (upgrades because of dependencies aside), or ensure => 
latest in the rare case that we've decided it's trivial or stable enough 
to allow automatic updates.


For anything that we care about, we install using a parameterized class, 
that exposes a package_version parameter which we explicitly set to a 
version in our ENC. For testing/QA, we override that parameter on a host 
or group level to a newer version, and once it's validated, we change 
the version in the "default" environment. (Well actually, that's how it 
works in our new puppet3 infrastructure, currently being rolled out, 
which uses an in-house Django-based ENC. In our "old" puppet 
infrastructure that uses Puppet Dashboard, we have a *bunch* of 
parameters (which show up in puppet as globals) set on groups or nodes, 
like "postgres_version" or "httpd_package_version").


-jantman

On 10/31/2013 01:40 PM, Jo Rhett wrote:
There's always the alternative of using "ensure => heira( 
'package_version', present )" and using hiera to control the software 
release. If you're doing this you want osfamily in the hiera 
structure. I've found this much superior to either of the following 
two choices.


On Sep 25, 2013, at 10:13 AM, phundisk > wrote:
For me, when I was deciding to manage updates, there were two options 
for me.


1. Set everything to ensure latest and only use clones of 
centos/redhat repos for different environments such as QA, and 
production.  The downside of here is that you need to manage every 
package in puppet, you will probably miss some.
And that you'll need to keep clones of the repos for each environment, 
which AFAIK is about 100G per environment.


2. Just use ensure => present and use another solution such as 
spacewalk or satellite to manage updates.  That is what I choose 
personally.  It works out pretty good so far.


On Tuesday, September 24, 2013 4:31:10 PM UTC-4, François Chenais wrote:

Hello,

I got many classes, using the well known template ...

package
 ensure => XXX
 notify => service

  file
 require => package
 notify => service

  service
 require => File, Package


... with ensure value XXX set to 'latest'.


This implies that package could be updated when I change a value
in config file even if I don't want to update it ... especially
in production ...

A solution can be changing all ensure value to 'present' or
'installed' but I'm not
the owner of the code so I would like to know if there is a way to

- deactivate the package update through a command line option ?
- change the ensure value using

  - a command line option
  - a fact
  - a tag
  - ???



More generally, what's the best practice to manage software
updates using puppet :

- ensure => present
- fix pkg repositories   :/
- ???


Thanks a lot


 François









--
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 post to this group, send email to puppet-users@googlegroups.com 
.

Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.


--
Jo Rhett
Net Consonance : net philanthropy to improve open source and 
internet projects.


Author of Instant Puppet 3 Starter: 
http://www.netconsonance.com/instant-puppet-3-starter-book/




--
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/30F8BCC6-5975-47C2-A574-2C54B67C5E71%40netconsonance.com.

For more options, visit https://groups.google.com/groups/opt_out.


--
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/52739877.5050002%40jasonantman.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] ENC - how to get info about the node

[Jason Antman]

Steven,

Can you be a little more specific about what you're trying to do?
Normally, you'd set that "department" variable in the ENC itself.

Puppet calls the ENC script (node_terminus) with the certificate name
(or is it the FQDN? I never remember, since they're both the same for
me) of the node that is requesting a catalog. Any additional information
that the ENC needs, it needs to get on its own. In the past I've always
followed the paradigm of a person manually inputting data into the ENC
via CLI script or Web UI - usually some combination of classes,
parameters and groups (templating containers holding one or more
classes, parameters, or other groups, and applied to multiple nodes).
However I don't see a reason other than time/performance why the ENC
couldn't also lookup information from facts (via PuppetDB or some other
method), Hiera, or other external data sources.

-jantman

On 10/27/2013 08:34 AM, Steven Jonthen wrote:
> Hi guys,
>
> It is only allowed to pass one parameter to your own ENC-Class in
> Puppet. But how can I set a "department" variable for each node and
> use it in my ENC-Script?
>
> Has anyone a clue how to do it? Thank's in advance!
> -- 
> 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 post to this group, send email to puppet-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/puppet-users.
> For more options, visit https://groups.google.com/groups/opt_out.

-- 
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 post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.