Re: [Puppet Users] puppet module environment bug?
So when I replace list with upgrade and specify which module within that environment to upgrade, am I expecting that module's dependencies to be upgraded / installed in the common modules? I ask as we got quite the fright what that happened... I just tested with --modulepath=environments/tools_office/modules and got the expected results for both list and upgrade, but I'm concerned that --environment does not provide equivalent exclusivity for change operations. James On 29 January 2016 at 10:19, Lowe Schmidt <m...@loweschmidt.se> wrote: > /etc/puppet/modules is available for all environments (if I am not > mistaken). > > > -- > Lowe Schmidt | +46 723 867 157 > > On 29 January 2016 at 10:43, James Green <james.mk.gr...@gmail.com> wrote: > >> jamesg@puppet-master:/etc/puppet$ sudo puppet module list --environment >> tools_office >> /etc/puppet/environments/tools_office/modules >> └── garethr-docker (v4.1.1) >> /etc/puppet/modules >> ├── AlexCline-dirtree (v0.2.1) >> ├── AlexCline-fstab (v0.5.4) >> [ lots of others ] >> >> Why does puppet list the modules in the other environments? Is it a bug? >> >> Version: 3.8.5 >> >> Thanks, >> >> James >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Puppet Users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to puppet-users+unsubscr...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/puppet-users/CAMH6%2BaymZc6Qqb00Bn_-DBwpfvg6F8iQA2cMWdVV6heRMcjHhQ%40mail.gmail.com >> <https://groups.google.com/d/msgid/puppet-users/CAMH6%2BaymZc6Qqb00Bn_-DBwpfvg6F8iQA2cMWdVV6heRMcjHhQ%40mail.gmail.com?utm_medium=email_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to puppet-users+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/puppet-users/CAC-wWcSqjRkbrqQQfrZ6qVJoOHPDJO3i%3DsVuuhJjXVg9W8fJ3w%40mail.gmail.com > <https://groups.google.com/d/msgid/puppet-users/CAC-wWcSqjRkbrqQQfrZ6qVJoOHPDJO3i%3DsVuuhJjXVg9W8fJ3w%40mail.gmail.com?utm_medium=email_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CAMH6%2BayAOmVLxRW7XUOb8NMMzosO7kunaWXiEsvVQDVR7Otgfw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] puppet module environment bug?
jamesg@puppet-master:/etc/puppet$ sudo puppet module list --environment tools_office /etc/puppet/environments/tools_office/modules └── garethr-docker (v4.1.1) /etc/puppet/modules ├── AlexCline-dirtree (v0.2.1) ├── AlexCline-fstab (v0.5.4) [ lots of others ] Why does puppet list the modules in the other environments? Is it a bug? Version: 3.8.5 Thanks, James -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CAMH6%2BaymZc6Qqb00Bn_-DBwpfvg6F8iQA2cMWdVV6heRMcjHhQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Could not retrieve file metadata ... end of file reached
I am not convinced that this is to do with an agent being busy then attempting the next connection. Info: Retrieving pluginfacts Info: Retrieving plugin Info: Loading facts Error: Could not retrieve catalog from remote server: end of file reached Warning: Not using cache on failed catalog Error: Could not retrieve catalog; skipping run The above all happened within a few seconds. I might argue within 4-5 seconds. Unless of course I'd misunderstood your hypothesis? On 13 March 2015 at 05:28, Josh Cooper j...@puppetlabs.com wrote: On Thu, Mar 12, 2015 at 4:21 AM, James Green james.mk.gr...@gmail.com wrote: I was running puppet agent -t --noop repeatedly with this error. Running again, this time omitting --noop, it succeeded. Not entirely clear what this tells me... On 12 March 2015 at 10:58, James Green james.mk.gr...@gmail.com wrote: Error: /Stage[main]/Our_unattended_upgrades/File[/etc/apt/apt.conf.d/20auto-upgrades]: Could not evaluate: Could not retrieve file metadata for puppet:///modules/our_unattended_upgrades/etc/apt/apt.conf.d/20auto-upgrades: end of file reached Wrapped exception: end of file reached Versions on the server: ii facter 2.4.1-1puppetlabs1 all Ruby module for collecting simple facts about a host operating system ii hiera1.3.4-1puppetlabs1 all A simple pluggable Hierarchical Database. ii puppet 3.7.4-1puppetlabs1 all Centralized configuration management - agent startup and compatibility scripts ii puppet-common3.7.4-1puppetlabs1 all Centralized configuration management ii puppetdb 2.2.2-1puppetlabs1 all PuppetDB Centralized Storage. ii puppetdb-terminus2.2.2-1puppetlabs1 all Connect Puppet to PuppetDB by setting up a terminus for PuppetDB. ii puppetlabs-release 1.0-11 all Package to install Puppet Labs gpg key and apt repo ii puppetmaster-common 3.7.4-1puppetlabs1 all Puppet master common scripts ii puppetmaster-passenger 3.7.4-1puppetlabs1 all Centralised configuration management - master setup to run under mod passenger Are we looking at a known bug or are we really going to need to debug this? James On 11 March 2015 at 09:47, James Green james.mk.gr...@gmail.com wrote: Hi, Sorry for the delayed response. In our case we are using Passenger. On 5 March 2015 at 15:24, Henrik Lindberg henrik.lindb...@cloudsmith.com wrote: On 2015-05-03 12:02, James Green wrote: We occasionally have an agent fail because of this. I'm told by others running the agents more frequently that it appears to be at random and not on anything particularly large. If you are using webrick then it is most likely a concurrency problem (more than one agent calling in at the same time). Webrick is not recommended for production use because of this. - henrik -- Visit my Blog Puppet on the Edge http://puppet-on-the-edge.blogspot.se/ -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/ msgid/puppet-users/md9sfc%24r1e%241%40ger.gmane.org. 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/CAMH6%2Bay6EoB1zCZ587s%2B-gWno%3DGdHBR%3DKkhmD1aVHHXn66TsVw%40mail.gmail.com https://groups.google.com/d/msgid/puppet-users/CAMH6%2Bay6EoB1zCZ587s%2B-gWno%3DGdHBR%3DKkhmD1aVHHXn66TsVw%40mail.gmail.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. The fact that you are on puppet 3.7 and the error occasionally occurs, but not always, makes me think it's https://tickets.puppetlabs.com/browse/PUP-3238. Starting in puppet 3.7, we've added support for persistent HTTP connections, see https://docs.puppetlabs.com/puppet/latest/reference/subsystem_agent_master_comm.html#persistent-connections--keepalive . This eliminates the TCP/SSL handshake for every file metadata and content request, and greatly reduces the load on the master. But there is a possibility that a loadbalancer or puppetmaster may close an idle connection. Unfortunately, ruby does not surface socket errors when writing a request, only when reading. So often this issue manifests itself with end of file reached. To confirm if this is the case, make sure the puppet agent's http_keep_alive setting
Re: [Puppet Users] Could not retrieve file metadata ... end of file reached
Error: /Stage[main]/Our_unattended_upgrades/File[/etc/apt/apt.conf.d/20auto-upgrades]: Could not evaluate: Could not retrieve file metadata for puppet:///modules/our_unattended_upgrades/etc/apt/apt.conf.d/20auto-upgrades: end of file reached Wrapped exception: end of file reached Versions on the server: ii facter 2.4.1-1puppetlabs1 all Ruby module for collecting simple facts about a host operating system ii hiera1.3.4-1puppetlabs1 all A simple pluggable Hierarchical Database. ii puppet 3.7.4-1puppetlabs1 all Centralized configuration management - agent startup and compatibility scripts ii puppet-common3.7.4-1puppetlabs1 all Centralized configuration management ii puppetdb 2.2.2-1puppetlabs1 all PuppetDB Centralized Storage. ii puppetdb-terminus2.2.2-1puppetlabs1 all Connect Puppet to PuppetDB by setting up a terminus for PuppetDB. ii puppetlabs-release 1.0-11 all Package to install Puppet Labs gpg key and apt repo ii puppetmaster-common 3.7.4-1puppetlabs1 all Puppet master common scripts ii puppetmaster-passenger 3.7.4-1puppetlabs1 all Centralised configuration management - master setup to run under mod passenger Are we looking at a known bug or are we really going to need to debug this? James On 11 March 2015 at 09:47, James Green james.mk.gr...@gmail.com wrote: Hi, Sorry for the delayed response. In our case we are using Passenger. On 5 March 2015 at 15:24, Henrik Lindberg henrik.lindb...@cloudsmith.com wrote: On 2015-05-03 12:02, James Green wrote: We occasionally have an agent fail because of this. I'm told by others running the agents more frequently that it appears to be at random and not on anything particularly large. If you are using webrick then it is most likely a concurrency problem (more than one agent calling in at the same time). Webrick is not recommended for production use because of this. - henrik -- Visit my Blog Puppet on the Edge http://puppet-on-the-edge.blogspot.se/ -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/ msgid/puppet-users/md9sfc%24r1e%241%40ger.gmane.org. 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/CAMH6%2BazZoSjsGYKP%3D19q4p%2Bp6ASeSQKLVJ3Apd9NyHp52uo_pA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Could not retrieve file metadata ... end of file reached
I was running puppet agent -t --noop repeatedly with this error. Running again, this time omitting --noop, it succeeded. Not entirely clear what this tells me... On 12 March 2015 at 10:58, James Green james.mk.gr...@gmail.com wrote: Error: /Stage[main]/Our_unattended_upgrades/File[/etc/apt/apt.conf.d/20auto-upgrades]: Could not evaluate: Could not retrieve file metadata for puppet:///modules/our_unattended_upgrades/etc/apt/apt.conf.d/20auto-upgrades: end of file reached Wrapped exception: end of file reached Versions on the server: ii facter 2.4.1-1puppetlabs1 all Ruby module for collecting simple facts about a host operating system ii hiera1.3.4-1puppetlabs1 all A simple pluggable Hierarchical Database. ii puppet 3.7.4-1puppetlabs1 all Centralized configuration management - agent startup and compatibility scripts ii puppet-common3.7.4-1puppetlabs1 all Centralized configuration management ii puppetdb 2.2.2-1puppetlabs1 all PuppetDB Centralized Storage. ii puppetdb-terminus2.2.2-1puppetlabs1 all Connect Puppet to PuppetDB by setting up a terminus for PuppetDB. ii puppetlabs-release 1.0-11 all Package to install Puppet Labs gpg key and apt repo ii puppetmaster-common 3.7.4-1puppetlabs1 all Puppet master common scripts ii puppetmaster-passenger 3.7.4-1puppetlabs1 all Centralised configuration management - master setup to run under mod passenger Are we looking at a known bug or are we really going to need to debug this? James On 11 March 2015 at 09:47, James Green james.mk.gr...@gmail.com wrote: Hi, Sorry for the delayed response. In our case we are using Passenger. On 5 March 2015 at 15:24, Henrik Lindberg henrik.lindb...@cloudsmith.com wrote: On 2015-05-03 12:02, James Green wrote: We occasionally have an agent fail because of this. I'm told by others running the agents more frequently that it appears to be at random and not on anything particularly large. If you are using webrick then it is most likely a concurrency problem (more than one agent calling in at the same time). Webrick is not recommended for production use because of this. - henrik -- Visit my Blog Puppet on the Edge http://puppet-on-the-edge.blogspot.se/ -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/ msgid/puppet-users/md9sfc%24r1e%241%40ger.gmane.org. 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/CAMH6%2Bay6EoB1zCZ587s%2B-gWno%3DGdHBR%3DKkhmD1aVHHXn66TsVw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] puppetdb console and docs
The documentation at https://docs.puppetlabs.com/puppetdb/latest/maintain_and_tune.html talks about checking the MQ depth. I'm not seeing such a thing on our dashboard but plenty of others not documented such as Catalogue Duplication. Am I looking at outdated documentation? James -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CAMH6%2BaxTxqy5yC7AX%2BstW0379khse0dAXBAf3UqbKv0QtOB27A%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Could not retrieve file metadata ... end of file reached
Hi, Sorry for the delayed response. In our case we are using Passenger. On 5 March 2015 at 15:24, Henrik Lindberg henrik.lindb...@cloudsmith.com wrote: On 2015-05-03 12:02, James Green wrote: We occasionally have an agent fail because of this. I'm told by others running the agents more frequently that it appears to be at random and not on anything particularly large. If you are using webrick then it is most likely a concurrency problem (more than one agent calling in at the same time). Webrick is not recommended for production use because of this. - henrik -- Visit my Blog Puppet on the Edge http://puppet-on-the-edge.blogspot.se/ -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/ msgid/puppet-users/md9sfc%24r1e%241%40ger.gmane.org. 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/CAMH6%2Bays%2B5UYx4Lk51R0ZXrJNL6bCWtnTjGOPCyKprUr5F6Ygg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] puppet module list upgrades-available
I have a need to report on the modules we have installed and for each: 1. The version installed 2. The latest version available to upgrade to Any ideas how to get this as I'm not seeing a puppet module command to match. [ Fairly convinced I cannot be the first to ask this too... ] Thanks, James -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CAMH6%2BayCLvVZM8aJX2a1NqR6BVkKv%2BFwLrh4eeRk3ZWfAM-wmg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Could not retrieve file metadata ... end of file reached
We occasionally have an agent fail because of this. I'm told by others running the agents more frequently that it appears to be at random and not on anything particularly large. Looks like server and agents are 3.7.4, both Ubuntu. Can't see much in the way of server logs. Any ideas where to go to debug this? A few minutes on, and the agent in this case has now succeeded... Thanks, James -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CAMH6%2Bax-gWpyZLWHpB19_EWtD3OnG8U%3DHEvkJFtyK1HGzkAHHA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] puppetdb dies at random
An excellent write-up, thank you. In our case puppet-master is actually an LXC container instance. On reflection the values reported by top are meaningless, and I'm not convinced I know the solution for monitoring purposes. I might suggest however that part of application support now needs to include the question is this a container instance to help reduce time wasted by yourselves and others (this is not a criticism of you or your colleagues but an observation of an enhancement to be made across the industry in [potential] fault diagnosis). I have removed the -Xmx192M from our start-up parameters, we'll see how things go for the time being. Thanks, James On 16 February 2015 at 13:04, Ken Barber k...@puppetlabs.com wrote: 16850 puppetdb 20 0 12.697g 418684 14848 S 0.9 0.4 4:32.74 java That's top now since it began running around 10.30 this morning (GMT). 12G of ram? It's the only proc in the list having a 'g' against it. Seems excessive..? So, there is a difference in the columns here ... the column with the 'g' is the 'virtual' usage, that means its the amount of RAM allocated for potential usage. Its not using all of that memory right now, but it can under large circumstances change to use that much. I'm not quite sure why this is so high, you'd need to show a full output of your settings, perhaps a ps auxwww | grep java will give us the settings that have been passed and will enable me to understand why its so high. Either way, it's usually been set to do that by someone/something - by default our settings shouldn't enable Java to consume 12 GB out of the box, so I can only presume the heap setting was changed at some point. The column just after that is the RES column, indicating how much its actually consuming now. This is usually the important one. I'm of course trivialising the description of each column, but understand virt versus res is important. There are lots of articles on the internet about this subject that are definitely worth researching as a sysadmin. Another thing, if that is truly that high, you might want to check your dmesg output to make sure the process isn't getting caught by the OOMkiller in Linux. I have no other information about your system then what you've given me, so I can't make a judgement on whether 12 GB is high or not for you. It does seem high, although I could understand this increase in the setting if you were processing a lot of data. 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/CAE4bNTmhJFvS-cUg3UoUxpyCoKV8YX7WKC1fq72XwHQ5yPtnUA%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/CAMH6%2Bax8KHKUZV%3Dy4E7AO3%2B0kdBFsN0RnZFXywORti8Lzy0R_w%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] puppetdb dies at random
I have a 270MB puppetdb-oom.hprof.prev file in /var/log/puppetdb
Google reports this as http://projects.puppetlabs.com/issues/23237 however
this page is a 500 Internal Server Error at present.
On 16 February 2015 at 12:13, Ken Barber k...@puppetlabs.com wrote:
It might be that PuppetDB is running out of heap? Check
/var/log/puppetdb for a file 'puppetdb-oom.hprof' for an indiciation
this is happening.
You can find instructions for how to adjust your heap space here:
https://docs.puppetlabs.com/puppetdb/2.2/configure.html#configuring-the-java-heap-size
ken.
On Mon, Feb 16, 2015 at 11:23 AM, James Green james.mk.gr...@gmail.com
wrote:
We have a puppet-master box with the following installed:
root@puppet-master:/var/log/puppetdb# dpkg -l | grep puppet
ii facter 2.4.1-1puppetlabs1 all
Ruby module for collecting simple facts about a host operating system
ii hiera1.3.4-1puppetlabs1 all
A simple pluggable Hierarchical Database.
ii puppet 3.7.4-1puppetlabs1 all
Centralized configuration management - agent startup and compatibility
scripts
ii puppet-common3.7.4-1puppetlabs1 all
Centralized configuration management
ii puppetdb 2.2.2-1puppetlabs1 all
PuppetDB Centralized Storage.
ii puppetdb-terminus2.2.2-1puppetlabs1 all
Connect Puppet to PuppetDB by setting up a terminus for PuppetDB.
ii puppetlabs-release 1.0-11 all
Package to install Puppet Labs gpg key and apt repo
ii puppetmaster-common 3.7.4-1puppetlabs1 all
Puppet master common scripts
ii puppetmaster-passenger 3.7.4-1puppetlabs1 all
Centralised configuration management - master setup to run under mod
passenger
Occasionally puppetdb is found to no longer be running. The end of the
log
says that it is replacing facts. Then syslog shows puppet-master is
unable
to replace-facts as the connection to puppet-db is refused. The start
of
the log when we boot it again states:
2015-02-16 10:34:28,202 INFO [p.t.s.w.jetty9-core] Removing buggy
security
provider SunPKCS11-NSS version 1.7
2015-02-16 10:34:28,537 INFO [p.t.s.w.jetty9-service] Initializing web
server.
2015-02-16 10:34:28,604 INFO [p.t.s.w.jetty9-service] Starting web
server.
2015-02-16 10:34:28,606 INFO [o.e.j.s.Server] jetty-9.1.z-SNAPSHOT
2015-02-16 10:34:28,638 INFO [o.e.j.s.ServerConnector] Started
ServerConnector@395ac93f{HTTP/1.1}{localhost:8080}
2015-02-16 10:34:28,732 INFO [o.e.j.s.ServerConnector] Started
ServerConnector@298d54c9{SSL-HTTP/1.1}{0.0.0.0:8081}
2015-02-16 10:34:28,787 INFO [c.p.p.c.services] PuppetDB version 2.2.2
2015-02-16 10:34:28,792 WARN [c.j.b.BoneCPConfig] JDBC username was not
set
in config!
2015-02-16 10:34:28,792 WARN [c.j.b.BoneCPConfig] JDBC password was not
set
in config!
2015-02-16 10:34:31,650 INFO [c.p.p.s.migrate] There are no pending
migrations
2015-02-16 10:34:31,650 WARN [c.p.p.s.migrate] Unable to install optimal
indexing
We are unable to create optimal indexes for your database.
For maximum index performance, we recommend using PostgreSQL 9.3 or
greater.
2015-02-16 10:34:31,654 INFO [c.p.p.c.services] Starting broker
2015-02-16 10:34:31,899 INFO [o.a.a.s.k.MessageDatabase] KahaDB is
version
4
2015-02-16 10:34:31,931 INFO [o.a.a.s.k.MessageDatabase] Recovering from
the journal ...
2015-02-16 10:34:31,931 INFO [o.a.a.s.k.MessageDatabase] Recovery
replayed
2 operations from the journal in 0.026 seconds.
2015-02-16 10:34:32,455 INFO [c.p.p.c.services] Starting 12 command
processor threads
2015-02-16 10:34:32,471 WARN [c.j.b.BoneCPConfig] JDBC username was not
set
in config!
2015-02-16 10:34:32,473 WARN [c.j.b.BoneCPConfig] JDBC password was not
set
in config!
2015-02-16 10:34:32,479 INFO [c.p.p.c.services] Starting query server
2015-02-16 10:34:32,496 WARN [o.e.j.s.h.ContextHandler] Empty
contextPath
2015-02-16 10:34:32,500 INFO [o.e.j.s.h.ContextHandler] Started
o.e.j.s.h.ContextHandler@41ec3132{/,null,AVAILABLE}
2015-02-16 10:34:32,515 INFO [c.p.p.c.services] Starting sweep of stale
reports (threshold: 14 days)
2015-02-16 10:34:32,530 INFO [c.p.p.c.services] Finished sweep of stale
reports (threshold: 14 days)
2015-02-16 10:34:32,531 INFO [c.p.p.c.services] Starting database
garbage
collection
2015-02-16 10:34:32,752 INFO [c.p.p.c.services] Finished database
garbage
collection
And then we're back to replacing facts again.
Any ideas where we should go from here?
Thanks,
James
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To unsubscribe from this group and stop
Re: [Puppet Users] puppetdb dies at random
16850 puppetdb 20 0 12.697g 418684 14848 S 0.9 0.4 4:32.74 java
That's top now since it began running around 10.30 this morning (GMT). 12G
of ram? It's the only proc in the list having a 'g' against it. Seems
excessive..?
On 16 February 2015 at 12:43, James Green james.mk.gr...@gmail.com wrote:
I have a 270MB puppetdb-oom.hprof.prev file in /var/log/puppetdb
Google reports this as http://projects.puppetlabs.com/issues/23237
however this page is a 500 Internal Server Error at present.
On 16 February 2015 at 12:13, Ken Barber k...@puppetlabs.com wrote:
It might be that PuppetDB is running out of heap? Check
/var/log/puppetdb for a file 'puppetdb-oom.hprof' for an indiciation
this is happening.
You can find instructions for how to adjust your heap space here:
https://docs.puppetlabs.com/puppetdb/2.2/configure.html#configuring-the-java-heap-size
ken.
On Mon, Feb 16, 2015 at 11:23 AM, James Green james.mk.gr...@gmail.com
wrote:
We have a puppet-master box with the following installed:
root@puppet-master:/var/log/puppetdb# dpkg -l | grep puppet
ii facter 2.4.1-1puppetlabs1
all
Ruby module for collecting simple facts about a host operating system
ii hiera1.3.4-1puppetlabs1
all
A simple pluggable Hierarchical Database.
ii puppet 3.7.4-1puppetlabs1
all
Centralized configuration management - agent startup and compatibility
scripts
ii puppet-common3.7.4-1puppetlabs1
all
Centralized configuration management
ii puppetdb 2.2.2-1puppetlabs1
all
PuppetDB Centralized Storage.
ii puppetdb-terminus2.2.2-1puppetlabs1
all
Connect Puppet to PuppetDB by setting up a terminus for PuppetDB.
ii puppetlabs-release 1.0-11
all
Package to install Puppet Labs gpg key and apt repo
ii puppetmaster-common 3.7.4-1puppetlabs1
all
Puppet master common scripts
ii puppetmaster-passenger 3.7.4-1puppetlabs1
all
Centralised configuration management - master setup to run under mod
passenger
Occasionally puppetdb is found to no longer be running. The end of the
log
says that it is replacing facts. Then syslog shows puppet-master is
unable
to replace-facts as the connection to puppet-db is refused. The start
of
the log when we boot it again states:
2015-02-16 10:34:28,202 INFO [p.t.s.w.jetty9-core] Removing buggy
security
provider SunPKCS11-NSS version 1.7
2015-02-16 10:34:28,537 INFO [p.t.s.w.jetty9-service] Initializing web
server.
2015-02-16 10:34:28,604 INFO [p.t.s.w.jetty9-service] Starting web
server.
2015-02-16 10:34:28,606 INFO [o.e.j.s.Server] jetty-9.1.z-SNAPSHOT
2015-02-16 10:34:28,638 INFO [o.e.j.s.ServerConnector] Started
ServerConnector@395ac93f{HTTP/1.1}{localhost:8080}
2015-02-16 10:34:28,732 INFO [o.e.j.s.ServerConnector] Started
ServerConnector@298d54c9{SSL-HTTP/1.1}{0.0.0.0:8081}
2015-02-16 10:34:28,787 INFO [c.p.p.c.services] PuppetDB version 2.2.2
2015-02-16 10:34:28,792 WARN [c.j.b.BoneCPConfig] JDBC username was
not set
in config!
2015-02-16 10:34:28,792 WARN [c.j.b.BoneCPConfig] JDBC password was
not set
in config!
2015-02-16 10:34:31,650 INFO [c.p.p.s.migrate] There are no pending
migrations
2015-02-16 10:34:31,650 WARN [c.p.p.s.migrate] Unable to install
optimal
indexing
We are unable to create optimal indexes for your database.
For maximum index performance, we recommend using PostgreSQL 9.3 or
greater.
2015-02-16 10:34:31,654 INFO [c.p.p.c.services] Starting broker
2015-02-16 10:34:31,899 INFO [o.a.a.s.k.MessageDatabase] KahaDB is
version
4
2015-02-16 10:34:31,931 INFO [o.a.a.s.k.MessageDatabase] Recovering
from
the journal ...
2015-02-16 10:34:31,931 INFO [o.a.a.s.k.MessageDatabase] Recovery
replayed
2 operations from the journal in 0.026 seconds.
2015-02-16 10:34:32,455 INFO [c.p.p.c.services] Starting 12 command
processor threads
2015-02-16 10:34:32,471 WARN [c.j.b.BoneCPConfig] JDBC username was
not set
in config!
2015-02-16 10:34:32,473 WARN [c.j.b.BoneCPConfig] JDBC password was
not set
in config!
2015-02-16 10:34:32,479 INFO [c.p.p.c.services] Starting query server
2015-02-16 10:34:32,496 WARN [o.e.j.s.h.ContextHandler] Empty
contextPath
2015-02-16 10:34:32,500 INFO [o.e.j.s.h.ContextHandler] Started
o.e.j.s.h.ContextHandler@41ec3132{/,null,AVAILABLE}
2015-02-16 10:34:32,515 INFO [c.p.p.c.services] Starting sweep of stale
reports (threshold: 14 days)
2015-02-16 10:34:32,530 INFO [c.p.p.c.services] Finished sweep of stale
reports (threshold: 14 days)
2015-02-16 10:34:32,531 INFO [c.p.p.c.services] Starting database
garbage
collection
2015-02-16 10:34:32,752 INFO [c.p.p.c.services] Finished database
garbage
collection
And then we're back to replacing facts again.
Any ideas where we
[Puppet Users] puppetdb dies at random
We have a puppet-master box with the following installed:
root@puppet-master:/var/log/puppetdb# dpkg -l | grep puppet
ii facter 2.4.1-1puppetlabs1 all
Ruby module for collecting simple facts about a host operating system
ii hiera1.3.4-1puppetlabs1 all
A simple pluggable Hierarchical Database.
ii puppet 3.7.4-1puppetlabs1 all
Centralized configuration management - agent startup and
compatibility scripts
ii puppet-common3.7.4-1puppetlabs1 all
Centralized configuration management
ii puppetdb 2.2.2-1puppetlabs1 all
PuppetDB Centralized Storage.
ii puppetdb-terminus2.2.2-1puppetlabs1 all
Connect Puppet to PuppetDB by setting up a terminus for PuppetDB.
ii puppetlabs-release 1.0-11 all
Package to install Puppet Labs gpg key and apt repo
ii puppetmaster-common 3.7.4-1puppetlabs1 all
Puppet master common scripts
ii puppetmaster-passenger 3.7.4-1puppetlabs1 all
Centralised configuration management - master setup to run under mod
passenger
Occasionally puppetdb is found to no longer be running. The end of the log
says that it is replacing facts. Then syslog shows puppet-master is unable
to replace-facts as the connection to puppet-db is refused. The start of
the log when we boot it again states:
2015-02-16 10:34:28,202 INFO [p.t.s.w.jetty9-core] Removing buggy security
provider SunPKCS11-NSS version 1.7
2015-02-16 10:34:28,537 INFO [p.t.s.w.jetty9-service] Initializing web
server.
2015-02-16 10:34:28,604 INFO [p.t.s.w.jetty9-service] Starting web server.
2015-02-16 10:34:28,606 INFO [o.e.j.s.Server] jetty-9.1.z-SNAPSHOT
2015-02-16 10:34:28,638 INFO [o.e.j.s.ServerConnector] Started
ServerConnector@395ac93f{HTTP/1.1}{localhost:8080}
2015-02-16 10:34:28,732 INFO [o.e.j.s.ServerConnector] Started
ServerConnector@298d54c9{SSL-HTTP/1.1}{0.0.0.0:8081}
2015-02-16 10:34:28,787 INFO [c.p.p.c.services] PuppetDB version 2.2.2
2015-02-16 10:34:28,792 WARN [c.j.b.BoneCPConfig] JDBC username was not
set in config!
2015-02-16 10:34:28,792 WARN [c.j.b.BoneCPConfig] JDBC password was not
set in config!
2015-02-16 10:34:31,650 INFO [c.p.p.s.migrate] There are no pending
migrations
2015-02-16 10:34:31,650 WARN [c.p.p.s.migrate] Unable to install optimal
indexing
We are unable to create optimal indexes for your database.
For maximum index performance, we recommend using PostgreSQL 9.3 or
greater.
2015-02-16 10:34:31,654 INFO [c.p.p.c.services] Starting broker
2015-02-16 10:34:31,899 INFO [o.a.a.s.k.MessageDatabase] KahaDB is version
4
2015-02-16 10:34:31,931 INFO [o.a.a.s.k.MessageDatabase] Recovering from
the journal ...
2015-02-16 10:34:31,931 INFO [o.a.a.s.k.MessageDatabase] Recovery replayed
2 operations from the journal in 0.026 seconds.
2015-02-16 10:34:32,455 INFO [c.p.p.c.services] Starting 12 command
processor threads
2015-02-16 10:34:32,471 WARN [c.j.b.BoneCPConfig] JDBC username was not
set in config!
2015-02-16 10:34:32,473 WARN [c.j.b.BoneCPConfig] JDBC password was not
set in config!
2015-02-16 10:34:32,479 INFO [c.p.p.c.services] Starting query server
2015-02-16 10:34:32,496 WARN [o.e.j.s.h.ContextHandler] Empty contextPath
2015-02-16 10:34:32,500 INFO [o.e.j.s.h.ContextHandler] Started
o.e.j.s.h.ContextHandler@41ec3132{/,null,AVAILABLE}
2015-02-16 10:34:32,515 INFO [c.p.p.c.services] Starting sweep of stale
reports (threshold: 14 days)
2015-02-16 10:34:32,530 INFO [c.p.p.c.services] Finished sweep of stale
reports (threshold: 14 days)
2015-02-16 10:34:32,531 INFO [c.p.p.c.services] Starting database garbage
collection
2015-02-16 10:34:32,752 INFO [c.p.p.c.services] Finished database garbage
collection
And then we're back to replacing facts again.
Any ideas where we should go from here?
Thanks,
James
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/CAMH6%2BazCSD-BPD%2ByAO1jV_36bExqhVJ98DBBPk3s3ex4iDVNvg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
[Puppet Users] augeas failure - any ideas?
augeas { 'postfix-master-smtp-inet' :
context = /files/etc/postfix/master.cf,
changes = [
set smtp[type = inet]/private n,
set smtp[type = inet]/unprivileged -,
set smtp[type = inet]/chroot n,
set smtp[type = inet]/wakeup -,
set smtp[type = inet]/limit 10,
'set smtp[type = inet]/command smtpd -o
content_filter=smtptorestgw:dummy',
],
require = Package['postfix'],
notify = Service['postfix'],
}
On the server:
Debug: Augeas[postfix-master-smtp-inet](provider=augeas): Opening augeas
with root /, lens path , flags 32
Debug: Augeas[postfix-master-smtp-inet](provider=augeas): Augeas version
1.2.0 is installed
Debug: Augeas[postfix-master-smtp-inet](provider=augeas): Will attempt to
save and only run if files changed
Debug: Augeas[postfix-master-smtp-inet](provider=augeas): sending command
'set' with params [/files/etc/postfix/master.cf/smtp[type =
inet]/private, n]
Debug: Augeas[postfix-master-smtp-inet](provider=augeas): sending command
'set' with params [/files/etc/postfix/master.cf/smtp[type =
inet]/unprivileged, -]
Debug: Augeas[postfix-master-smtp-inet](provider=augeas): sending command
'set' with params [/files/etc/postfix/master.cf/smtp[type = inet]/chroot,
n]
Debug: Augeas[postfix-master-smtp-inet](provider=augeas): sending command
'set' with params [/files/etc/postfix/master.cf/smtp[type = inet]/wakeup,
-]
Debug: Augeas[postfix-master-smtp-inet](provider=augeas): sending command
'set' with params [/files/etc/postfix/master.cf/smtp[type = inet]/limit,
10]
Debug: Augeas[postfix-master-smtp-inet](provider=augeas): sending command
'set' with params [/files/etc/postfix/master.cf/smtp[type =
inet]/command, smtpd -o content_filter=smtptorestgw:dummy]
Debug: Augeas[postfix-master-smtp-inet](provider=augeas): Put failed on one
or more files, output from /augeas//error:
Debug: Augeas[postfix-master-smtp-inet](provider=augeas):
/augeas/files/etc/postfix/master.cf/error = put_failed
Debug: Augeas[postfix-master-smtp-inet](provider=augeas):
/augeas/files/etc/postfix/master.cf/error/path = /files/etc/postfix/
master.cf/smtp
Debug: Augeas[postfix-master-smtp-inet](provider=augeas):
/augeas/files/etc/postfix/master.cf/error/lens =
/usr/share/augeas/lenses/dist/postfix_master.aug:39.18-47.21:
Debug: Augeas[postfix-master-smtp-inet](provider=augeas):
/augeas/files/etc/postfix/master.cf/error/message = Failed to match
{ /type/ = /inet|unix|fifo|pass/ }{ /private/ = /y|n|-/ }{
/unprivileged/ = /y|n|-/ }{ /chroot/ = /y|n|-/ }{ /wakeup/ =
/([0-9]+|-)\\??/ }{ /limit/ = /([0-9]+|-)\\??/ }{ /command/ =
/[!$,-.0-:=@-Z_a-{}]([!$,-.0-:=@-Z_a-{}]|[]\/[]|
)*([!$,-.0-:=@-Z_a-{}]|[]\/[])([\t ]*\n[\t
]+[!$,-.0-:=@-Z_a-{}]([!$,-.0-:=@-Z_a-{}]|[]\/[]|
)*([!$,-.0-:=@-Z_a-{}]|[]\/[]))*/ }
with tree
{ private = n }
Debug: Augeas[postfix-master-smtp-inet](provider=augeas): Closed the augeas
connection
Error: /Stage[main]/custom_postfix::Sasl/Augeas[postfix-master-smtp-inet]:
Could not evaluate: Saving failed, see debug
Any ideas?
Thanks,
James
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/CAMH6%2BayVPziXijP1A67rubah_iE-ryski6RF8Er3z4QfD2FR0w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: augeas failure - any ideas?
It's because the file doesn't yet have an uncommented smtp line. It seems
augeas cannot uncomment the line or put a new one in. I am therefore unsure
how augeas can be used to ensure the line exists.
Do people have to work around this by supplying template fragments or
something?
On 10 December 2014 at 14:59, James Green james.mk.gr...@gmail.com wrote:
augeas { 'postfix-master-smtp-inet' :
context = /files/etc/postfix/master.cf,
changes = [
set smtp[type = inet]/private n,
set smtp[type = inet]/unprivileged -,
set smtp[type = inet]/chroot n,
set smtp[type = inet]/wakeup -,
set smtp[type = inet]/limit 10,
'set smtp[type = inet]/command smtpd -o
content_filter=smtptorestgw:dummy',
],
require = Package['postfix'],
notify = Service['postfix'],
}
On the server:
Debug: Augeas[postfix-master-smtp-inet](provider=augeas): Opening augeas
with root /, lens path , flags 32
Debug: Augeas[postfix-master-smtp-inet](provider=augeas): Augeas version
1.2.0 is installed
Debug: Augeas[postfix-master-smtp-inet](provider=augeas): Will attempt to
save and only run if files changed
Debug: Augeas[postfix-master-smtp-inet](provider=augeas): sending command
'set' with params [/files/etc/postfix/master.cf/smtp[type
http://master.cf/smtp%5Btype = inet]/private, n]
Debug: Augeas[postfix-master-smtp-inet](provider=augeas): sending command
'set' with params [/files/etc/postfix/master.cf/smtp[type
http://master.cf/smtp%5Btype = inet]/unprivileged, -]
Debug: Augeas[postfix-master-smtp-inet](provider=augeas): sending command
'set' with params [/files/etc/postfix/master.cf/smtp[type
http://master.cf/smtp%5Btype = inet]/chroot, n]
Debug: Augeas[postfix-master-smtp-inet](provider=augeas): sending command
'set' with params [/files/etc/postfix/master.cf/smtp[type
http://master.cf/smtp%5Btype = inet]/wakeup, -]
Debug: Augeas[postfix-master-smtp-inet](provider=augeas): sending command
'set' with params [/files/etc/postfix/master.cf/smtp[type
http://master.cf/smtp%5Btype = inet]/limit, 10]
Debug: Augeas[postfix-master-smtp-inet](provider=augeas): sending command
'set' with params [/files/etc/postfix/master.cf/smtp[type
http://master.cf/smtp%5Btype = inet]/command, smtpd -o
content_filter=smtptorestgw:dummy]
Debug: Augeas[postfix-master-smtp-inet](provider=augeas): Put failed on
one or more files, output from /augeas//error:
Debug: Augeas[postfix-master-smtp-inet](provider=augeas):
/augeas/files/etc/postfix/master.cf/error = put_failed
Debug: Augeas[postfix-master-smtp-inet](provider=augeas):
/augeas/files/etc/postfix/master.cf/error/path = /files/etc/postfix/
master.cf/smtp
Debug: Augeas[postfix-master-smtp-inet](provider=augeas):
/augeas/files/etc/postfix/master.cf/error/lens =
/usr/share/augeas/lenses/dist/postfix_master.aug:39.18-47.21:
Debug: Augeas[postfix-master-smtp-inet](provider=augeas):
/augeas/files/etc/postfix/master.cf/error/message = Failed to match
{ /type/ = /inet|unix|fifo|pass/ }{ /private/ = /y|n|-/ }{
/unprivileged/ = /y|n|-/ }{ /chroot/ = /y|n|-/ }{ /wakeup/ =
/([0-9]+|-)\\??/ }{ /limit/ = /([0-9]+|-)\\??/ }{ /command/ =
/[!$,-.0-:=@-Z_a-{}]([!$,-.0-:=@-Z_a-{}]|[]\/[]|
)*([!$,-.0-:=@-Z_a-{}]|[]\/[])([\t ]*\n[\t
]+[!$,-.0-:=@-Z_a-{}]([!$,-.0-:=@-Z_a-{}]|[]\/[]|
)*([!$,-.0-:=@-Z_a-{}]|[]\/[]))*/ }
with tree
{ private = n }
Debug: Augeas[postfix-master-smtp-inet](provider=augeas): Closed the
augeas connection
Error: /Stage[main]/custom_postfix::Sasl/Augeas[postfix-master-smtp-inet]:
Could not evaluate: Saving failed, see debug
Any ideas?
Thanks,
James
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/CAMH6%2Bax4yT5VZc9FBOHiLkcprCN2PixRPDoAQrGr6gbUoS-tkg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
[Puppet Users] puppet.conf documentation ammendment
Could someone kindly add a notice bar to the puppet.conf web documentation stating that: *Changes to puppet.conf are picked up automatically by the puppet agent. You can observe this by making a change and tailing syslog for a few moments.* There are a few google results teaching us how to declare puppet as a service with a subscription to puppet.conf, which appears unnecessary given the above :) Thanks, James -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CAMH6%2Bax9T5BKt%2BCwuCWeG8tzcEDOX17YRStdDMrocyWzhN5GPQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: File server on linux - files with spaces are 404 on server
Upon further investigation, this is PUP-2700 getting us busted for any new instances. In our case the files are held on the puppet master but we're using passenger I'm told. So until 3.7 is out I guess we're completely reliant on existing instances..? On 26 June 2014 15:54, James Green james.mk.gr...@gmail.com wrote: I'm trying to finish off some work a colleague began which includes distribution of some files from the puppet master. I just fired up a new instance and watched as puppet agent -t came up with a whole lot of errors in ensuring certain files were present. Intrigued, it seems those with a space in the path are not found on the server: Error: Could not set 'file' on ensure: Error 404 on SERVER: Not Found: Could not find file_content svn/project/trunk/SQL/New%20Install/jquery.js Error: Could not set 'file' on ensure: Error 404 on SERVER: Not Found: Could not find file_content svn/project/trunk/SQL/New%20Install/jquery.js Wrapped exception: Error 404 on SERVER: Not Found: Could not find file_content svn/project/trunk/SQL/New%20Install/jquery.js On the server itself I can find the file, it's just listed within the New Install directory as you would expect. This is one of about a dozen or more all with spaces. Both master and client are Ubuntu. I'm struggling to see why those with spaces are failing. Any guidance would be appreciated. Thanks, James -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CAMH6%2Baz%2B4JynekYDrmnVfB%3Dr%2BcUgFFxgRKWdh1hDobrSY235QA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] File server on linux - files with spaces are 404 on server
I'm trying to finish off some work a colleague began which includes distribution of some files from the puppet master. I just fired up a new instance and watched as puppet agent -t came up with a whole lot of errors in ensuring certain files were present. Intrigued, it seems those with a space in the path are not found on the server: Error: Could not set 'file' on ensure: Error 404 on SERVER: Not Found: Could not find file_content svn/project/trunk/SQL/New%20Install/jquery.js Error: Could not set 'file' on ensure: Error 404 on SERVER: Not Found: Could not find file_content svn/project/trunk/SQL/New%20Install/jquery.js Wrapped exception: Error 404 on SERVER: Not Found: Could not find file_content svn/project/trunk/SQL/New%20Install/jquery.js On the server itself I can find the file, it's just listed within the New Install directory as you would expect. This is one of about a dozen or more all with spaces. Both master and client are Ubuntu. I'm struggling to see why those with spaces are failing. Any guidance would be appreciated. Thanks, James -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CAMH6%2BazUBQvB-SBmmME7ZoQOD6eQDaVvH1XLSv%3D%2BrPPHLbjPpg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
