[Puppet Users] Building puppet agent for ARM - looking for info on config settings

[JonY]

I have some belief that I've successfully assembled the various bits for 
'puppet-runtime' (v6.4). Now Im trying to build the puppet-agent (also 
v6.4).
  
At the end of the runtime build I have these 4 files:

-rw-r--r--  1 pocl root   514 Aug 11 12:53 
agent-runtime-6.4.x-201906190.debian-9-arm-bill-of-materials

-rw-r--r--  1 pocl root  2538 Aug 11 12:52 
agent-runtime-6.4.x-201906190.debian-9-arm.json

-rw-r--r--  1 pocl root  4752 Aug 11 12:53 
*agent-runtime-6.4.x-201906190.debian-9-arm.tar.gz*

-rw-r--r--  1 pocl root99 Aug 11 12:53 
agent-runtime-6.4.x-201906190.debian-9-arm.tar.gz.sha1

In the agent build files "puppet-agent.rb" appears to be looking for a file 
called "#{proj.settings[:puppet_runtime_basename]}.settings.yaml'  but I 
don't see any reference to this in the runtime Makefile. 
Im trying to work around this omission but am wondering what to use for 
these settings:  


  proj.setting(:puppet_configdir, File.join(proj.sysconfdir, 'puppet'))

  proj.setting(:puppet_codedir, File.join(proj.sysconfdir, 'code'))


  # Target directory for vendor modules

  proj.setting(:module_vendordir, File.join(proj.prefix, 'vendor_modules'))
  

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/7359e31b-6fbc-462c-a942-0daf63f56084%40googlegroups.com.

[Puppet Users] Collecting CPU load / usage facts

[JonY]

I'm wondering if puppet could be used to collect `sar` style data. Does 
such a module exist? Is this outside the intended use of facter?

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

[Puppet Users] Re: Using Ruby puppet db library - syntax question

[JonY]

On Friday, January 23, 2015 at 5:04:54 AM UTC-8, Nick Howes wrote:
>
> On Tuesday, 20 January 2015 20:00:14 UTC, JonY wrote:
>
> I'm hoping to use this library (or something similar) to request a single 
>> fact from all nodes. The equiv curl request would be 'curl -X GET 
>> http://host:8080/v3/facts --data-urlencode 
>> 'query=["=","name","fs_space"]'.
>>
>> I've been looking at the docs on '
>> https://github.com/puppetlabs/puppetdb-ruby' but I can't seem to get the 
>> syntax correct for this type of request. Suggestions?
>>
>
>
> It'll look like this:
>
> response = client.request(
>   'facts',
>   [:'=', 'name', 'fs_space']
> )
>
> nodes = response.data 
>
>
> The response data will be an array of hashes - each hash containing the 
> node's "certname" and the "name" and "value" of its fact.
>


Tried that - got this error:

/usr/local/lib/ruby/gems/2.1.0/gems/puppetdb-ruby-0.0.1/lib/puppetdb/client.rb:79:in
 
`raise_if_error': PuppetDB::APIError (PuppetDB::APIError)
from 
/usr/local/lib/ruby/gems/2.1.0/gems/puppetdb-ruby-0.0.1/lib/puppetdb/client.rb:101:in
 
`request'
from ./check.rb:8:in `'
 

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

[Puppet Users] Re: invoke-rc.d errors - what happened to this system?

[JonY]

Looking at the debug log it appears that puppet is calling 
'/etc/init.d/dnsmasq status' before this message appears.. but when I enter 
the same command subsequently I'm told ''running'. and nothing else.

Similar messages appear for puppet, ifplugd, apache2.. every service that I 
monitor with puppet. 

On Tuesday, January 20, 2015 at 12:19:12 PM UTC-8, JonY wrote:
>
> Debian 6 machine running 3.7.1. Attempts to run 'puppet agent --test' give 
> a stream of errors like this:
>
> invoke-rc.d: WARNING: 'invoke-rc.d dnsmasq start' called
> invoke-rc.d: during shutdown sequence.
> invoke-rc.d: enabling safe mode: initscript policy layer disabled.
>
>
> If I do a 'service dnsmasq start' after this it works ok with no error 
> messages. 
>
> 'runlevel' reports '3 6'.
>
> The system is apparently bolluxed somehow but I'm not sure what's wrong. 
> Where should I look?
>

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

[Puppet Users] invoke-rc.d errors - what happened to this system?

[JonY]

Debian 6 machine running 3.7.1. Attempts to run 'puppet agent --test' give 
a stream of errors like this:

invoke-rc.d: WARNING: 'invoke-rc.d dnsmasq start' called
invoke-rc.d: during shutdown sequence.
invoke-rc.d: enabling safe mode: initscript policy layer disabled.


If I do a 'service dnsmasq start' after this it works ok with no error 
messages. 

'runlevel' reports '3 6'.

The system is apparently bolluxed somehow but I'm not sure what's wrong. 
Where should I look?

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

[Puppet Users] Using Ruby puppet db library - syntax question

[JonY]

I'm hoping to use this library (or something similar) to request a single 
fact from all nodes. The equiv curl request would be 'curl -X GET 
http://host:8080/v3/facts --data-urlencode 'query=["=","name","fs_space"]'.

I've been looking at the docs on 
'https://github.com/puppetlabs/puppetdb-ruby' but I can't seem to get the 
syntax correct for this type of request. Suggestions?

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

[Puppet Users] Re: what gets run when a client can't connect?

[JonY]

Situation: client insists on ability to use a 3G modem to connect to AWS 
servers (including puppet). I need a way to ensure that the 'wvdial' 
process is running. It will lose the carrier and hang-up at times so I 
wrote a piece of bash that (re)starts it from puppet.. but you see the 
problem - if wvdial isn't running then the puppet agent will fail so the 
exec script won't get run.

Is there a way around this? Or do i need to use a cron to fix this?

On Tuesday, December 9, 2014 6:12:35 AM UTC-8, jcbollinger wrote:
>
>
>
> On Monday, December 8, 2014 9:57:39 AM UTC-6, JonY wrote:
>>
>> Anything? Some cached set? 
>>
>
> If the agent cannot retrieve a catalog from the master then it may apply a 
> cached version of the most recent one successfully retrieved.  I say "may" 
> because the behavior can be disabled (so that the agent does nothing unless 
> it successfully retrieves a fresh catalog).
>
>
> 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/8353fd91-c8fa-45b0-8d9c-2acf176a04be%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] what gets run when a client can't connect?

[JonY]

Anything? Some cached set? 

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

Re: [Puppet Users] How about an AMI?

[JonY]

> Its not for lack of packages...rather how they get installed that's the
> issue. The AMI is installing ruby 1.8 AND 2.0 when 'yum install
> puppet-server' runs. PS can't find its packages when it tries to run.

In any event I'll try a diff package and see if I get any further.

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

Re: [Puppet Users] master - error(s) on fresh installation (EC2)

[JonY]

Can't run 'facter' either.

$ cat /etc/os-release
NAME="Amazon Linux AMI"
VERSION="2014.09"
ID="amzn"
ID_LIKE="rhel fedora"
VERSION_ID="2014.09"
PRETTY_NAME="Amazon Linux AMI 2014.09"
ANSI_COLOR="0;33"
CPE_NAME="cpe:/o:amazon:linux:2014.09:ga"
HOME_URL="http://aws.amazon.com/amazon-linux-ami/";


In any event - you were right about it being a duplicate of an existing 
bug. 


On Friday, November 14, 2014 9:18:53 AM UTC-8, Kylo Ginsberg wrote:
>
> On Fri, Nov 14, 2014 at 6:03 AM, Kylo Ginsberg  > wrote:
>
>> On Fri, Nov 14, 2014 at 4:27 AM, JonY > 
>> wrote:
>>
>>> AMI? I'm new to this world.
>>>
>>
>> There are AMIs for many different OSs/distros.
>>
>> What does 'facter operatingsystem' report?
>>
>> Thanks
>> Kylo
>>  
>>
>>>
>>>
>>> On Thursday, November 13, 2014 2:42:31 PM UTC-8, Felix.Frank wrote:
>>>>
>>>> On 11/13/2014 08:00 PM, JonY wrote: 
>>>> > Installed latest from puppetlabs repro on an EC2 instance. 
>>>>
>>>> ...running...which platform? 
>>>>
>>>
> One guess, which I put in https://tickets.puppetlabs.com/browse/PUP-3672 
> as well, is that this is on Amazon Linux, for which we don't currently have 
> packages.
>
> Kylo 
>
>>  -- 
>>> You received this message because you are subscribed 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/fbf34adc-e317-415d-a3aa-01e11957ec57%40googlegroups.com
>>>  
>>> <https://groups.google.com/d/msgid/puppet-users/fbf34adc-e317-415d-a3aa-01e11957ec57%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> -- 
>> Kylo Ginsberg | ky...@puppetlabs.com  | irc: kylo | twitter: 
>> @kylog
>>
>> *Join us at **PuppetConf 2015, October 5-9 in Portland, OR - *
>> http://2015.puppetconf.com.  
>> *Register early to save 40%!*
>>  
>
>
>
> -- 
> Kylo Ginsberg | ky...@puppetlabs.com  | irc: kylo | twitter: 
> @kylog
>
> *Join us at **PuppetConf 2015, October 5-9 in Portland, OR - *
> http://2015.puppetconf.com.  
> *Register early to save 40%!*
>  

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

[Puppet Users] How about an AMI?

[JonY]

Since p-server 3.7 doesn't appear to work on the AWS linux AMI how about 
creating an AMI that does 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/7140583d-c518-426c-a4b0-372670aee69f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] master - error(s) on fresh installation (EC2)

[JonY]

AMI? I'm new to this world.

On Thursday, November 13, 2014 2:42:31 PM UTC-8, Felix.Frank wrote:
>
> On 11/13/2014 08:00 PM, JonY wrote: 
> > Installed latest from puppetlabs repro on an EC2 instance. 
>
> ...running...which platform? 
>

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

[Puppet Users] Re: master - error(s) on fresh installation (EC2)

[JonY]

Indeed. the line in question is 'require 'puppet/util/command_line''. This 
file gets installed into 

/usr/lib/ruby/site_ruby/1.8/puppet/util/command_line
/usr/lib/ruby/site_ruby/1.8/puppet/util/command_line.rb

so it's not found. I've scrubbed out all traces of ruby from this system 
and when I reinstall 'puppet-server' it brings down both ruby 1.8 and 2.0. 
The 'command_line.rb' file is put in 1.8 but the interpreter runs with 2.0.

On Thursday, November 13, 2014 11:00:01 AM UTC-8, JonY wrote:
>
> Installed latest from puppetlabs repro on an EC2 instance.
>
> Started working through steps from 
> https://docs.puppetlabs.com/guides/install_puppet/post_install.html
>
> # puppet master --verbose --no-daemonize
> /usr/share/ruby/vendor_ruby/2.0/rubygems/core_ext/kernel_require.rb:55:in 
> `require': cannot load such file -- puppet/util/command_line (LoadError)
> from 
> /usr/share/ruby/vendor_ruby/2.0/rubygems/core_ext/kernel_require.rb:55:in 
> `require'
> from /usr/bin/puppet:7:in `'
>
> What step(s) did I miss?
>
> ---
> I'm wondering if this is the problem:
>
> # ruby --version
> ruby 2.0.0p594 (2014-10-27 revision 48167) [x86_64-linux]
>
> This is the version that AWS installed by default.
>
>
>

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

[Puppet Users] master - error(s) on fresh installation (EC2)

[JonY]

Installed latest from puppetlabs repro on an EC2 instance.

Started working through steps 
from https://docs.puppetlabs.com/guides/install_puppet/post_install.html

# puppet master --verbose --no-daemonize
/usr/share/ruby/vendor_ruby/2.0/rubygems/core_ext/kernel_require.rb:55:in 
`require': cannot load such file -- puppet/util/command_line (LoadError)
from 
/usr/share/ruby/vendor_ruby/2.0/rubygems/core_ext/kernel_require.rb:55:in 
`require'
from /usr/bin/puppet:7:in `'

What step(s) did I miss?

---
I'm wondering if this is the problem:

# ruby --version
ruby 2.0.0p594 (2014-10-27 revision 48167) [x86_64-linux]

This is the version that AWS installed by default.


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

[Puppet Users] service control - what am I doing wrong?

[JonY]

I put together a module and some files to control cassandra. When I change 
one of the dependent files in my module the cassandra service is stopped 
but not restarted. 

The service uses a std start/stop/status file and 'status' sets the 
appropriate exit code:

[root@cass1 security]# service cassandra status
Cassandra is running.
[root@cass1 security]# echo $?
0
[root@cass1 security]# service cassandra stop
Stopping Cassandra:[  OK  ]
[root@cass1 security]# service cassandra status
Cassandra is stopped.
[root@cass1 security]# echo $?
1


Relevant line from module def:

User[ 'cassandra' ] -> Package[ 'nc' ] -> File[ '/etc/init.d/cassandra' ] 
-> File[ '/etc/security/limits.d/cassandra.conf' ] -> File[ 
'/etc/security/limits.d/90-nproc.conf' ] ~> Service[ 'cassandra' ]

All the various bits are declared in the module. 


What did I miss?

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

Re: [Puppet Users] Managing folder trees - best practice?

[JonY]

On Tuesday, November 11, 2014 11:12:37 PM UTC-8, Felix.Frank wrote:
>
> On 11/01/2014 01:46 PM, JonY wrote: 
> > 2. Maintain two (nearly identical - but not quite) file trees. It's 
> > all in git so maybe this isn't so bad. Looks messy though. Means 
> > having to sync nested trees and keep them straight. 
> > 3. Change the tree structure of what's being copied in and don't 
> > recurse. Name every sub folder in the 'file' resource according to 
> > which node get what. Neater than #2 but lots of extra work. 
> > 4. Create a 'merge' solution so I keep the current folder structure 
> > and only merge in the changes for the impacted nodes. 
>
> Hi, 
>
> are you aware that this works: 
>
> class base { 
> file { '/etc/foobar': recurse => true, source => ... } 
> } 
>
> class different { 
> file { '/etc/foobar/subdir/file': ensure => file, ... ; 
>'/etc/foobar/subtree': ensure => directory, ... 
> } 
> } 
>
> include base 
> include different 
>
> The files/directories underneath /tmp/foobar that are managed explicitly 
> (via class different) are exempt from recursion. This might allow you to 
> declare the exceptional case in a more sparse fashion. 
>
> HTH, 
> Felix 
>


That's what I've been using. Works well. TY. 

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

[Puppet Users] Managing folder trees - best practice?

[JonY]

Situation: systems come from imaging  with /var/tree full of (a hierarchy 
of) stuff that needs to be removed and replaced. I have a 'file/force => 
true/recurse => true' resource setup to accomplish this.. short and to the 
point...works great..replaces the folder hierarchy with a new one. 

Along comes an eager dev who says "I want to split this tree into two types 
- the difference between these being ~5% of the files." 

My choices for managing this tree seem to boil down to:

1. Berate the dev. Not v satisfying - like yelling at a puppy.
2. Maintain two (nearly identical - but not quite) file trees. It's all in 
git so maybe this isn't so bad. Looks messy though. Means having to sync 
nested trees and keep them straight.
3. Change the tree structure of what's being copied in and don't recurse. 
Name every sub folder in the 'file' resource according to which node get 
what. Neater than #2 but lots of extra work.
4. Create a 'merge' solution so I keep the current folder structure and 
only merge in the changes for the impacted nodes.

#1 - lots of unhappiness
#2 - seems prone to error
#3 - extra work. probably what will happen though.
#4 - seems like the most obvious but (AFAIK) it's not supported by puppet.

Is there something better? Another choice I've neglected?

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

Re: [Puppet Users] ENC - what does 'error 1' mean?

[JonY]

I've simplified the script to this:

#!/usr/local/bin/ruby

open('test.out', 'w') { |f|
  f.puts "Hello"
}


.. and it still gives me 'error 1' when run as an ENC. 

While it's true that the puppet server is using ruby 1.8.7 this shouldn't 
matter for the above code. 

What would the effect of outputting incorrect YAML be? I'm wondering about 
the syntax of what's being printed.




On Friday, October 31, 2014 2:44:18 AM UTC-7, Felix.Frank wrote:
>
> Well, obviously your script is throwing an error when invoked from 
> Puppet, behaving differently than from the command line. 
>
> This can have numerous reasons related to your process environment. 
> Perhaps the master is running with a different Ruby (PE?) 
>
> To debug this, add early debug logging to your ENC script and trace its 
> execution when Puppet calls it. If you fail to generate *any* log 
> output, this likely means that Ruby won't even start interpreting your 
> code. 
>
> HTH, 
> Felix 
>
> On 10/31/2014 02:20 AM, JonY wrote: 
> > Im recoding an ENC in ruby (from Perl). The new version gives me the 
> error: 
> > 
> > Oct 30 18:03:25 serv puppet-master[29051]: Failed when searching for 
> > node nodexx: Failed to find nodexx via exec: Execution of ' 
> > nodexx' returned 1: 
> > 
> > What I've checked: 
> > 
> > - both can be run under the 'puppet' account ("sudo -u puppet 
> > " ) 
> > - both return (seemingly) identical YAML 
> > - both are 'chmod puppet:puppet ' 
> > 
> > But only the perl works... what did I miss? 
>
>

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

[Puppet Users] ENC - what does 'error 1' mean?

[JonY]

Im recoding an ENC in ruby (from Perl). The new version gives me the error:

Oct 30 18:03:25 serv puppet-master[29051]: Failed when searching for node 
nodexx: Failed to find nodexx via exec: Execution of ' nodexx' 
returned 1:

What I've checked:

- both can be run under the 'puppet' account ("sudo -u puppet 
" )
- both return (seemingly) identical YAML
- both are 'chmod puppet:puppet '

But only the perl works... what did I miss?

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

[Puppet Users] Upgrading ruby to 2.1.x - paranoid question

[JonY]

Would like to upgrade Ruby to the latest. To make everything on my puppet 
server happy I need to remove the Ruby 1.8.7 that YUM installed. 

When I run 'yum erase ruby' it looks like it will also remove puppet, 
puppetdb, and so on. If I follow through with this:

- will a reinstall of puppet and puppetdb use the upgraded ruby?
- will they behave like they do now? (reasonably well)

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

[Puppet Users] Custom / nested resource types - crackpot ideas

[JonY]

Is it (reasonably) feasible to add new resource types? I don't want to 
disassemble the whole code base but if there is a known path to this I'd 
like to read about it.


Some thoughts:It strikes me that there are at a few situations that I run 
into with this SW that would make for decent additions. 

1. "once": do a given resource type once and set a fact to not repeat it. I 
keep kludging solutions to this. 
2. "log": set a log level and location for a resource / node / etc. This 
would help to figure out "WTF is going on".
3. "return value": set a fact with the failure code for a given operation 
or agent run. I keep finding cases where the agent is failing and the 
server isn't logging it. It isn't until I log in and run the agent that I 
see the error(s).
4. "counter": set a fact with the # of times a given operation has been 
performed on a system. This would help to track down systems that are 
thrashing because of competing operations.


These could either be additional params for existing resources or an outer 
layer to same.



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

Re: [Puppet Users] Re: ENC vs manifest - cage match

[JonY]

I have to use an ENC as there are DB calls to be made to determine which 
nodes get which SW.

AFAIU hiera can't do this.

On Wednesday, October 29, 2014 6:13:42 AM UTC-7, R.I. Pienaar wrote:
>
>
>
> - Original Message - 
> > From: "jcbollinger"  
> > To: "puppet-users" > 
> > Sent: Wednesday, October 29, 2014 1:09:04 PM 
> > Subject: [Puppet Users] Re: ENC vs manifest - cage match 
>
> > On Wednesday, October 29, 2014 5:44:41 AM UTC-5, JonY wrote: 
> >> 
> >> If we throw these two into the octagon.. who wins? If one says "add it" 
> >> and the other says "remove it".. what do I end up with? 
> >> 
> > 
> > Two techs enter, one tech leaves! 
> > 
> > Or not. 
> > 
> > I really can't agree with the premise that a winner between those two 
> can 
> > be declared in absolute terms, and in any case they are not mutually 
> > exclusive. 
> > 
> > Felix makes an excellent point that Hiera can serve many of the same 
> > purposes that an ENC can do.  When you throw in the possibility of 
> > providing a custom Hiera back end, I'm prepared to say that anything it 
> is 
> > possible to do with an ENC, it is also possible to do with Hiera + 
> > manifest.  Some things may be more *convenient* to do via the ENC 
>
> with the exception of setting the environment from the master side which 
> ENCs 
> can do and hiera cant 
>

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

[Puppet Users] ENC vs manifest - cage match

[JonY]

If we throw these two into the octagon.. who wins? If one says "add it" and 
the other says "remove it".. what do I end up with? 

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

[Puppet Users] Is it possible to merge two 'file' trees?

[JonY]

Situation: folder tree that gets installed via 'file' resource. In some 
circumstances I want to add files/ folders to this tree. 

Given that the tree is 100% puppet controlled if I add the extra files they 
will get booted out.. right? 

Is there some way to tell puppet to accept the extra bits (under some 
circumstances)?

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

Re: [Puppet Users] Re: Adding then removing SW - best practices?

[JonY]

I've been using 'anti-classes' up to now.. hoping for a better way.. alas...


On Monday, October 27, 2014 11:17:12 AM UTC-7, Trevor Vaughan wrote:
>
> One day, long ago in 2008, there was a discussion on anti-classes: 
> http://comments.gmane.org/gmane.comp.sysutils.puppet.user/5884.
>
> Yeah, they're still irritating, but I don't really know how else to do it.
>
> init.pp ( $enable => true ) ==> Main Class
> init.pp ( $enable => false ) ==> Anti Class
>
> Trevor
>
> On Mon, Oct 27, 2014 at 11:54 AM, Brian Morris  > wrote:
>
>> This could be done in a stateful fashion. Start with a facter like this:
>>
>> Facter.add(:apache_exists) do
>>>
>>> confine :osfamily => "Debian"
>>>
>>> setcode do
>>>
>>> if Facter::Util::Resolution.exec("dpkg -l | grep apache2 | grep -v 
>>>> apache2-utils | grep ^ii")
>>>
>>> "true"
>>>
>>> end
>>>
>>> end
>>>
>>> end
>>>
>>>
>> ... and then, in a manifest, reference the facter to see if it is true:
>>
>> if ( $::apache_exists ) {
>>>
>>> do something,
>>>
>>> }
>>>
>>>
>>
>> Brian 
>>  
>>
>> On Sunday, October 26, 2014 5:18:44 AM UTC-7, JonY wrote:
>>>
>>> Let's say that I'm deploying a steady stream of identical hosts. Each 
>>> has some piece of SW on it that's managed by Puppet.  I continue to 
>>> (regularly) add to and maintain this group over time.
>>>
>>> Day comes when this SW is no longer required. 
>>>
>>> So I remove the module from Puppet to prevent it being included on 
>>> future hosts in this group. 
>>>
>>> "What about the existing hosts?" I ask.
>>> "Add a module to remove the SW" I think.
>>> "What about the future hosts? Won't this seem a bit odd to tell puppet 
>>> to remove SW that was never installed?" I wonder.
>>> "Puppet is idempotent!" says the FM. 
>>> "Ok - but it still seems amiss. To a 'distant observer' it would seem an 
>>> odd practice." says I.
>>>
>>> Should I break up the 'before' and 'after' hosts into separate groups / 
>>> environments? I use an ENC to manage the modules. Maybe a DB entry to 
>>> indicate who gets the extra module?
>>>
>>> Some other pathway?
>>>
>>  -- 
>> You received this message because you are subscribed 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/825cb051-76b9-4353-8ee7-20c7b81d2896%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/puppet-users/825cb051-76b9-4353-8ee7-20c7b81d2896%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> Trevor Vaughan
> Vice President, Onyx Point, Inc
> (410) 541-6699
> tvau...@onyxpoint.com 
>
> -- This account not approved for unencrypted proprietary information -- 
>

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

Re: [Puppet Users] Adding then removing SW - best practices?

[JonY]

I get the rationale of an 'immutable system' but I don't have the privilege 
of replacing these. They are field-deployed in sensitive locations. 



On Sunday, October 26, 2014 6:11:56 PM UTC-7, Garrett Honeycutt wrote:
>
> On 10/26/14 5:18 AM, JonY wrote: 
> > Let's say that I'm deploying a steady stream of identical hosts. Each 
> > has some piece of SW on it that's managed by Puppet.  I continue to 
> > (regularly) add to and maintain this group over time. 
> > 
> > Day comes when this SW is no longer required. 
> > 
> > So I remove the module from Puppet to prevent it being included on 
> > future hosts in this group. 
> > 
> > "What about the existing hosts?" I ask. 
> > "Add a module to remove the SW" I think. 
> > "What about the future hosts? Won't this seem a bit odd to tell puppet 
> > to remove SW that was never installed?" I wonder. 
> > "Puppet is idempotent!" says the FM. 
> > "Ok - but it still seems amiss. To a 'distant observer' it would seem an 
> > odd practice." says I. 
> > 
> > Should I break up the 'before' and 'after' hosts into separate groups / 
> > environments? I use an ENC to manage the modules. Maybe a DB entry to 
> > indicate who gets the extra module? 
> > 
> > Some other pathway? 
> > 
> > -- 
> > You received this message because you are subscribed 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  
> > <mailto:puppet-users+unsubscr...@googlegroups.com >. 
> > To view this discussion on the web visit 
> > 
> https://groups.google.com/d/msgid/puppet-users/7cf584ad-b697-4904-8428-9750a1444a93%40googlegroups.com
>  
> > <
> https://groups.google.com/d/msgid/puppet-users/7cf584ad-b697-4904-8428-9750a1444a93%40googlegroups.com?utm_medium=email&utm_source=footer>.
>  
>
> > For more options, visit https://groups.google.com/d/optout. 
>
> Hi, 
>
> If you take the approach of immutable systems, you would just provision 
> new systems that do not have the software, transition to using them and 
> then remove the old systems altogether. 
>
> Getting into the practice of regularly rebuilding your hosts ensures 
> that your provisioning process + configuration management is actually 
> working. 
>
> 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/178b53dc-c603-41f2-98cb-5c8d06c36d49%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Adding then removing SW - best practices?

[JonY]

Let's say that I'm deploying a steady stream of identical hosts. Each has 
some piece of SW on it that's managed by Puppet.  I continue to (regularly) 
add to and maintain this group over time.

Day comes when this SW is no longer required. 

So I remove the module from Puppet to prevent it being included on future 
hosts in this group. 

"What about the existing hosts?" I ask.
"Add a module to remove the SW" I think.
"What about the future hosts? Won't this seem a bit odd to tell puppet to 
remove SW that was never installed?" I wonder.
"Puppet is idempotent!" says the FM. 
"Ok - but it still seems amiss. To a 'distant observer' it would seem an 
odd practice." says I.

Should I break up the 'before' and 'after' hosts into separate groups / 
environments? I use an ENC to manage the modules. Maybe a DB entry to 
indicate who gets the extra module?

Some other pathway?

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

[Puppet Users] command 'store report' version 2 is deprecated?

[JonY]

I recently changed over to a postgres back end. Now puppetdb.log seems to 
be awash in these errors.

I'm pretty sure everything is up to date:


# rpm -qa | grep puppet
puppetlabs-release-6-11.noarch
puppet-server-3.7.2-1.el6.noarch
puppetdb-2.2.2-1.el6.noarch
puppet-3.7.2-1.el6.noarch
puppetdb-terminus-2.2.2-1.el6.noarch
vim-puppet-2.7.20-1.el6.rf.noarch


Did I miss a step somewhere?



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

Re: [Puppet Users] puppetdb export - WTF?!

[JonY]

I pulled the plug on it after > 48 hours. The file is 14Mb at this point. 

I may start the Postgres server and try the export again. Perhaps if 
puppetdb isn't running this will be more efficient.

On Friday, October 10, 2014 6:13:04 PM UTC-7, Wyatt Alt wrote:
>
> Hey Jon, 
>
> Thanks for the update and the ticket: 
> https://tickets.puppetlabs.com/browse/PDB-947 
>
> We've been trying to reproduce this today and have had relatively 
> little luck. As you alluded earlier, it seems like a possible 
> contributor might be the number of reports per node.  Would you mind 
> giving us the sizes of your exported tarball and contained folders, as 
> well as the average number of reports per node? 
>
> I'm currently running a 200 node hsql export with 745 reports per node 
> (149k total), which is beyond the scale we would expect to be 
> performant on hsql, and at current pace it will still be done in seven 
> hours or so. 
>
> To the extent that you're still having trouble a stack dump may be 
> helpful in diagnosing the issue. 
>
> Thanks, 
> Wyatt 
>
>
> On Thu Oct  9 03:50:13 2014, JonY wrote: 
> > Update: 45 hours - ~75% complete 
> > 
> > On Tuesday, October 7, 2014 1:32:02 PM UTC-7, JonY wrote: 
> > 
> > Running for 7 hours now. Has exported ~15-20% of the data. 
> > 
> > I'm intrigued to see what I end up with. 
> > 
> > 
> > On Tuesday, October 7, 2014 1:19:04 PM UTC-7, Wyatt Alt wrote: 
> > 
> > Thanks Jony. 
> > 
> > I've loaded up an embedded database to comparable capacity and 
> > while export isn't quick, it's not nearly as slow as you're 
> > experiencing. 
> > 
> > Fro your process list the PDB appears to be running with a max 
> > heap size (Xmx) of 1024m.  Perhaps increasing this could make 
> > a difference? 
> > 
> >     The export process appears to be using 192m, but I think that 
> > should be using the same JAVA_ARGS as PuppetDB itself and so 
> > could be a bug. 
> > 
> > Wyatt 
> > 
> > 
> > On Tue, Oct 7, 2014 at 11:03 AM, JonY  
> wrote: 
> > 
> > https://gist.github.com/ce60c590a0531c0b09cd.git 
> > <https://gist.github.com/ce60c590a0531c0b09cd.git> 
> > 
> > 
> > # rpm -qa | grep puppet 
> > puppet-server-3.7.1-1.el6.noarch 
> > puppetlabs-release-6-11.noarch 
> > puppetdb-terminus-2.2.0-1.el6.noarch 
> > puppet-3.7.1-1.el6.noarch 
> > vim-puppet-2.7.20-1.el6.rf.noarch 
> > puppetdb-2.2.0-1.el6.noarch 
> > 
> > Am storing 30 days of data. Yes - it's a fair bit more 
> > then the default. 
> > 
> > 
> > 
> > 
> > On Tuesday, October 7, 2014 9:00:17 AM UTC-7, Wyatt Alt 
> wrote: 
> > 
> > Hey JonY, 
> > 
> > Sounds interesting.  What version of PuppetDB are you 
> > using?  Do you have reports, facts, and catalogs, or 
> > only some of those? Can you paste your config.ini? 
> > 
> > Also can you give the output of 
> > 
> > ps aux |grep java 
> > top -n1 
> > free 
> > 
> > in a gist maybe? 
> > 
> > Wyatt 
> > 
> > 
> > 
> > 
> > 
> > On Tue, Oct 7, 2014 at 8:30 AM, JonY 
> >  wrote: 
> > 
> > (ok - terrribly unprofessional title.. I get it). 
> > 
> > I'm trying to 'do the right thing' and move from 
> > the embedded DB to Postgres. Following the 
> > instructions I figured I would dump out the 
> > contents of the embedded DB and import this into 
> > Postgres. 
> > 
> > So I start 'puppetdb export --outfile '. 
> > 
> > Pour some coffee. 
> > 
> > Watch it dump one node. 
> > 
> > Have some more coffee. 
> > 
> > Wait. 
> > 
> > One more node. 
> > 
> > Hours pass. Glaciers melt. 
> > 
> > 3+ hours into the process and it has dumped 1

Re: [Puppet Users] puppetdb export - WTF?!

[JonY]

Update: 45 hours - ~75% complete

On Tuesday, October 7, 2014 1:32:02 PM UTC-7, JonY wrote:
>
> Running for 7 hours now. Has exported ~15-20% of the data.
>
> I'm intrigued to see what I end up with.
>
>
> On Tuesday, October 7, 2014 1:19:04 PM UTC-7, Wyatt Alt wrote:
>>
>> Thanks Jony.
>>
>> I've loaded up an embedded database to comparable capacity and while 
>> export isn't quick, it's not nearly as slow as you're experiencing.
>>
>> Fro your process list the PDB appears to be running with a max heap size 
>> (Xmx) of 1024m.  Perhaps increasing this could make a difference?
>>
>> The export process appears to be using 192m, but I think that should be 
>> using the same JAVA_ARGS as PuppetDB itself and so could be a bug.
>>
>> Wyatt
>>
>>
>> On Tue, Oct 7, 2014 at 11:03 AM, JonY  wrote:
>>
>>> https://gist.github.com/ce60c590a0531c0b09cd.git
>>>
>>>
>>> # rpm -qa | grep puppet
>>> puppet-server-3.7.1-1.el6.noarch
>>> puppetlabs-release-6-11.noarch
>>> puppetdb-terminus-2.2.0-1.el6.noarch
>>> puppet-3.7.1-1.el6.noarch
>>> vim-puppet-2.7.20-1.el6.rf.noarch
>>> puppetdb-2.2.0-1.el6.noarch
>>>
>>> Am storing 30 days of data. Yes - it's a fair bit more then the default.
>>>
>>>
>>>
>>>
>>> On Tuesday, October 7, 2014 9:00:17 AM UTC-7, Wyatt Alt wrote:
>>>>
>>>> Hey JonY,
>>>>
>>>> Sounds interesting.  What version of PuppetDB are you using?  Do you 
>>>> have reports, facts, and catalogs, or only some of those? Can you paste 
>>>> your config.ini?
>>>>
>>>> Also can you give the output of
>>>>
>>>> ps aux |grep java
>>>> top -n1
>>>> free
>>>>
>>>> in a gist maybe?
>>>>
>>>> Wyatt
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Tue, Oct 7, 2014 at 8:30 AM, JonY  wrote:
>>>>
>>>>> (ok - terrribly unprofessional title.. I get it).
>>>>>
>>>>> I'm trying to 'do the right thing' and move from the embedded DB to 
>>>>> Postgres. Following the instructions I figured I would dump out the 
>>>>> contents of the embedded DB and import this into Postgres.
>>>>>
>>>>> So I start 'puppetdb export --outfile '. 
>>>>>
>>>>> Pour some coffee.
>>>>>
>>>>> Watch it dump one node.
>>>>>
>>>>> Have some more coffee.
>>>>>
>>>>> Wait.
>>>>>
>>>>> One more node.
>>>>>
>>>>> Hours pass. Glaciers melt. 
>>>>>
>>>>> 3+ hours into the process and it has dumped 10 nodes (of > 100). At 
>>>>> this rate I'm looking at about 1.5 days to get this done. Really? 
>>>>>
>>>>> System has 16 cores, 32Gb of RAM.. barely running at idle. Tell me I 
>>>>> missed some critical parameter.
>>>>>
>>>>>
>>>>>  -- 
>>>>> You received this message because you are subscribed 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/1fbe251a-2c25-42ea-9529-d01bbf561980%
>>>>> 40googlegroups.com 
>>>>> <https://groups.google.com/d/msgid/puppet-users/1fbe251a-2c25-42ea-9529-d01bbf561980%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...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/puppet-users/9b735460-1722-48dc-9ad5-f34f554567f4%40googlegroups.com
>>>  
>>> <https://groups.google.com/d/msgid/puppet-users/9b735460-1722-48dc-9ad5-f34f554567f4%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/b0bd8590-0649-4188-a325-fe41168f96bc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] puppetdb export - WTF?!

[JonY]

Running for 7 hours now. Has exported ~15-20% of the data.

I'm intrigued to see what I end up with.


On Tuesday, October 7, 2014 1:19:04 PM UTC-7, Wyatt Alt wrote:
>
> Thanks Jony.
>
> I've loaded up an embedded database to comparable capacity and while 
> export isn't quick, it's not nearly as slow as you're experiencing.
>
> Fro your process list the PDB appears to be running with a max heap size 
> (Xmx) of 1024m.  Perhaps increasing this could make a difference?
>
> The export process appears to be using 192m, but I think that should be 
> using the same JAVA_ARGS as PuppetDB itself and so could be a bug.
>
> Wyatt
>
>
> On Tue, Oct 7, 2014 at 11:03 AM, JonY > 
> wrote:
>
>> https://gist.github.com/ce60c590a0531c0b09cd.git
>>
>>
>> # rpm -qa | grep puppet
>> puppet-server-3.7.1-1.el6.noarch
>> puppetlabs-release-6-11.noarch
>> puppetdb-terminus-2.2.0-1.el6.noarch
>> puppet-3.7.1-1.el6.noarch
>> vim-puppet-2.7.20-1.el6.rf.noarch
>> puppetdb-2.2.0-1.el6.noarch
>>
>> Am storing 30 days of data. Yes - it's a fair bit more then the default.
>>
>>
>>
>>
>> On Tuesday, October 7, 2014 9:00:17 AM UTC-7, Wyatt Alt wrote:
>>>
>>> Hey JonY,
>>>
>>> Sounds interesting.  What version of PuppetDB are you using?  Do you 
>>> have reports, facts, and catalogs, or only some of those? Can you paste 
>>> your config.ini?
>>>
>>> Also can you give the output of
>>>
>>> ps aux |grep java
>>> top -n1
>>> free
>>>
>>> in a gist maybe?
>>>
>>> Wyatt
>>>
>>>
>>>
>>>
>>>
>>> On Tue, Oct 7, 2014 at 8:30 AM, JonY  wrote:
>>>
>>>> (ok - terrribly unprofessional title.. I get it).
>>>>
>>>> I'm trying to 'do the right thing' and move from the embedded DB to 
>>>> Postgres. Following the instructions I figured I would dump out the 
>>>> contents of the embedded DB and import this into Postgres.
>>>>
>>>> So I start 'puppetdb export --outfile '. 
>>>>
>>>> Pour some coffee.
>>>>
>>>> Watch it dump one node.
>>>>
>>>> Have some more coffee.
>>>>
>>>> Wait.
>>>>
>>>> One more node.
>>>>
>>>> Hours pass. Glaciers melt. 
>>>>
>>>> 3+ hours into the process and it has dumped 10 nodes (of > 100). At 
>>>> this rate I'm looking at about 1.5 days to get this done. Really? 
>>>>
>>>> System has 16 cores, 32Gb of RAM.. barely running at idle. Tell me I 
>>>> missed some critical parameter.
>>>>
>>>>
>>>>  -- 
>>>> You received this message because you are subscribed 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/1fbe251a-2c25-42ea-9529-d01bbf561980%
>>>> 40googlegroups.com 
>>>> <https://groups.google.com/d/msgid/puppet-users/1fbe251a-2c25-42ea-9529-d01bbf561980%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...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/puppet-users/9b735460-1722-48dc-9ad5-f34f554567f4%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/puppet-users/9b735460-1722-48dc-9ad5-f34f554567f4%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/032a81c4-adc6-431e-91a8-2037a87e9d53%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] puppetdb export - WTF?!

[JonY]

https://gist.github.com/ce60c590a0531c0b09cd.git


# rpm -qa | grep puppet
puppet-server-3.7.1-1.el6.noarch
puppetlabs-release-6-11.noarch
puppetdb-terminus-2.2.0-1.el6.noarch
puppet-3.7.1-1.el6.noarch
vim-puppet-2.7.20-1.el6.rf.noarch
puppetdb-2.2.0-1.el6.noarch

Am storing 30 days of data. Yes - it's a fair bit more then the default.




On Tuesday, October 7, 2014 9:00:17 AM UTC-7, Wyatt Alt wrote:
>
> Hey JonY,
>
> Sounds interesting.  What version of PuppetDB are you using?  Do you have 
> reports, facts, and catalogs, or only some of those? Can you paste your 
> config.ini?
>
> Also can you give the output of
>
> ps aux |grep java
> top -n1
> free
>
> in a gist maybe?
>
> Wyatt
>
>
>
>
>
> On Tue, Oct 7, 2014 at 8:30 AM, JonY > 
> wrote:
>
>> (ok - terrribly unprofessional title.. I get it).
>>
>> I'm trying to 'do the right thing' and move from the embedded DB to 
>> Postgres. Following the instructions I figured I would dump out the 
>> contents of the embedded DB and import this into Postgres.
>>
>> So I start 'puppetdb export --outfile '. 
>>
>> Pour some coffee.
>>
>> Watch it dump one node.
>>
>> Have some more coffee.
>>
>> Wait.
>>
>> One more node.
>>
>> Hours pass. Glaciers melt. 
>>
>> 3+ hours into the process and it has dumped 10 nodes (of > 100). At this 
>> rate I'm looking at about 1.5 days to get this done. Really? 
>>
>> System has 16 cores, 32Gb of RAM.. barely running at idle. Tell me I 
>> missed some critical parameter.
>>
>>
>>  -- 
>> You received this message because you are subscribed 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/1fbe251a-2c25-42ea-9529-d01bbf561980%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/puppet-users/1fbe251a-2c25-42ea-9529-d01bbf561980%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/9b735460-1722-48dc-9ad5-f34f554567f4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] puppetdb export - WTF?!

[JonY]

(ok - terrribly unprofessional title.. I get it).

I'm trying to 'do the right thing' and move from the embedded DB to 
Postgres. Following the instructions I figured I would dump out the 
contents of the embedded DB and import this into Postgres.

So I start 'puppetdb export --outfile '. 

Pour some coffee.

Watch it dump one node.

Have some more coffee.

Wait.

One more node.

Hours pass. Glaciers melt. 

3+ hours into the process and it has dumped 10 nodes (of > 100). At this 
rate I'm looking at about 1.5 days to get this done. Really? 

System has 16 cores, 32Gb of RAM.. barely running at idle. Tell me I missed 
some critical parameter.


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

[Puppet Users] Restarting puppet agent after upgrade

[JonY]

I've been having problems (documented here) with upgrading my clients from 
p-ver 3.5.1 and facter 1.7.5 to 3.7 and 2.2 respectively. (TL;DR - the 
client gives a facter error with every run and is essentially wedged).

I filed a bug but was told "restarting the puppet service will clear up 
this error". Ok - that's great. But how? 

I tried adding this line to my puppet agent manifest (in the agent 
'service' definition): restart  => '/usr/bin/nohup /etc/init.d/puppet 
restart &'. My hope was that bouncing the client wouldn't interfere with 
the running of said client. No dice. 

Supposedly the client will restart if there is a change to the puppet.conf 
file - truth? Do I need to add some bogus values to prod the client into 
action?

Other suggestions?


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

[Puppet Users] Applying exec only 1x - Dell OMSA setup

[JonY]

My instructions for setting up the repo and such for Dell OpenManage start 
with this command "wget -q -O - 
http://linux.dell.com/repo/hardware/latest/bootstrap.cgi | bash". It turns 
out the .cgi file has some cumbersome logic in it to determine OS and so 
forth - more so than I want to implement in a module.

So my question is - what's the proper way to apply this exec only once? 
I've used the 'depend on changes to a dummy file' to limit execs in the 
past but this seems like a real kludge.

Similarly - what's a better way to run this command (or achieve the same 
end result)? 

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

[Puppet Users] puppetdb - how far back is it supposed to keep data?

[JonY]

Just wondering. I was messing about with some queries this morning. 

Asking for '/v3/reports --data-urlencode 
'query=["=","certname","client_name"]' only returned about 2 weeks worth of 
reports. This system has been up and running for 6-8 months. 

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

[Puppet Users] Re: Based way to exclude systems?

[JonY]

Use an ENC: https://docs.puppetlabs.com/guides/external_nodes.html

On Wednesday, September 24, 2014 10:13:00 AM UTC-7, Tom Tucker wrote:
>
>
> I would like to use a profile that would be applied against all Linux 
> based systems to ensure they have an appropriate /etc/ntp.conf based on 
> their data center location as defined by Hiera.  My question is how do I 
> deploy this client based ntp.conf to all Linux systems, but also ensure my 
> four Linux based NTP server feeding these clients continue to have unique 
> server based NTP configs?  
>
>  
>
> In other words….
>
> I have four data centers and 2000+ systems.  If you are a Linux system and 
> not marked as an NTP server then use this client ntp.conf.
>
>  
>
> What is the best way to achieve such?
>
>  
>
> Thanks 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/0b4ea1ad-85ef-454c-90c8-edad76b9efe2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: Custom facts and environments

[JonY]

>
> "For a given node, the pluginsync process will sync plugins, including 
> custom facts, from the modules in the modulepath of the environment to 
> which that node belongs."
>

So if my modulepath is /etc/puppet/modules - pluginsync will grab 
everything from 'lib' folders under that (IE /etc/puppet/modules/.../lib ) 
regardless of whether it is referenced for a given client? Seems a tad 
confusing as other elements from this path (other modules) aren't sent to a 
given client without appearing in the node classifier for that client.

On Wednesday, September 24, 2014 6:34:13 AM UTC-7, jcbollinger wrote:
>
>
>
> On Tuesday, September 23, 2014 7:30:40 AM UTC-5, JonY wrote:
>>
>> I'm attempting to make the jump to directory-based environments and am 
>> curious about what to do with custom facts.
>>
>> In my current config I've tried putting custom facts into a separate 
>> module as /etc/puppet/modules/facts/{manifest,lib} and 
>> /etc/puppet/modules/facts/lib/facter/. I haven't had any 
>> success in getting these to propagate to clients though. 
>>
>> I've added 'pluginsync=true' to puppet.conf on server/clients.
>>
>> Reading the various docs doesn't make it sound like I need a manifest for 
>> custom facts. Truth? How about a class file?
>>
>
>
> Correct, you do not need a manifest for custom facts.  Manifests are 
> instructions for constructing parts of nodes' catalogs.  They can use the 
> values of custom facts, but they are not involved in installing custom fact 
> implementations on clients.  That's what pluginsync is for.
>
> I don't know what you mean by a "class file", as distinguished from a 
> manifest.
>  
>
>>
>> Questions:
>>
>> 1. What step(s) did I miss in getting my facts to be distributed?
>> 2. When I split up my network into 'production', 'test', etc folders for 
>> use in environments - what happens to custom facts then?
>>
>
>
> Custom facts should be in modules.  Typically they are in the same module 
> as the classes that use them, but in principle, it should not be a problem 
> for them to appear in their own, separate module.  For a given node, the 
> pluginsync process will sync plugins, including custom facts, from the 
> modules in the modulepath of the environment to which that node belongs.  
> Therefore, if your facts are not getting distributed then a modulepath 
> issue is one of the things to consider.
>
> Also, running plain 'facter' on a client will compute and present only the 
> standard facts.  If you want also custom facts from Puppet then use 'facter 
> -p'.
>
>
> 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/163bf27d-edce-4fc8-97bb-660df2e4a4dd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[JonY]

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/ffc37ff8-b082-4a1a-a646-2c2ea8a897fc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: Custom facts and environments

[JonY]

Follow-up:

1. I used the directions from this post 
(https://groups.google.com/forum/#!topic/puppet-users/irSCu9SVoh4) 

   and the new 'fact' began to appear in /var/lib/puppet/lib/facter -- 
why?  an empty 'site.pp' file? is there some way to regulate which hosts 
get this?
   NOTE - I didn't add the 'factdir' line to 'puppet.conf' on the 
server. 

2. If I run 'facter' on a client I don't see my custom fact in the list.. 
but.. it's appearing on the server via puppetdb - why?

This seems to need some more documentation. It's a bit too random / 
mysterious.

On Wednesday, September 24, 2014 1:36:07 AM UTC-7, David LeVene wrote:
>
> In reply to myself... (as i'm really not an expert) our setup is actually 
> using module/lib/facter as noted here 
> https://docs.puppetlabs.com/guides/plugins_in_modules.html
>
> and below is an example of my test env, which works with facts.
>
> /etc/puppet/environments/production/modules/base/lib/facter/puppet_info.rb
> /etc/puppet/environments/staging/modules/base/lib/facter/puppet_info.rb
> /etc/puppet/environments/test/modules/base/lib/facter/puppet_info.rb
>
> As you can see i'm very much learning as I go as well.
>
> On Wednesday, 24 September 2014 17:58:08 UTC+9:30, David LeVene wrote:
>>
>> Hey JonY,
>>
>> Firstly, i'm not an expert but hopefully this assist you
>>
>> We are using the single dir config as we're currently running on an older 
>> version of puppet, but this link should give you the information you 
>> require. 
>> https://docs.puppetlabs.com/facter/2.0/custom_facts.html#fact-locations
>>
>> A snippet from the page above says..
>> The best way to distribute external facts is with pluginsync, which added 
>> support for them in Puppet 3.4 
>> <https://docs.puppetlabs.com/puppet/3/reference/release_notes.html#preparations-for-syncing-external-facts>
>> /Facter 2.0.1 
>> <https://docs.puppetlabs.com/facter/2.0/release_notes.html#pluginsync-for-external-facts>.
>>  
>> To add external facts to your puppet modules, just place them in
>> //facts.d/. 
>>
>> eg 
>> /etc/puppet/environments/production/modules//facts.d/.rb
>>
>> Each environment will use its own custom facts which is what you want so 
>> you can test a custom fact in the test env 
>> (/etc/puppet/environments/test/modules/base/lib/facter/) before you push to 
>> others etc.
>>
>> Having the custom fact present in this directory should deploy it on the 
>> servers (it does for me!)
>>
>> To answer your 2 questions directly;
>> 1. What step(s) did I miss in getting my facts to be distributed?
>>None from what I've seen - just your custom facts are in the wrong 
>> folder
>> 2. When I split up my network into 'production', 'test', etc folders for 
>> use in environments - what happens to custom facts then?
>>The facts are unique per environment
>>
>> Hope this helps
>>
>> Cheers
>> David
>>
>>
>>
>> On Tuesday, 23 September 2014 22:00:40 UTC+9:30, JonY wrote:
>>>
>>> I'm attempting to make the jump to directory-based environments and am 
>>> curious about what to do with custom facts.
>>>
>>> In my current config I've tried putting custom facts into a separate 
>>> module as /etc/puppet/modules/facts/{manifest,lib} and 
>>> /etc/puppet/modules/facts/lib/facter/. I haven't had any 
>>> success in getting these to propagate to clients though. 
>>>
>>> I've added 'pluginsync=true' to puppet.conf on server/clients.
>>>
>>> Reading the various docs doesn't make it sound like I need a manifest 
>>> for custom facts. Truth? How about a class file?
>>>
>>> Questions:
>>>
>>> 1. What step(s) did I miss in getting my facts to be distributed?
>>> 2. When I split up my network into 'production', 'test', etc folders for 
>>> use in environments - what happens to custom facts then?
>>>
>>

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

[Puppet Users] Custom facts and environments

[JonY]

I'm attempting to make the jump to directory-based environments and am 
curious about what to do with custom facts.

In my current config I've tried putting custom facts into a separate module 
as /etc/puppet/modules/facts/{manifest,lib} and 
/etc/puppet/modules/facts/lib/facter/. I haven't had any 
success in getting these to propagate to clients though. 

I've added 'pluginsync=true' to puppet.conf on server/clients.

Reading the various docs doesn't make it sound like I need a manifest for 
custom facts. Truth? How about a class file?

Questions:

1. What step(s) did I miss in getting my facts to be distributed?
2. When I split up my network into 'production', 'test', etc folders for 
use in environments - what happens to custom facts then?

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

Re: [Puppet Users] facter for debian: missing '_all.deb' version

[JonY]

FWIW:  I repackaged facter 1.7.5 as a "_all" and it installs on my ARM 
systems. I can upgrade to puppet/common 3.5.1 now. 



On Monday, April 28, 2014 3:39:21 PM UTC-7, JonY wrote:
>
> In the past I've worked around this by creating a stub version of 
> dmidecode. facter is happy.
>
> On Monday, April 28, 2014 11:59:52 AM UTC-7, Matthaus Litteken wrote:
>>
>> This issue is being tracked at 
>> https://tickets.puppetlabs.com/browse/CPR-5. The core of the problem 
>> is that facter is not an all arch package. It depends on dmidecode, 
>> which is not available for all architectures. Because of this, facter 
>> is an arch dependent package and there is no all package for it. There 
>> is more detail in the linked ticket. 
>>
>> HTH 
>>
>> On Mon, Apr 28, 2014 at 7:52 AM, JonY  wrote: 
>> > To the build-czars at puppet labs: could you please include a 
>> "*_all.deb" 
>> > version of facter in your build cycle? It doesn't appear to have been 
>> > created since v 1.6.18. 
>> > 
>> > My clients are almost exclusively ARM based and can't upgrade without 
>> this 
>> > being available. 
>> > 
>> > Humbly yours, 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...@googlegroups.com. 
>> > To view this discussion on the web visit 
>> > 
>> https://groups.google.com/d/msgid/puppet-users/d01e58d1-70a1-47ae-b802-d49473d2d5b0%40googlegroups.com.
>>  
>>
>> > For more options, visit https://groups.google.com/d/optout. 
>>
>>
>>
>> -- 
>> Matthaus Owens 
>> Puppet Labs 
>>
>> Join us at PuppetConf 2014, September 22-24 in San Francisco 
>> Register by May 30th to take advantage of the Early Adopter discount 
>> —save $349! 
>>
>

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

Re: [Puppet Users] facter for debian: missing '_all.deb' version

[JonY]

In the past I've worked around this by creating a stub version of 
dmidecode. facter is happy.

On Monday, April 28, 2014 11:59:52 AM UTC-7, Matthaus Litteken wrote:
>
> This issue is being tracked at 
> https://tickets.puppetlabs.com/browse/CPR-5. The core of the problem 
> is that facter is not an all arch package. It depends on dmidecode, 
> which is not available for all architectures. Because of this, facter 
> is an arch dependent package and there is no all package for it. There 
> is more detail in the linked ticket. 
>
> HTH 
>
> On Mon, Apr 28, 2014 at 7:52 AM, JonY > 
> wrote: 
> > To the build-czars at puppet labs: could you please include a 
> "*_all.deb" 
> > version of facter in your build cycle? It doesn't appear to have been 
> > created since v 1.6.18. 
> > 
> > My clients are almost exclusively ARM based and can't upgrade without 
> this 
> > being available. 
> > 
> > Humbly yours, 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...@googlegroups.com . 
> > To view this discussion on the web visit 
> > 
> https://groups.google.com/d/msgid/puppet-users/d01e58d1-70a1-47ae-b802-d49473d2d5b0%40googlegroups.com.
>  
>
> > For more options, visit https://groups.google.com/d/optout. 
>
>
>
> -- 
> Matthaus Owens 
> Puppet Labs 
>
> Join us at PuppetConf 2014, September 22-24 in San Francisco 
> Register by May 30th to take advantage of the Early Adopter discount —save 
> $349! 
>

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

[Puppet Users] facter for debian: missing '_all.deb' version

[JonY]

To the build-czars at puppet labs: could you please include a "*_all.deb" 
version of facter in your build cycle? It doesn't appear to have been 
created since v 1.6.18. 

My clients are almost exclusively ARM based and can't upgrade without this 
being available.

Humbly yours, 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/d01e58d1-70a1-47ae-b802-d49473d2d5b0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: PuppetDB is crashing - db constraint issue

[JonY]

On Saturday, April 26, 2014 11:05:50 AM UTC-7, JonY wrote:
>
> I think I'm past that version already:
>
> # rpm -qa | grep puppet
> puppetdb-1.6.3-1.el6.noarch
> puppet-3.5.1-1.el6.noarch
> puppet-server-3.5.1-1.el6.noarch
> vim-puppet-2.7.20-1.el6.rf.noarch
> puppetlabs-release-6-10.noarch
> puppetdb-terminus-1.6.3-1.el6.noarch
>
>
>>
NOTE: I'm not using postgresql either. Still under 100 clients... 

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

Re: [Puppet Users] Re: PuppetDB is crashing - db constraint issue

[JonY]

I think I'm past that version already:

# rpm -qa | grep puppet
puppetdb-1.6.3-1.el6.noarch
puppet-3.5.1-1.el6.noarch
puppet-server-3.5.1-1.el6.noarch
vim-puppet-2.7.20-1.el6.rf.noarch
puppetlabs-release-6-10.noarch
puppetdb-terminus-1.6.3-1.el6.noarch


On Saturday, April 26, 2014 7:44:43 AM UTC-7, Ken Barber wrote:
>
> Sorry, the URL for the Puppet bug is really here: 
> https://tickets.puppetlabs.com/browse/PUP-1524 
>
> On Sat, Apr 26, 2014 at 3:44 PM, Ken Barber 
> > 
> wrote: 
> > It sounds like this Puppet bug: 
> https://tickets.puppetlabs.com/browse/PDB-349 
> > 
> > You can usually solve this by upgrading to Puppet 3.4.3. 
> > 
> > ken. 
> > 
> > On Sat, Apr 26, 2014 at 3:39 PM, JonY > 
> wrote: 
> >> FWIW: I tried to remove all the db files and restart in hopes of 
> removing 
> >> the constraint issue. It immediately came back so I'm assuming that 
> this is 
> >> a bug in the version of puppetdb I have installed (1.6.3.1) 
> >> 
> >> 
> >> On Saturday, April 26, 2014 6:03:22 AM UTC-7, JonY wrote: 
> >>> 
> >>> It seems that puppetdb has run itself into a corner. It starts (albeit 
> >>> briefly) and then stops soon afterwards with this error: 
> >>> 
> >>> 2014-04-25 20:38:30,242 ERROR [command-proc-65] [puppetdb.command] 
> >>> [6c141db1-eeac-4c3f-be08-d03e5f445a19] [store report] Retrying after 
> attempt 
> >>> 13, due to: java.sql.SQLIntegrityConstraintViolationException: 
> integrity 
> >>> constraint violation: unique constraint or index violation; 
> >>> CONSTRAINT_RESOURCE_EVENTS_UNIQUE table: RESOURCE_EVENTS 
> >>> java.sql.SQLIntegrityConstraintViolationException: integrity 
> constraint 
> >>> violation: unique constraint or index violation; 
> >>> CONSTRAINT_RESOURCE_EVENTS_UNIQUE table: RESOURCE_EVENTS 
> >>> at org.hsqldb.jdbc.Util.sqlException(Unknown Source) 
> >>> at org.hsqldb.jdbc.Util.sqlException(Unknown Source) 
> >>> at org.hsqldb.jdbc.JDBCPreparedStatement.fetchResult(Unknown 
> >>> Source) 
> >>> at org.hsqldb.jdbc.JDBCPreparedStatement.executeUpdate(Unknown 
> >>> Source) 
> >>> 
> >>> .. lots more stack after that. 
> >>> 
> >>> 
> >>> How do I go about cleaning this up? All of my agent processes are 
> frozen. 
> >>> 
> >> -- 
> >> You received this message because you are subscribed 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/053ee518-b48f-44bb-b0e8-f68a09092fd7%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/8fb6f967-8d30-479b-a86d-47c1b01ad55b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: PuppetDB is crashing - db constraint issue

[JonY]

FWIW: I tried to remove all the db files and restart in hopes of removing 
the constraint issue. It immediately came back so I'm assuming that this is 
a bug in the version of puppetdb I have installed (1.6.3.1)

On Saturday, April 26, 2014 6:03:22 AM UTC-7, JonY wrote:
>
> It seems that puppetdb has run itself into a corner. It starts (albeit 
> briefly) and then stops soon afterwards with this error:
>
> 2014-04-25 20:38:30,242 ERROR [command-proc-65] [puppetdb.command] 
> [6c141db1-eeac-4c3f-be08-d03e5f445a19] [store report] Retrying after 
> attempt 13, due to: java.sql.SQLIntegrityConstraintViolationException: 
> integrity constraint violation: unique constraint or index violation; 
> CONSTRAINT_RESOURCE_EVENTS_UNIQUE table: RESOURCE_EVENTS
> java.sql.SQLIntegrityConstraintViolationException: integrity constraint 
> violation: unique constraint or index violation; 
> CONSTRAINT_RESOURCE_EVENTS_UNIQUE table: RESOURCE_EVENTS
> at org.hsqldb.jdbc.Util.sqlException(Unknown Source)
> at org.hsqldb.jdbc.Util.sqlException(Unknown Source)
> at org.hsqldb.jdbc.JDBCPreparedStatement.fetchResult(Unknown 
> Source)
> at org.hsqldb.jdbc.JDBCPreparedStatement.executeUpdate(Unknown 
> Source)
>
> .. lots more stack after that.
>
>
> How do I go about cleaning this up? All of my agent processes are frozen.
>
>

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

[Puppet Users] PuppetDB is crashing - db constraint issue

[JonY]

It seems that puppetdb has run itself into a corner. It starts (albeit 
briefly) and then stops soon afterwards with this error:

2014-04-25 20:38:30,242 ERROR [command-proc-65] [puppetdb.command] 
[6c141db1-eeac-4c3f-be08-d03e5f445a19] [store report] Retrying after 
attempt 13, due to: java.sql.SQLIntegrityConstraintViolationException: 
integrity constraint violation: unique constraint or index violation; 
CONSTRAINT_RESOURCE_EVENTS_UNIQUE table: RESOURCE_EVENTS
java.sql.SQLIntegrityConstraintViolationException: integrity constraint 
violation: unique constraint or index violation; 
CONSTRAINT_RESOURCE_EVENTS_UNIQUE table: RESOURCE_EVENTS
at org.hsqldb.jdbc.Util.sqlException(Unknown Source)
at org.hsqldb.jdbc.Util.sqlException(Unknown Source)
at org.hsqldb.jdbc.JDBCPreparedStatement.fetchResult(Unknown Source)
at org.hsqldb.jdbc.JDBCPreparedStatement.executeUpdate(Unknown 
Source)

.. lots more stack after that.


How do I go about cleaning this up? All of my agent processes are frozen.

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

Re: [Puppet Users] Re: Getting latest agent on debian for ARM?

[JonY]

Ah nice! I did the same on the dream plug. It's the same chip.



On Tuesday, April 8, 2014 5:07:52 AM UTC-7, Dirk Heinrichs wrote:
>
>  Am 08.04.2014 12:29, schrieb JonY:
>  
> Not sure. The devices are fanless PCs called 'dream plugs'. How would I 
> determine the chip id?
>
>
> I've got a Guruplug, which is the predecessor. It's armv5tel, running on 
> Marvel Feroceon CPU.
>
> % cat /proc/cpuinfo
> processor   : 0
> model name  : Feroceon 88FR131 rev 1 (v5l)
> Features: swp half thumb fastmult edsp
> CPU implementer : 0x56
> CPU architecture: 5TE
> CPU variant : 0x2
> CPU part: 0x131
> CPU revision: 1
>
> Hardware: Marvell Kirkwood (Flattened Device Tree)
> Revision: 
> Serial  : 
>
> % uname -a
> Linux rohan 3.13-1-kirkwood #1 Debian 3.13.7-1 (2014-03-25) armv5tel 
> GNU/Linux
>
> HTH...
>
> Dirk
> -- 
>
> *Dirk Heinrichs*, Senior Systems Engineer, Engineering Solutions
> *Recommind GmbH*, Von-Liebig-Straße 1, 53359 Rheinbach
> *Tel*: +49 2226 159 (Ansage) 1149
> *Email*: d...@recommind.com 
> *Skype*: dirk.heinrichs.recommind
> www.recommind.com
>  

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

Re: [Puppet Users] Re: Getting latest agent on debian for ARM?

[JonY]

Not sure. The devices are fanless PCs called 'dream plugs'. How would I 
determine the chip id?

On Monday, April 7, 2014 10:40:11 PM UTC-7, Ashutosh Parida wrote:
>
>
> Hey Jon,
>
> I am also planning to deploy puppet on ARM and am glad to see you tried 
> and may be you fixed issues with it.
> I dropped a mail to Puppetlabs, seeking information as to what is their 
> roadmap for supporting puppet on ARMv7 and later releases and puppetlabs 
> replied back saying currently they don't have any plans.
>
> Can you please tell which ARM platform you made it working ?
>
> Thanks,
> Ashutosh
>
>
> On Saturday, December 14, 2013 12:45:26 AM UTC+5:30, JonY wrote:
>>
>> Answer here: 
>> http://stackoverflow.com/questions/14607385/puppet-does-not-start-a-service-varnish-when-puppet-apply-is-run
>>
>>
>>
>> On Friday, December 13, 2013 11:07:01 AM UTC-8, Jon Yeargers wrote:
>>>
>>> Just out of curiosity I created my own 'dmidecode' package with a 
>>> trivial (does nothing) dmidecode executable. Once this was installed the 
>>> rest of puppet v 3.3.2 installed fine.
>>>
>>> NOW: it's having trouble accepting that certain services are already 
>>> running and it's trying to restart them every time. Strangely enough it 
>>> doesn't happen with 'system' services (EG apache2, snmpd) but only with my 
>>> code. I can't imagine this is related to my fake dmidecode but I'll keep 
>>> looking into it.
>>>
>>> On Friday, December 13, 2013 4:08:10 AM UTC-8, Felix.Frank wrote:
>>>>
>>>> Ideally, there will be a newly released facter package that replaces 
>>>> this dependency by a suggestion or recommendation. It will Just Work 
>>>> for 
>>>> you then. 
>>>>
>>>> In the meantime, these are your options: 
>>>> a) fetch the facter source package and build a forked package without 
>>>> this dependency 
>>>> b) fetch all deb packages you require and install them in one go using 
>>>> dpkg -i --force-depends or similar. 
>>>>
>>>> Option (a) is simple if you're versed in the creation of Debian 
>>>> packages, and pretty difficult if you're not. 
>>>>
>>>> HTH, 
>>>> Felix 
>>>>
>>>> On 12/13/2013 12:39 PM, Jon Yeargers wrote: 
>>>> > So am I SOL on this? Is ARM considered an 'unsupported architecture' 
>>>> > until I can create a 'dmidecode' for this platform? 
>>>>
>>>

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

[Puppet Users] Re: possible bug: slow server connection causes clients to hang

[JonY]

Turns out to be a denial of service on a machine in the same subnet. 
Machine in question has been sequestered. 

All of my puppet clients are hung. Fortunately there are only a few dozen 
as I'm having to touch each one, stop the puppet service, kill the hung 
process and rerun manually. 

On Monday, March 17, 2014 8:43:54 AM UTC-7, JonY wrote:
>
> Over the weekend there were some intermittent outages at our data center. 
> The puppet server would let clients connect but they would eventually time 
> out. 
>
> Unf this timeout wasn't handled gracefully and the clients would hang. 
> Doing a 'ps -ax | grep puppet' would show the service and the 'puppet 
> agent: applying configuration'. No activity available in the message log 
> for many hours though which indicated an unhappiness.
>
> If I killed the process and did 'puppet agent --test --debug' I could see 
> it get to where it tried to download the configuration. Doing this 
> interactively it would exit properly. If I restarted the service it would 
> stop and hang there.
>
> Server: CentOS 6.4 (x64). 
> puppet 3.4.0
> apache 2 / Passenger
>
> Clients: Debian 6.x 
> puppet 3.4.0
>

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

[Puppet Users] possible bug: slow server connection causes clients to hang

[JonY]

Over the weekend there were some intermittent outages at our data center. 
The puppet server would let clients connect but they would eventually time 
out. 

Unf this timeout wasn't handled gracefully and the clients would hang. 
Doing a 'ps -ax | grep puppet' would show the service and the 'puppet 
agent: applying configuration'. No activity available in the message log 
for many hours though which indicated an unhappiness.

If I killed the process and did 'puppet agent --test --debug' I could see 
it get to where it tried to download the configuration. Doing this 
interactively it would exit properly. If I restarted the service it would 
stop and hang there.

Server: CentOS 6.4 (x64). 
puppet 3.4.0
apache 2 / Passenger

Clients: Debian 6.x 
puppet 3.4.0

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

[Puppet Users] Possible issue with nagios_* commands

[JonY]

I'm trying to setup a nagios server via puppet to monitor the other servers 
in the group. I can get the various stored info from puppet db but when the 
*.cfg files are created in the nagios folder they are all root:root 0600. 

IE nagios can't read them.

I can work around this but I'm wondering if there is some config that I've 
missed.

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

[Puppet Users] Re: Host is missing hostname and/or domain

[JonY]

On Monday, February 24, 2014 7:17:28 AM UTC-8, jcbollinger wrote:
>
>
>
> On Friday, February 21, 2014 10:50:20 AM UTC-6, JonY wrote:
>>
>> I have 36 (seemingly) identical machines deployed from a single manifest.
>>
>
>
> Puppet does not do deployment, only post-deployment configuration.  I 
> raise that here because I think it likely that the problem likely boils 
> down to a deployment issue.
>
>  
>
>> For some reason I'm getting this error in my logs for a subset of them. 
>>
>> /etc/hosts:
>>
>> 127.0.0.1 hostname hostname.fqdn localhost
>>
>>
>
> Maybe nowhere else.  That hosts entry is bogus on at least two grounds:
>
>1. You should not be pointing the host's primary name at a loopback 
>address.  If you list it in /etc/hosts at all, it should be pointed at the 
>IP address assigned to the host's primary network interface.
>2. The canonical name field of each entry (the second) should hold the 
>fqdn.  The unqualifed name, if listed, should be among the aliases 
>(subsequent fields).
>
> Example:
>
> 192.168.0.42 host.mydomain.com host 
> 127.0.0.1localhost.localdomain localhost
>
> Traditionally, the host's own name needed to be first in /etc/hosts, as 
> that was how machines determined their own names.  That might still be the 
> case for some UNIX flavors, but I don't think it's common any longer.  It 
> doesn't work well for machines with dynamic IPs, so many systems use an 
> alternative means to record a machine's hostname.  On RedHat-family 
> Linuxes, at least, that's the 'HOSTNAME' entry in file 
> /etc/sysconfig/network.  Machines that employ such a mechanism do not 
> normally require a machine's own hostname to be listed in /etc/hosts at all.
>
> It may be illuminating to run the 'dnsdomainname' command on one of the 
> affected machines.  If it does not give the correct fully-qualified name 
> for the machine, then the machine is configured wrongly.  Such an error is 
> an initial provisioning / deployment problem.  You should assign the 
> machine its name before first firing up the Puppet agent on it.
>
>
> John
>
>

I think I found the problem. On the systems that have this error the 
/etc/resolv.conf file is missing the 'domain ' line. It's getting 
wiped out / replaced by DHCP at boot time. 

If I add the appropriate line back in the error goes away. I'll add a 
template file to puppet to maintain this add see what happens.

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

[Puppet Users] Re: Getting rid of YAML?

[JonY]

On Monday, February 24, 2014 7:21:28 AM UTC-8, jcbollinger wrote:
>
>
>
> On Friday, February 21, 2014 10:19:10 AM UTC-6, JonY wrote:
>>
>>
>> On Friday, February 21, 2014 8:10:23 AM UTC-8, jcbollinger wrote:
>>>
>>>
>>>
>>> On Thursday, February 20, 2014 4:41:33 PM UTC-6, JonY wrote:
>>>>
>>>> Looks like my server updated to 3.4.2.  Since then I've started seeing 
>>>> these occasional messages like:
>>>>
>>>> Feb 20 14:19:05 puppet-master[5626]: YAML in network requests is 
>>>> deprecated and will be removed in a future version. See 
>>>> http://links.puppetlabs.com/deprecate_yaml_on_network
>>>> Feb 20 14:19:05 puppet-master[5626]:(at 
>>>> /usr/lib/ruby/site_ruby/1.8/puppet/network/http/handler.rb:304:in 
>>>> `decode_params')
>>>>
>>>> Does this mean I'll be able to start using JSON or XML in my ENC 
>>>> scripts? 
>>>>
>>>>
>>>
>>> The master is complaining about YAML in the inbound request from an 
>>> agent.  You should stop seeing the message if you update the relevant 
>>> agents to a sufficiently recent version.
>>>
>>> The message is not related to ENC output, but inasmuch as JSON is very 
>>> nearly a subset of YAML, you should be able to have your ENC output JSON 
>>> now, provided that you don't tickle one of the few inconsistencies.  Not so 
>>> much XML.
>>>
>>>
>>> John
>>>
>>>
>>
>>
>> All of my agents are running 3.4.0.  (or so they are told to). Is there 
>> some way to find out where this anomalous request is coming from? A $DEBUG 
>> setting or equivalent?
>>
>
>
> If the name of the agent being serviced is not already logged in the 
> context of the message (look a few lines before), then you can probably get 
> it to be logged by enabling debug logging in the master (--debug 
> command-line option).
>
>
> John
>
>
Is this available via Passenger? IE a .conf setting? 

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

[Puppet Users] Host is missing hostname and/or domain

[JonY]

I have 36 (seemingly) identical machines deployed from a single manifest. 
For some reason I'm getting this error in my logs for a subset of them. 

/etc/hosts:

127.0.0.1 hostname hostname.fqdn localhost


Where else should I look?

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

[Puppet Users] Re: Getting rid of YAML?

[JonY]

On Friday, February 21, 2014 8:10:23 AM UTC-8, jcbollinger wrote:
>
>
>
> On Thursday, February 20, 2014 4:41:33 PM UTC-6, JonY wrote:
>>
>> Looks like my server updated to 3.4.2.  Since then I've started seeing 
>> these occasional messages like:
>>
>> Feb 20 14:19:05 puppet-master[5626]: YAML in network requests is 
>> deprecated and will be removed in a future version. See 
>> http://links.puppetlabs.com/deprecate_yaml_on_network
>> Feb 20 14:19:05 puppet-master[5626]:(at 
>> /usr/lib/ruby/site_ruby/1.8/puppet/network/http/handler.rb:304:in 
>> `decode_params')
>>
>> Does this mean I'll be able to start using JSON or XML in my ENC scripts? 
>>
>>
>
> The master is complaining about YAML in the inbound request from an 
> agent.  You should stop seeing the message if you update the relevant 
> agents to a sufficiently recent version.
>
> The message is not related to ENC output, but inasmuch as JSON is very 
> nearly a subset of YAML, you should be able to have your ENC output JSON 
> now, provided that you don't tickle one of the few inconsistencies.  Not so 
> much XML.
>
>
> John
>
>


All of my agents are running 3.4.0.  (or so they are told to). Is there 
some way to find out where this anomalous request is coming from? A $DEBUG 
setting or equivalent?

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/69e6fa25-106b-4b6d-a296-72186f5841fa%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] Getting rid of YAML?

[JonY]

Looks like my server updated to 3.4.2.  Since then I've started seeing 
these occasional messages like:

Feb 20 14:19:05 puppet-master[5626]: YAML in network requests is deprecated 
and will be removed in a future version. See 
http://links.puppetlabs.com/deprecate_yaml_on_network
Feb 20 14:19:05 puppet-master[5626]:(at 
/usr/lib/ruby/site_ruby/1.8/puppet/network/http/handler.rb:304:in 
`decode_params')

Does this mean I'll be able to start using JSON or XML in my ENC scripts? 

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/8f070b56-5c8c-499f-b34c-919f71513edc%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] Puppet agent - two calls to server / request?

[JonY]

I set up a simple ENC this morning that just logs every agent request to a 
file. What I've noticed is that every agent is logging two requests per 
run. Each request is about ~10 seconds apart.

Is this normal? Are my agents not setup correctly?

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/896158e2-26f7-4528-87d5-0262e9d5f693%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] Understanding script process control

[JonY]

One thing that does strike me as odd: if I run 'puppet agent --test' 
repeatedly I don't see multiple versions of this app. The duplication only 
happens when puppet runs via crond.

In any event - I'm trying 'hasstatus => false' to see if this makes any 
difference. 

On Tuesday, February 4, 2014 12:11:13 PM UTC-8, Jose Luis Ledesma wrote:
>
> Also try removing the subscribe parameter from the service, and check if 
> the restart works properly.
>
> Regards,
> El 04/02/2014 21:09, "José Luis Ledesma" > 
> escribió:
>
>> Have you tried setting hasstatus => true in the service definition?
>>
>> Could you provide a puppet agent -t --debug from the node?
>>
>> Regards,
>> El 04/02/2014 20:55, "JonY" > escribió:
>>
>>> I have an issue where puppet keeps starting additional instances of a 
>>> process even though it's already running. The 'control script' in question 
>>> does have a 'status' command but I'm thinking that I'm not properly telling 
>>> puppet that the process is ok.
>>>
>>> From the site:
>>> The init script’s status command must return 0 if the service is running 
>>> and a nonzero value otherwise. Ideally, these exit codes should conform to 
>>> the 
>>> LSB’s 
>>> specification<http://refspecs.linuxfoundation.org/LSB_4.1.0/LSB-Core-generic/LSB-Core-generic/iniscrptact.html>
>>>  for 
>>> init script status actions, but Puppet only considers the difference 
>>> between 0 and nonzero to be relevant.
>>>
>>>  The script is exiting with 'exit 0' when the process is running and 
>>> it's creating a .PID file for it in /var/run. If I examine 'echo $?' after 
>>> running 'service myscript status' I see 0. Is there some other indication 
>>> that I need? Should the script *actually* return 0? 
>>>
>>> When the box in question boots, there are immediately two instances of 
>>> the service running. Over time it builds up to quite a pile.
>>>
>>> If I run the script manually it responds as I would expect. "process is 
>>> running" and doesn't start additional instances.
>>>
>>> puppet script:
>>>
>>> class plugpc::local_services::x10monitor inherits plugpc::local_services
>>> {
>>> package
>>> {
>>> "x10monitor" :
>>> ensure => "latest",
>>> require => Package[ "mysql-server-5.1" ];
>>> }
>>>
>>> service
>>> {
>>> "x10monitor" :
>>> ensure => "running",
>>> enable => "true",
>>> subscribe => Package[ "x10monitor" ],
>>> require => [ Service[ "mysql" ], Package[ 
>>> "x10monitor" ]];
>>> }
>>>
>>> file
>>> {
>>> '/etc/logrotate.d/x10monitor' :
>>> mode => 644,
>>> source => 
>>> 'puppet:///modules/plugpc/logrotate/x10monitor',
>>> }
>>>
>>> }
>>>
>>>  -- 
>>> You received this message because you are subscribed 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/e3c410eb-0415-414f-9a0f-b8695efdadb7%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/66b5d39b-82b5-404b-a6c2-5bb6db1032e4%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] Understanding script process control

[JonY]

I'm getting suspicious that there is filesystem corruption. This may be 
confusing the service control.

On Tuesday, February 4, 2014 12:11:13 PM UTC-8, Jose Luis Ledesma wrote:
>
> Also try removing the subscribe parameter from the service, and check if 
> the restart works properly.
>
> Regards,
> El 04/02/2014 21:09, "José Luis Ledesma" > 
> escribió:
>
>> Have you tried setting hasstatus => true in the service definition?
>>
>> Could you provide a puppet agent -t --debug from the node?
>>
>> Regards,
>> El 04/02/2014 20:55, "JonY" > escribió:
>>
>>> I have an issue where puppet keeps starting additional instances of a 
>>> process even though it's already running. The 'control script' in question 
>>> does have a 'status' command but I'm thinking that I'm not properly telling 
>>> puppet that the process is ok.
>>>
>>> From the site:
>>> The init script’s status command must return 0 if the service is running 
>>> and a nonzero value otherwise. Ideally, these exit codes should conform to 
>>> the 
>>> LSB’s 
>>> specification<http://refspecs.linuxfoundation.org/LSB_4.1.0/LSB-Core-generic/LSB-Core-generic/iniscrptact.html>
>>>  for 
>>> init script status actions, but Puppet only considers the difference 
>>> between 0 and nonzero to be relevant.
>>>
>>>  The script is exiting with 'exit 0' when the process is running and 
>>> it's creating a .PID file for it in /var/run. If I examine 'echo $?' after 
>>> running 'service myscript status' I see 0. Is there some other indication 
>>> that I need? Should the script *actually* return 0? 
>>>
>>> When the box in question boots, there are immediately two instances of 
>>> the service running. Over time it builds up to quite a pile.
>>>
>>> If I run the script manually it responds as I would expect. "process is 
>>> running" and doesn't start additional instances.
>>>
>>> puppet script:
>>>
>>> class plugpc::local_services::x10monitor inherits plugpc::local_services
>>> {
>>> package
>>> {
>>> "x10monitor" :
>>> ensure => "latest",
>>> require => Package[ "mysql-server-5.1" ];
>>> }
>>>
>>> service
>>> {
>>> "x10monitor" :
>>> ensure => "running",
>>> enable => "true",
>>> subscribe => Package[ "x10monitor" ],
>>> require => [ Service[ "mysql" ], Package[ 
>>> "x10monitor" ]];
>>> }
>>>
>>> file
>>> {
>>> '/etc/logrotate.d/x10monitor' :
>>> mode => 644,
>>> source => 
>>> 'puppet:///modules/plugpc/logrotate/x10monitor',
>>> }
>>>
>>> }
>>>
>>>  -- 
>>> You received this message because you are subscribed 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/e3c410eb-0415-414f-9a0f-b8695efdadb7%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/f09d33fb-fe45-4a8b-bc8b-dba2a354a15a%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] Understanding script process control

[JonY]

I have an issue where puppet keeps starting additional instances of a 
process even though it's already running. The 'control script' in question 
does have a 'status' command but I'm thinking that I'm not properly telling 
puppet that the process is ok.

>From the site:
The init script’s status command must return 0 if the service is running 
and a nonzero value otherwise. Ideally, these exit codes should conform to the 
LSB’s 
specification
 for 
init script status actions, but Puppet only considers the difference 
between 0 and nonzero to be relevant.

The script is exiting with 'exit 0' when the process is running and it's 
creating a .PID file for it in /var/run. If I examine 'echo $?' after 
running 'service myscript status' I see 0. Is there some other indication 
that I need? Should the script *actually* return 0? 

When the box in question boots, there are immediately two instances of the 
service running. Over time it builds up to quite a pile.

If I run the script manually it responds as I would expect. "process is 
running" and doesn't start additional instances.

puppet script:

class plugpc::local_services::x10monitor inherits plugpc::local_services
{
package
{
"x10monitor" :
ensure => "latest",
require => Package[ "mysql-server-5.1" ];
}

service
{
"x10monitor" :
ensure => "running",
enable => "true",
subscribe => Package[ "x10monitor" ],
require => [ Service[ "mysql" ], Package[ 
"x10monitor" ]];
}

file
{
'/etc/logrotate.d/x10monitor' :
mode => 644,
source => 'puppet:///modules/plugpc/logrotate/x10monitor',
}

}

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

Re: [Puppet Users] Port for ENC requests?

[JonY]

chown puppet:puppet /etc/puppet/ENC/ENC.log

Perl was refusing to write to the log file when run under Passenger even 
though the file was as open as I could make it. And even though the script 
worked when run via the shell - passenger still wouldn't do it.



On Tuesday, February 4, 2014 11:16:41 AM UTC-8, Jose Luis Ledesma wrote:
>
> Have you looked syslog and apache logs?
>
> BTW /tmp should be 1777, but this shouldn't be the problem.
>
> Regards,
> El 04/02/2014 20:07, "JonY" > escribió:
>
>> I'm stumped then.
>>
>> Folder is 0777. Files are 0777. 
>>
>> I'm running the p-master using Passenger in apache2 which runs as the 
>> 'puppet' account. I used this account to run the app in question without 
>> any problem. 'su - puppet -c "/tmp/test0.pl"'. 
>>
>> SELinux is in 'permissive' mode.
>>
>> What else should I look for?
>>
>> On Monday, February 3, 2014 3:25:32 PM UTC-8, John Warburton wrote:
>>>
>>> On 4 February 2014 09:00, Jon Yeargers  wrote:
>>>
>>>> I'm trying to debug a new ENC setup. I created a short perl script to 
>>>> output a few lines of YAML. It runs fine on the puppet server but when I 
>>>> try it on a client I get this error:
>>>>
>>>> Warning: Error 400 on SERVER: Failed to find client.domain.org via 
>>>> exec: Execution of the '/etc/puppet/ENC/plug0.pl client.domain.org' 
>>>> returned 13:
>>>>
>>>  
>>>
>>>> Somewhere else I should be looking for errors? What does error 13 imply?
>>>>  
>>>> # grep 13 /usr/include/sys/errno.h
>>> #define EACCES  13  /* Permission denied 
>>>
>>> The user running the puppet master cannot access (read/execute?) your 
>>> script. Try running it as that user from the command line
>>>
>>> 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...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/puppet-users/ee479fec-6bd9-41b0-9f7c-0e33f362fb1b%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/4cbda3cc-acba-47e4-a352-95027dd54383%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] Port for ENC requests?

[JonY]

I'm stumped then.

Folder is 0777. Files are 0777. 

I'm running the p-master using Passenger in apache2 which runs as the 
'puppet' account. I used this account to run the app in question without 
any problem. 'su - puppet -c "/tmp/test0.pl"'. 

SELinux is in 'permissive' mode.

What else should I look for?

On Monday, February 3, 2014 3:25:32 PM UTC-8, John Warburton wrote:
>
> On 4 February 2014 09:00, Jon Yeargers >wrote:
>
>> I'm trying to debug a new ENC setup. I created a short perl script to 
>> output a few lines of YAML. It runs fine on the puppet server but when I 
>> try it on a client I get this error:
>>
>> Warning: Error 400 on SERVER: Failed to find client.domain.org via exec: 
>> Execution of the '/etc/puppet/ENC/plug0.pl client.domain.org' returned 
>> 13:
>>
>  
>
>> Somewhere else I should be looking for errors? What does error 13 imply?
>>  
>> # grep 13 /usr/include/sys/errno.h
> #define EACCES  13  /* Permission denied 
>
> The user running the puppet master cannot access (read/execute?) your 
> script. Try running it as that user from the command line
>
> 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/ee479fec-6bd9-41b0-9f7c-0e33f362fb1b%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.