Re: [Puppet Users] Re: Puppet Pro, 2nd edition - status directly from APress
I don't know what they are doing, but it will be an adventure to get a hard-copy of the book :) Krum, Spencer Pro Puppet (Professional Apress) Voraussichtliches Lieferdatum: 28. Juni 2014 - 30. Juni 2014 On 12/22/2013 02:59 AM, Stuart Cracraft wrote: hey did some ruby and cured those blues away. On Dec 21, 2013, at 5:55 PM, Felix Frank felix.fr...@alumni.tu-berlin.de wrote: Uhm, what is now? On 12/20/2013 11:35 PM, Stuart Cracraft wrote: It's all too money-centric and materialist. What a shame. -- You received this message because you are subscribed to a topic in the Google Groups Puppet Users group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/puppet-users/B-IogA5Tflc/unsubscribe. To unsubscribe from this group and all its topics, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/52B6469C.5090202%40Alumni.TU-Berlin.de. For more options, visit https://groups.google.com/groups/opt_out. -- Johan De Wit Open Source Consultant Red Hat Certified Engineer (805008667232363) Puppet Certified Professional 2013 (PCP006) _ Open-Future Phone +32 (0)2/255 70 70 Zavelstraat 72 Fax +32 (0)2/255 70 71 3071 KORTENBERG Mobile+32 (0)474/42 40 73 BELGIUM http://www.open-future.be _ Next Events: Puppet Advanced Training | http://www.open-future.be/puppet-advanced-training-7-till-9th-january Puppet Fundamentals Training | http://www.open-future.be/puppet-fundamentals-training-4-till-6th-february Subscribe to our newsletter | http://eepurl.com/BUG8H -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/52B7FF40.80709%40open-future.be. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] missing msgpack gem following puppet 3.4.0 upgrade
Hello all,
Our puppet master and agents recently updated to 3.4.0 and all of our
puppet runs are now compiling the catalog and promptly exiting happily
without actually doing anything. There isn't anything unusual about what I
see in the log output aside from a debug message about missing the msgpack
gem. We are not attempting to use the new serialization at this time and no
configurations have changed other than the package upgrade, but nonetheless
puppet seems displeased about not having the library. Has anyone else
encountered this? Is there something besides the package upgrade that is
required for this to work?
OS: CentOS 6.4
Puppet: 3.4.0-1
puppet.noarch 3.4.0-1.el6
@PuppetLabs
puppet-server.noarch 3.4.0-1.el6
@PuppetLabs
Some log output from an agent noop run, I am not 100% certain this is
causing the problem since the missing gem is only logged at the debug
level, but I'm only going off of nothing else seeming out of the ordinary.
I appreciate any thoughts on the matter, in the meantime I'll trying going
back to 3.3.2-1 and see if that restores proper function. Our normal runs
take many minutes as puppet does quite a bit for us, but it now bows out
awfully quick.
...
Debug: Using settings: adding file resource 'resourcefile':
'File[/var/lib/puppet/state/resources.txt]{:loglevel=:debug,
:links=:follow, :owner=root, :backup=false, :mode=640,
:ensure=:file, :path=/var/lib/puppet/state/resources.txt}'
Debug: Using settings: adding file resource 'clientyamldir':
'File[/var/lib/puppet/client_yaml]{:loglevel=:debug, :links=:follow,
:backup=false, :mode=750, :ensure=:directory,
:path=/var/lib/puppet/client_yaml}'
Debug: Using settings: adding file resource 'classfile':
'File[/var/lib/puppet/classes.txt]{:loglevel=:debug, :links=:follow,
:owner=root, :backup=false, :mode=640, :ensure=:file,
:path=/var/lib/puppet/classes.txt}'
Debug: Using settings: adding file resource 'lastrunreport':
'File[/var/lib/puppet/state/last_run_report.yaml]{:loglevel=:debug,
:links=:follow, :backup=false, :mode=640, :ensure=:file,
:path=/var/lib/puppet/state/last_run_report.yaml}'
Debug: Using settings: adding file resource 'clientbucketdir':
'File[/var/lib/puppet/clientbucket]{:loglevel=:debug, :links=:follow,
:backup=false, :mode=750, :ensure=:directory,
:path=/var/lib/puppet/clientbucket}'
Debug: Using settings: adding file resource 'graphdir':
'File[/var/lib/puppet/state/graphs]{:loglevel=:debug, :links=:follow,
:backup=false, :ensure=:directory, :path=/var/lib/puppet/state/graphs}'
Debug: Using settings: adding file resource 'statefile':
'File[/var/lib/puppet/state/state.yaml]{:loglevel=:debug, :links=:follow,
:backup=false, :mode=660, :ensure=:file,
:path=/var/lib/puppet/state/state.yaml}'
Debug: Using settings: adding file resource 'client_datadir':
'File[/var/lib/puppet/client_data]{:loglevel=:debug, :links=:follow,
:backup=false, :mode=750, :ensure=:directory,
:path=/var/lib/puppet/client_data}'
Debug: Using settings: adding file resource 'lastrunfile':
'File[/var/lib/puppet/state/last_run_summary.yaml]{:loglevel=:debug,
:links=:follow, :backup=false, :mode=644, :ensure=:file,
:path=/var/lib/puppet/state/last_run_summary.yaml}'
Debug: Finishing transaction 70160328710680
Debug: Loaded state in 0.06 seconds
*Debug: Failed to load library 'msgpack' for feature 'msgpack'*
Debug: node supports formats: pson b64_zlib_yaml yaml raw
Debug: Using cached certificate for ca
Debug: Using cached certificate for stack01.qa.tstllc.net
Debug: Using cached certificate_revocation_list for ca
Info: Retrieving plugin
*Debug: Failed to load library 'msgpack' for feature 'msgpack'*
Debug: file_metadata supports formats: pson b64_zlib_yaml yaml raw
Debug: Finishing transaction 70160331731520
Info: Loading facts in /var/lib/puppet/lib/facter/fqdn_int.rb
Info: Loading facts in /var/lib/puppet/lib/facter/domain_int.rb
Info: Loading facts in /var/lib/puppet/lib/facter/facter_dot_d.rb
Info: Loading facts in /var/lib/puppet/lib/facter/root_home.rb
Info: Loading facts in /var/lib/puppet/lib/facter/datacenter.rb
Info: Loading facts in /var/lib/puppet/lib/facter/environment.rb
Info: Loading facts in /var/lib/puppet/lib/facter/puppet_vardir.rb
Info: Loading facts in /var/lib/puppet/lib/facter/pe_version.rb
Info: Loading facts in /var/lib/puppet/lib/facter/role.rb
*Debug: Failed to load library 'msgpack' for feature 'msgpack'*
Debug: catalog supports formats: pson dot b64_zlib_yaml yaml raw
Info: Caching catalog for stack01.qa.tstllc.net
Debug: Creating default schedules
Debug: Loaded state in 0.03 seconds
Info: Applying configuration version '1387818458'
Debug: Finishing transaction 70160316686700
Debug: Storing state
Debug: Stored state in 0.16 seconds
Notice: Finished catalog run in 0.26 seconds
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To unsubscribe from this group
[Puppet Users] Re: missing msgpack gem following puppet 3.4.0 upgrade
Upon downgrading to 3.3.2-1 the problem still remains, so it does appear
that the missing msgpack gem is a red herring that is not the cause of my
problem. I'd still be interested in thoughts on that debug statement
though, particularly if we choose to move to the improved serialization in
the future.
On Monday, December 23, 2013 12:44:59 PM UTC-5, Luke Alford wrote:
Hello all,
Our puppet master and agents recently updated to 3.4.0 and all of our
puppet runs are now compiling the catalog and promptly exiting happily
without actually doing anything. There isn't anything unusual about what I
see in the log output aside from a debug message about missing the msgpack
gem. We are not attempting to use the new serialization at this time and no
configurations have changed other than the package upgrade, but nonetheless
puppet seems displeased about not having the library. Has anyone else
encountered this? Is there something besides the package upgrade that is
required for this to work?
OS: CentOS 6.4
Puppet: 3.4.0-1
puppet.noarch 3.4.0-1.el6
@PuppetLabs
puppet-server.noarch 3.4.0-1.el6
@PuppetLabs
Some log output from an agent noop run, I am not 100% certain this is
causing the problem since the missing gem is only logged at the debug
level, but I'm only going off of nothing else seeming out of the ordinary.
I appreciate any thoughts on the matter, in the meantime I'll trying going
back to 3.3.2-1 and see if that restores proper function. Our normal runs
take many minutes as puppet does quite a bit for us, but it now bows out
awfully quick.
...
Debug: Using settings: adding file resource 'resourcefile':
'File[/var/lib/puppet/state/resources.txt]{:loglevel=:debug,
:links=:follow, :owner=root, :backup=false, :mode=640,
:ensure=:file, :path=/var/lib/puppet/state/resources.txt}'
Debug: Using settings: adding file resource 'clientyamldir':
'File[/var/lib/puppet/client_yaml]{:loglevel=:debug, :links=:follow,
:backup=false, :mode=750, :ensure=:directory,
:path=/var/lib/puppet/client_yaml}'
Debug: Using settings: adding file resource 'classfile':
'File[/var/lib/puppet/classes.txt]{:loglevel=:debug, :links=:follow,
:owner=root, :backup=false, :mode=640, :ensure=:file,
:path=/var/lib/puppet/classes.txt}'
Debug: Using settings: adding file resource 'lastrunreport':
'File[/var/lib/puppet/state/last_run_report.yaml]{:loglevel=:debug,
:links=:follow, :backup=false, :mode=640, :ensure=:file,
:path=/var/lib/puppet/state/last_run_report.yaml}'
Debug: Using settings: adding file resource 'clientbucketdir':
'File[/var/lib/puppet/clientbucket]{:loglevel=:debug, :links=:follow,
:backup=false, :mode=750, :ensure=:directory,
:path=/var/lib/puppet/clientbucket}'
Debug: Using settings: adding file resource 'graphdir':
'File[/var/lib/puppet/state/graphs]{:loglevel=:debug, :links=:follow,
:backup=false, :ensure=:directory, :path=/var/lib/puppet/state/graphs}'
Debug: Using settings: adding file resource 'statefile':
'File[/var/lib/puppet/state/state.yaml]{:loglevel=:debug, :links=:follow,
:backup=false, :mode=660, :ensure=:file,
:path=/var/lib/puppet/state/state.yaml}'
Debug: Using settings: adding file resource 'client_datadir':
'File[/var/lib/puppet/client_data]{:loglevel=:debug, :links=:follow,
:backup=false, :mode=750, :ensure=:directory,
:path=/var/lib/puppet/client_data}'
Debug: Using settings: adding file resource 'lastrunfile':
'File[/var/lib/puppet/state/last_run_summary.yaml]{:loglevel=:debug,
:links=:follow, :backup=false, :mode=644, :ensure=:file,
:path=/var/lib/puppet/state/last_run_summary.yaml}'
Debug: Finishing transaction 70160328710680
Debug: Loaded state in 0.06 seconds
*Debug: Failed to load library 'msgpack' for feature 'msgpack'*
Debug: node supports formats: pson b64_zlib_yaml yaml raw
Debug: Using cached certificate for ca
Debug: Using cached certificate for stack01.qa.tstllc.net
Debug: Using cached certificate_revocation_list for ca
Info: Retrieving plugin
*Debug: Failed to load library 'msgpack' for feature 'msgpack'*
Debug: file_metadata supports formats: pson b64_zlib_yaml yaml raw
Debug: Finishing transaction 70160331731520
Info: Loading facts in /var/lib/puppet/lib/facter/fqdn_int.rb
Info: Loading facts in /var/lib/puppet/lib/facter/domain_int.rb
Info: Loading facts in /var/lib/puppet/lib/facter/facter_dot_d.rb
Info: Loading facts in /var/lib/puppet/lib/facter/root_home.rb
Info: Loading facts in /var/lib/puppet/lib/facter/datacenter.rb
Info: Loading facts in /var/lib/puppet/lib/facter/environment.rb
Info: Loading facts in /var/lib/puppet/lib/facter/puppet_vardir.rb
Info: Loading facts in /var/lib/puppet/lib/facter/pe_version.rb
Info: Loading facts in /var/lib/puppet/lib/facter/role.rb
*Debug: Failed to load library 'msgpack' for feature 'msgpack'*
Debug: catalog supports formats: pson dot
Re: [Puppet Users] Re: missing msgpack gem following puppet 3.4.0 upgrade
Puppet 3.4.0 adds experimental support for the msgpack protocol (
http://docs.puppetlabs.com/puppet/3/reference/experiments_msgpack.html),
but doesn't depend on it being present. To enable it you need to install
the msgpack gem and set the preferred serialization format, so unless
you're explicitly enabling it then it shouldn't be a concern. Since it's
only experimental we aren't planning on moving to it in the near future,
but it's available so that people can try it for themselves.
With respect to your puppet runs being empty, you'll probably want to
ensure that the puppet master is generating the catalogs that you expected.
You can do `puppet master --compile nodename` to directly generate a
catalog; if that returns an empty catalog then it is probably an issue with
how the master is configured.
On Mon, Dec 23, 2013 at 9:54 AM, Luke Alford laa1...@gmail.com wrote:
Upon downgrading to 3.3.2-1 the problem still remains, so it does appear
that the missing msgpack gem is a red herring that is not the cause of my
problem. I'd still be interested in thoughts on that debug statement
though, particularly if we choose to move to the improved serialization in
the future.
On Monday, December 23, 2013 12:44:59 PM UTC-5, Luke Alford wrote:
Hello all,
Our puppet master and agents recently updated to 3.4.0 and all of our
puppet runs are now compiling the catalog and promptly exiting happily
without actually doing anything. There isn't anything unusual about what I
see in the log output aside from a debug message about missing the msgpack
gem. We are not attempting to use the new serialization at this time and no
configurations have changed other than the package upgrade, but nonetheless
puppet seems displeased about not having the library. Has anyone else
encountered this? Is there something besides the package upgrade that is
required for this to work?
OS: CentOS 6.4
Puppet: 3.4.0-1
puppet.noarch 3.4.0-1.el6
@PuppetLabs
puppet-server.noarch 3.4.0-1.el6
@PuppetLabs
Some log output from an agent noop run, I am not 100% certain this is
causing the problem since the missing gem is only logged at the debug
level, but I'm only going off of nothing else seeming out of the ordinary.
I appreciate any thoughts on the matter, in the meantime I'll trying going
back to 3.3.2-1 and see if that restores proper function. Our normal runs
take many minutes as puppet does quite a bit for us, but it now bows out
awfully quick.
...
Debug: Using settings: adding file resource 'resourcefile':
'File[/var/lib/puppet/state/resources.txt]{:loglevel=:debug,
:links=:follow, :owner=root, :backup=false, :mode=640,
:ensure=:file, :path=/var/lib/puppet/state/resources.txt}'
Debug: Using settings: adding file resource 'clientyamldir':
'File[/var/lib/puppet/client_yaml]{:loglevel=:debug, :links=:follow,
:backup=false, :mode=750, :ensure=:directory, :path=/var/lib/puppet/
client_yaml}'
Debug: Using settings: adding file resource 'classfile':
'File[/var/lib/puppet/classes.txt]{:loglevel=:debug, :links=:follow,
:owner=root, :backup=false, :mode=640, :ensure=:file,
:path=/var/lib/puppet/classes.txt}'
Debug: Using settings: adding file resource 'lastrunreport':
'File[/var/lib/puppet/state/last_run_report.yaml]{:loglevel=:debug,
:links=:follow, :backup=false, :mode=640, :ensure=:file,
:path=/var/lib/puppet/state/last_run_report.yaml}'
Debug: Using settings: adding file resource 'clientbucketdir':
'File[/var/lib/puppet/clientbucket]{:loglevel=:debug, :links=:follow,
:backup=false, :mode=750, :ensure=:directory, :path=/var/lib/puppet/
clientbucket}'
Debug: Using settings: adding file resource 'graphdir':
'File[/var/lib/puppet/state/graphs]{:loglevel=:debug, :links=:follow,
:backup=false, :ensure=:directory, :path=/var/lib/puppet/state/
graphs}'
Debug: Using settings: adding file resource 'statefile':
'File[/var/lib/puppet/state/state.yaml]{:loglevel=:debug,
:links=:follow, :backup=false, :mode=660, :ensure=:file,
:path=/var/lib/puppet/state/state.yaml}'
Debug: Using settings: adding file resource 'client_datadir':
'File[/var/lib/puppet/client_data]{:loglevel=:debug, :links=:follow,
:backup=false, :mode=750, :ensure=:directory, :path=/var/lib/puppet/
client_data}'
Debug: Using settings: adding file resource 'lastrunfile':
'File[/var/lib/puppet/state/last_run_summary.yaml]{:loglevel=:debug,
:links=:follow, :backup=false, :mode=644, :ensure=:file,
:path=/var/lib/puppet/state/last_run_summary.yaml}'
Debug: Finishing transaction 70160328710680
Debug: Loaded state in 0.06 seconds
*Debug: Failed to load library 'msgpack' for feature 'msgpack'*
Debug: node supports formats: pson b64_zlib_yaml yaml raw
Debug: Using cached certificate for ca
Debug: Using cached certificate for stack01.qa.tstllc.net
Debug: Using cached certificate_revocation_list for ca
Info: Retrieving plugin
*Debug: Failed to load library 'msgpack' for feature 'msgpack'*
Re: [Puppet Users] Roles/profile design
Ramin,
After looking more at your example for configuring apache mods via hiera, I
have one problem.
The create_resources will actually just define a resource like so:
apache::mod { 'php' }
However, to install the php module with puppetlabs/apache, I actually need
to include the apache::mod::php class, ie:
class { 'apache::mod::php' }
Any ideas on how to make this work correctly? The hiera data should allow
me to choose which apache::mod::subclass modules that should be installed.
Thanks,
Josh
You're overloading profile because you're not using Hiera or an
ENC.
Take this example
class role::app1_fe { # or perhaps ::fe_app1
include profile::apache
include profile::php
}
class profile::apache {
include apache
$mymods = hiera('apache::a2mods', {})
create_resources('apache::a2mod', $mymods)
$myvhosts = hiera('apache::vhosts', {})
create_resources('apache::vhost', $myvhosts)
}
profile::apache can be used by *any* server that needs Apache because by
default it does nothing but the minimal config of Apache. However if you
were to feed it data such as modules to enable or vhosts to load you
could build any Apache server you might need.
hieradata/app1_fe.yaml # this assumes you have a role fact.
---
apache::a2mods:
expires: {}
headers: {}
rewrite: {}
apache::vhosts:
www.example.com: {}
Structures like profile::webserver::app1 indicate you're mixing roles
and profiles. And you also embedding data into your Puppet code rather
than writing code to consume data.
It's a lot to wrap your head around and from my experience it
takes 1-2
restructures of your Puppet code to fully understand it.
Ramin
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/72124198-748e-4e3e-8bb5-75c333edb8b5%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Roles/profile design
On 12/23/2013 02:52 PM, Josh wrote:
Ramin,
After looking more at your example for configuring apache mods via hiera, I
have one problem.
The create_resources will actually just define a resource like so:
apache::mod { 'php' }
However, to install the php module with puppetlabs/apache, I actually need
to include the apache::mod::php class, ie:
class { 'apache::mod::php' }
Any ideas on how to make this work correctly? The hiera data should allow
me to choose which apache::mod::subclass modules that should be installed.
Thanks,
Josh
Hi,
How are you declaring your classes to include from with in hiera?
Is it similar to this?
---
classes:
- apache
- apache::mod
apache::someparamater: value
apache::mod::php: blah
If so, you should be able to do:
---
classes:
- apache
- apache::mod::php
apache::my_favorite_parameter: value
apache::mod::php::php_parameter: some_other_vaule
I haven't tried that exact thing with the apache module, but it does
work for other modules with sub-classes that I've been working with.
That is assuming that you're using the 'classes' array with the
hiera_include function. We use the create_resources function to create
wrappers for defines, while regular classes are included via the
hiera_include and classes array.
Our setup was pretty much taken directly from the hiera documentation:
http://docs.puppetlabs.com/hiera/1/puppet.html#assigning-classes-to-nodes-with-hiera-hierainclude
There are some gotchas that come up with the hiera merge behavior
depending on how complex you're hiera layout becomes. For example, we
had to set the hiera merge_behavior to deeper for us to get some of the
desired results that we were looking for.
--
Joseph Swick joseph.sw...@meltwater.com
Operations Engineer
Meltwater Group
signature.asc
Description: OpenPGP digital signature
[Puppet Users] Re: Debugging execution error with vcsrepo
If I manually clone the repo, I get a similarly puzzling error:
Error: /Stage[main]/myuser/Vcsrepo[/home/myuser/myrepo]: Could not
evaluate: Execution of '/usr/bin/su myuser -c /usr/local/bin/git config
remote.origin.url' returned 127: -su: /usr/local/bin/git config
remote.origin.url: No such file or directory
On Saturday, 21 December 2013 18:33:45 UTC-8, Patrick Gibson wrote:
I'm using the vcsrepo module to clone a git repo as a particular user, and
I'm getting a puzzling error:
Debug: Executing '/usr/bin/su myuser -c /usr/local/bin/git clone
g...@git.myhostname.com:repos/myrepo.git /home/myuser/myrepo'
Error: Execution of '/usr/bin/su myuser -c /usr/local/bin/git clone
g...@git.myhostname.com:repos/myrepo.git /home/myuser/myrepo' returned 127:
su: /usr/local/bin/git clone g...@git.myhostname.com:repos/myrepo.git
/home/myuser/myrepo: No such file or directory
When I copy and paste the exact command and run it, it works fine. I can't
figure out what would be complaining about No such file or directory.
Every executable and path mentioned in the command exists.
My relevant classes look like this:
class sshd {
file { /etc/ssh/sshd_config:
source = puppet:///modules/sshd/sshd_config,
notify = Service[sshd]
}
file { /etc/ssh/ssh_config:
source = puppet:///modules/sshd/ssh_config,
notify = Service[sshd]
}
service { sshd:
ensure = running,
}
}
class myuser {
file { /home/myuser/.ssh:
ensure = directory,
mode = 0700,
owner = myuser,
group = myuser,
}
file { /home/myuser/.ssh/known_hosts:
source = puppet:///modules/myuser/.ssh/known_hosts,
owner = myuser,
group = myuser,
}
file { /home/myuser/.ssh/id_rsa:
source = puppet:///modules/myuser/.ssh/id_rsa,
mode = 0600,
owner = myuser,
group = myuser,
}
vcsrepo { /home/myuser/myrepo:
require = Class[sshd],
ensure = present,
provider = git,
source = 'g...@git.myhostname.com:repos/myrepo.git',
revision = 'master',
user = 'myuser'
}
}
Any pointers?
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/d0efd577-e9f7-432d-bef4-cb388bc526a0%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Re: missing msgpack gem following puppet 3.4.0 upgrade
Thanks for the confirmation Adrien, and for the tip on the puppet master
compile command. I don't do much administration so I'm not terribly
familiar with some of those common commands. I've got some more questions
you or others might be able to shed light on, but they're well beyond the
scope of my original question so I'll post a new thread.
Thanks!
On Monday, December 23, 2013 2:12:57 PM UTC-5, Adrien Thebo wrote:
Puppet 3.4.0 adds experimental support for the msgpack protocol (
http://docs.puppetlabs.com/puppet/3/reference/experiments_msgpack.html),
but doesn't depend on it being present. To enable it you need to install
the msgpack gem and set the preferred serialization format, so unless
you're explicitly enabling it then it shouldn't be a concern. Since it's
only experimental we aren't planning on moving to it in the near future,
but it's available so that people can try it for themselves.
With respect to your puppet runs being empty, you'll probably want to
ensure that the puppet master is generating the catalogs that you expected.
You can do `puppet master --compile nodename` to directly generate a
catalog; if that returns an empty catalog then it is probably an issue with
how the master is configured.
On Mon, Dec 23, 2013 at 9:54 AM, Luke Alford laa...@gmail.comjavascript:
wrote:
Upon downgrading to 3.3.2-1 the problem still remains, so it does appear
that the missing msgpack gem is a red herring that is not the cause of my
problem. I'd still be interested in thoughts on that debug statement
though, particularly if we choose to move to the improved serialization in
the future.
On Monday, December 23, 2013 12:44:59 PM UTC-5, Luke Alford wrote:
Hello all,
Our puppet master and agents recently updated to 3.4.0 and all of our
puppet runs are now compiling the catalog and promptly exiting happily
without actually doing anything. There isn't anything unusual about what I
see in the log output aside from a debug message about missing the msgpack
gem. We are not attempting to use the new serialization at this time and no
configurations have changed other than the package upgrade, but nonetheless
puppet seems displeased about not having the library. Has anyone else
encountered this? Is there something besides the package upgrade that is
required for this to work?
OS: CentOS 6.4
Puppet: 3.4.0-1
puppet.noarch 3.4.0-1.el6
@PuppetLabs
puppet-server.noarch 3.4.0-1.el6
@PuppetLabs
Some log output from an agent noop run, I am not 100% certain this is
causing the problem since the missing gem is only logged at the debug
level, but I'm only going off of nothing else seeming out of the ordinary.
I appreciate any thoughts on the matter, in the meantime I'll trying going
back to 3.3.2-1 and see if that restores proper function. Our normal runs
take many minutes as puppet does quite a bit for us, but it now bows out
awfully quick.
...
Debug: Using settings: adding file resource 'resourcefile':
'File[/var/lib/puppet/state/resources.txt]{:loglevel=:debug,
:links=:follow, :owner=root, :backup=false, :mode=640,
:ensure=:file, :path=/var/lib/puppet/state/resources.txt}'
Debug: Using settings: adding file resource 'clientyamldir':
'File[/var/lib/puppet/client_yaml]{:loglevel=:debug, :links=:follow,
:backup=false, :mode=750, :ensure=:directory, :path=/var/lib/puppet/
client_yaml}'
Debug: Using settings: adding file resource 'classfile':
'File[/var/lib/puppet/classes.txt]{:loglevel=:debug, :links=:follow,
:owner=root, :backup=false, :mode=640, :ensure=:file,
:path=/var/lib/puppet/classes.txt}'
Debug: Using settings: adding file resource 'lastrunreport':
'File[/var/lib/puppet/state/last_run_report.yaml]{:loglevel=:debug,
:links=:follow, :backup=false, :mode=640, :ensure=:file,
:path=/var/lib/puppet/state/last_run_report.yaml}'
Debug: Using settings: adding file resource 'clientbucketdir':
'File[/var/lib/puppet/clientbucket]{:loglevel=:debug, :links=:follow,
:backup=false, :mode=750, :ensure=:directory, :path=/var/lib/puppet/
clientbucket}'
Debug: Using settings: adding file resource 'graphdir':
'File[/var/lib/puppet/state/graphs]{:loglevel=:debug, :links=:follow,
:backup=false, :ensure=:directory, :path=/var/lib/puppet/state/
graphs}'
Debug: Using settings: adding file resource 'statefile':
'File[/var/lib/puppet/state/state.yaml]{:loglevel=:debug,
:links=:follow, :backup=false, :mode=660, :ensure=:file,
:path=/var/lib/puppet/state/state.yaml}'
Debug: Using settings: adding file resource 'client_datadir':
'File[/var/lib/puppet/client_data]{:loglevel=:debug, :links=:follow,
:backup=false, :mode=750, :ensure=:directory, :path=/var/lib/puppet/
client_data}'
Debug: Using settings: adding file resource 'lastrunfile':
'File[/var/lib/puppet/state/last_run_summary.yaml]{:loglevel=:debug,
:links=:follow,
Re: [Puppet Users] Roles/profile design
Joseph, I'm not currently defining classes with hiera. The host is assigned a role, which includes a profile, which installs includes ::apache. I guess this may be something that we need to look at for these types of scenarios. Josh Hi, How are you declaring your classes to include from with in hiera? Is it similar to this? --- classes: - apache - apache::mod apache::someparamater: value apache::mod::php: blah If so, you should be able to do: --- classes: - apache - apache::mod::php apache::my_favorite_parameter: value apache::mod::php::php_parameter: some_other_vaule I haven't tried that exact thing with the apache module, but it does work for other modules with sub-classes that I've been working with. That is assuming that you're using the 'classes' array with the hiera_include function. We use the create_resources function to create wrappers for defines, while regular classes are included via the hiera_include and classes array. Our setup was pretty much taken directly from the hiera documentation: http://docs.puppetlabs.com/hiera/1/puppet.html#assigning-classes-to-nodes-with-hiera-hierainclude There are some gotchas that come up with the hiera merge behavior depending on how complex you're hiera layout becomes. For example, we had to set the hiera merge_behavior to deeper for us to get some of the desired results that we were looking for. -- Joseph Swick joseph...@meltwater.com javascript: Operations Engineer Meltwater Group -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/c7ba4374-1b14-4dfc-8165-97122836141a%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] puppet 3.4.0 upgrade, foreman 1.1-stable, problems that are not provisioning related
I am having problems with our puppet/foreman infrastructure that seem to
coincide with an upgrade to 3.4.0-1, but that are persisting after a
downgrade back to 3.3.2-1. There are no obvious errors I can find and I
don't seem to be having any problems with puppet talking to foreman, so
overall things look completely normal other than I have puppet classes when
foreman responds with node information and an empty catalog after the
puppet master compiles. I am pretty stumped by this and would appreciate
any thoughts others may have on troubleshooting this problem.
First, here's some more important information about our system. We had been
running puppet 3.3.2-1 and foreman 1.1-stable for quite some time before
things bumped up to 3.4.0 over the weekend.
- centos 6.4 for puppet master and nodes
- puppet and puppet-server 3.3.2-1 (I downgraded both puppet and
puppet-server back to this version since we'd been running successfully
with it for some time now)
- puppetdb and puppetdb-terminus 1.5.0-1
- foreman 1.1-stable (we've also been running this for some time, we don't
do any provisioning with it but we use it as an ENC for storing data and
classifying nodes into roles)
- puppet and foreman running behind nginx/passenger
If the upgrade to 3.4.0 was the sole source of my problem I would expect
things to have returned back to normal after the downgrade. Since the
catalog is still empty though, there's got to be something I'm missing.
Here are a few things I've tried while digging into this.
1) puppet master --compile my node
The node is found, but there are no classes identified. Therein lies the
problem.
...
version: 1387830624,
classes: [
settings,
default
],
environment: production
...
2) Firing up irb, I manually checked what foreman returns for my node. I
won't post the whole output including parameters, but the important part is
that the keyset for the classes key in the yaml document matches what I
would expect for this particular monolithic test box.
...
{play=nil, sudo=nil, mongo=nil, rsyslog=nil,
mysql::server=nil, jmx=nil, nginx::loadbalancer=nil, ssh=nil,
play::install=nil, mongo::seed=nil, users=nil,
mysql::server::master=nil, logstash=nil, common=nil,
puppet=nil, zabbix=nil, motd=nil, logrotate=nil, java=nil,
yum=nil, ntp=nil}
3) I noticed that facter also updated to version 1.7.4 during this time,
but at least from what I've tried so far this doesn't seem to be a problem
of any kind.
4) Yes, I did try turning it off and on again. :)
So it seems that somewhere between talking to the ENC and actually
compiling the catalog that my puppet classes disappear into the ether that
I have not yet identified. I would appreciate any suggestions people have
on further troubleshooting, or why the upgrade might have gotten things
into an odd state that rolling back the package somehow doesn't fix.
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/8ab0dbef-8ffc-4b57-b26e-e30991c41085%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Roles/profile design
Something like the following might work.
class profile::app1_site
class {'apache::mod::php':}
package { 'php5-brcypt': }
# etc etc
}
I've avoided parameterized classes for historical reasons, but Joseph's
method should work. It does require some restructuring.
fwiw not a fan of the apache::mod set of functionality unless the
module is part of Apache core. I've noticed there is now a
puppetlabs-passenger module to handle the complexities apache::mod {
'passenger': } could not. Assuming your PHP config is more than just
installing the Apache module I recommend following the same logic and
making your own PHP module with a module and local conf define. Wrap
that in profile::php with the needed create_resources and add it to the
role.
Ramin
On 12/23/2013 12:44 PM, Josh wrote:
Joseph,
I'm not currently defining classes with hiera. The host is assigned a
role, which includes a profile, which installs includes ::apache. I
guess this may be something that we need to look at for these types of
scenarios.
Josh
Hi,
How are you declaring your classes to include from with in hiera?
Is it similar to this?
---
classes:
- apache
- apache::mod
apache::someparamater: value
apache::mod::php: blah
If so, you should be able to do:
---
classes:
- apache
- apache::mod::php
apache::my_favorite_parameter: value
apache::mod::php::php_parameter: some_other_vaule
I haven't tried that exact thing with the apache module, but it does
work for other modules with sub-classes that I've been working with.
That is assuming that you're using the 'classes' array with the
hiera_include function. We use the create_resources function to create
wrappers for defines, while regular classes are included via the
hiera_include and classes array.
Our setup was pretty much taken directly from the hiera documentation:
http://docs.puppetlabs.com/hiera/1/puppet.html#assigning-classes-to-nodes-with-hiera-hierainclude
http://docs.puppetlabs.com/hiera/1/puppet.html#assigning-classes-to-nodes-with-hiera-hierainclude
There are some gotchas that come up with the hiera merge behavior
depending on how complex you're hiera layout becomes. For example, we
had to set the hiera merge_behavior to deeper for us to get some of the
desired results that we were looking for.
--
Joseph Swick joseph...@meltwater.com javascript:
Operations Engineer
Meltwater Group
--
You received this message because you are subscribed to the Google
Groups Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send
an email to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/c7ba4374-1b14-4dfc-8165-97122836141a%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/52B8A956.5050108%40badapple.net.
For more options, visit https://groups.google.com/groups/opt_out.
