Re: [Puppet Users] Re: copying files to the agent that matched hostname
Hi San,
On 08/16/2011 08:46 PM, Sans wrote:
Thanks John! Is $hostname a puppet built-in variable like
$operatingsystem, $fqdn etc?
These varaibles are made available to puppet by facter.
You can run facter on command line to see facter output.
Regards,
Martin
-San
On Aug 16, 3:38 pm, jcbollinger john.bollin...@stjude.org wrote:
You can interpolate the 'hostname' fact into the name of the resouce,
the name of the file on the file server, or both. For example:
file { ${hostname}-cert.pem:
...
source = puppet://puppet.internalnet/modules/certs/${hostname}-
cert.pem
}
John
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] mount remounts not working
On Tue, 16 Aug 2011 18:31:48 +0200 Stefan Schulte wrote: [...] Solution: remove the name (so name will implicitly be /srv/cloud) or change name to /srv/cloud (with no trailing slash) FTW: This is filed as https://projects.puppetlabs.com/issues/6793 thanks a lot! -Stefan Cheers, Arnau -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: scoping question - I want a node specific global var
On Aug 16, 11:24 am, Rich Rauenzahn rraue...@gmail.com wrote:
On Tue, Aug 16, 2011 at 6:23 AM, jcbollinger john.bollin...@stjude.org
wrote:
[Lots of good ideas]
Of those, I would recommend either extlookup() or your ENC (if you
have one), with my personal preference being extlookup(). I think
Hiera may offer an even better solution (though similar to
extlookup()), but I'm not familiar enough with it to feel comfortable
recommending it.
Unfortunately I've thought of some of those and they don't quite fit
with our existing infrastructure.
* We're not using ENC
Fair enough. I don't use one either, but it was worth pointing out
the possibility.
* I want the special information right alongside the node decl. This
reduces chance for error and makes the data more maintainable.
So that's the constraint that is really biting you, in more ways than
one, and I feel obligated to observe that it is a style / practices
issue, not an infrastructure issue.
Let me give more background:
We have a nodes.pp with a lot of hosts in it. We map a nodename to a
single class...
node /our-squid\d+/ { include system:our_squid }
node /our-db\d+/ { include system:our_db }
and so on.
We are making a failover site.
node /special-our-squid\d+/ { include system::our_squid}
node /special-our-db\d+/ { include system::our_db }
I don't want to confuse the issue with more details, but due to some
legacy naming conventions, we can't (..shouldn't...) use /^special-*/
to determine the sites are failover. We would like the attribute in
puppet.
Ok, so that rules out regex hostname matching, both in node
declarations and in selector expressions. It makes it less palatable,
but by no means impossible to use a selector somewhere to choose a
value for $failover. It remains your stipulation that $failover be
assigned in the node declaration that narrows your options here.
I could do class { system::our_db: failover = failover }, except I
want that failover attribute within the class that system::our_db
derives from.
class system {
// Am I special?
}
class system::our_db($failover) inherits system {
// Am I special, too?
}
So ideally (except that this won't work with the new scoping rules in
the future), I'd like to
node /special-our-db\d+/ { $SPECIAL=true
include system::our_db }
Now, I could make a class
class special($yesorno = false) {
$SPECIAL = $yesorno
}
and include that in all nodes, and change it to false in the special
nodes It isn't very elegant and makes our node file a lot
messier. Each node is two lines now.. there must be a more elegant
solution.
Your constraint that the failover information be in the node
declarations is again what's driving you here. It is not consistent
to insist that node declarations must contain more information, but at
the same time complain that they become longer / more complex.
Maybe the answer is to make a case statement in the nodes.pp that sets
$IMSPECIAL globally based on the hostname... which was one of your
suggestions. But I don't like maintaining two lists of host regex's,
which could get out of date.
Is there no specifier to reach my node's scope? i.e.,
$mynode::IMSPECIAL? Maybe in Ruby?
Only dynamic scoping, as far as I know, and that's going away. Also,
it doesn't work with node inheritance the way you would like it to do.
It may be that Hiera provides a way to paper over this problem. I
have not studied it enough to be sure, but it looks like it can
combine multiple data sources, including at least Puppet variables,
flat files, and databases. There are multiple ways you could use it,
including variations that set a variable in the node definition and
variations that put the lookup directly in the class that uses the
data. The data associating 'special' status with certain nodes could
be centralized or not, as you wish, and the data consumers need not be
affected if you later choose to change the data organization. If you
wanted, that data could be externalized, so that you would not need to
modify anything about your manifests when you add a new special node.
Extlookup() gives you most of that as well, but Hiera is the next,
more powerful generation of the idea.
Alternatively, you could drop the plan to use node inheritance. You
must have a viable plan for identifying your failover nodes by their
hostnames (even if its just knowing specific names), for your original
idea is predicated on such a plan. Therefore, instead of applying
that logic to choose which node declaration to apply, you can instead
use it either within node declarations or without to set your magic
variable or class parameter, or to include a different / extra class.
For example:
node /.*our-db\d+/ {
$failover = $hostname ? { /our-db\d+/ = false, default = true }
include system:our_db
}
John
--
You received this message because you
[Puppet Users] [centos 6] error downloading facter-1.6.0-2.el6.noarch.rpm from epel
I'm trying to install puppet-server into my centos6 server... but i cann't find the dependency facter anywhere on the internet :(( Any help/ideas ? With kind regards, ~remke http://www.craigdunn.org/2010/08/part-1-installing-puppet-2-6-1-on-centos-with-yumrpm/ [root@localhost yum.repos.d]# yum --enablerepo=epel,epel-puppet,centosplus,extras install puppet-server Loaded plugins: fastestmirror, priorities Loading mirror speeds from cached hostfile * base: ftp.tudelft.nl * centosplus: ftp.uni-bayreuth.de * extras: ftp.tudelft.nl * updates: ftp.tudelft.nl base | 3.7 kB 00:00 centosplus | 3.5 kB 00:00 centosplus/primary_db | 1.4 MB 00:00 http://download.fedoraproject.org/pub/epel/6/x86_64/repodata/repomd.xml: [Errno 12] Timeout on http://nl.mirror.eurid.eu/epel/6/x86_64/repodata/repomd.xml: (28, 'Operation too slow. Less than 1 bytes/sec transfered the last 30 seconds') Trying other mirror. extras | 951 B 00:00 updates | 3.5 kB 00:00 53 packages excluded due to repository priority protections Setting up Install Process Resolving Dependencies -- Running transaction check --- Package puppet-server.noarch 0:0.25.5-1.el6 set to be updated -- Processing Dependency: puppet = 0.25.5-1.el6 for package: puppet-server-0.25.5-1.el6.noarch -- Running transaction check --- Package puppet.noarch 0:0.25.5-1.el6 set to be updated -- Processing Dependency: facter = 1.5 for package: puppet-0.25.5-1.el6.noarch -- Processing Dependency: ruby-shadow for package: puppet-0.25.5-1.el6.noarch -- Processing Dependency: ruby-augeas for package: puppet-0.25.5-1.el6.noarch -- Processing Dependency: ruby(selinux) for package: puppet-0.25.5-1.el6.noarch -- Running transaction check --- Package facter.noarch 0:1.6.0-2.el6 set to be updated --- Package libselinux-ruby.x86_64 0:2.0.94-2.el6 set to be updated --- Package ruby-augeas.x86_64 0:0.3.0-1.el6 set to be updated -- Processing Dependency: augeas-libs = 0.5.1 for package: ruby-augeas-0.3.0-1.el6.x86_64 -- Processing Dependency: libaugeas.so.0(AUGEAS_0.8.0)(64bit) for package: ruby-augeas-0.3.0-1.el6.x86_64 -- Processing Dependency: libaugeas.so.0(AUGEAS_0.1.0)(64bit) for package: ruby-augeas-0.3.0-1.el6.x86_64 -- Processing Dependency: libaugeas.so.0()(64bit) for package: ruby-augeas-0.3.0-1.el6.x86_64 --- Package ruby-shadow.x86_64 0:1.4.1-13.el6 set to be updated -- Running transaction check --- Package augeas-libs.x86_64 0:0.7.2-3.el6 set to be updated -- Finished Dependency Resolution Dependencies Resolved === Package Arch Version RepositorySize === Installing: puppet-server noarch 0.25.5-1.el6 epel 22 k Installing for dependencies: augeas-libs x86_64 0.7.2-3.el6 base 289 k facter noarch 1.6.0-2.el6 epel 61 k libselinux-ruby x86_64 2.0.94-2.el6 base 98 k puppet
[Puppet Users] Help Getting Puppet to run on HP-UX (as a client)
OK I need a little help here. I am trying to get puppet working on an HP-UX 11.31 server. I have ruby, ruby gems, facter and puppet installed (albeit not correctly). So, When i try to start the puppet daemon i get these errors. Thanks in advance. /opt/iexpress/ruby/sbin/puppetd --trace --server puppet --verbose warning: iconv couldn't be loaded, which is required for UTF-8/UTF-16 conversions /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/network/http/ compression.rb:13:in `require' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/network/http/ compression.rb:13:in `module:Active' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/network/http/ compression.rb:12:in `module:Compression' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/network/http/ compression.rb:3:in `top (required)' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/type/file/ content.rb:7:in `require' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/type/file/ content.rb:7:in `top (required)' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/type/file.rb:784:in `require' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/type/file.rb:784:in `top (required)' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/util/autoload.rb: 79:in `load' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/util/autoload.rb: 79:in `block in load' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/util/autoload.rb: 75:in `each' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/util/autoload.rb: 75:in `load' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/metatype/manager.rb: 124:in `type' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/resource.rb:228:in `resource_type' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/resource.rb:417:in `parse_title' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/resource.rb:234:in `to_hash' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/resource.rb:243:in `uniqueness_key' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/resource/catalog.rb: 433:in `resource' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/util/settings.rb: 565:in `block in to_catalog' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/util/settings.rb: 562:in `each' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/util/settings.rb: 562:in `to_catalog' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/util/settings.rb: 621:in `block in use' /opt/iexpress/ruby/lib/ruby/1.9.1/sync.rb:225:in `sync_synchronize' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/util/settings.rb: 615:in `use' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/application/ agent.rb:442:in `setup' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/application.rb: 305:in `block (2 levels) in run' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/application.rb: 411:in `hook' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/application.rb: 305:in `block in run' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/application.rb: 402:in `exit_on_fail' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/application.rb: 305:in `run' /opt/iexpress/ruby/sbin/puppetd:4:in `main' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/util/autoload.rb: 87:in `rescue in block in load' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/util/autoload.rb: 78:in `block in load' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/util/autoload.rb: 75:in `each' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/util/autoload.rb: 75:in `load' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/metatype/manager.rb: 124:in `type' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/resource.rb:228:in `resource_type' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/resource.rb:417:in `parse_title' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/resource.rb:234:in `to_hash' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/resource.rb:243:in `uniqueness_key' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/resource/catalog.rb: 433:in `resource' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/util/settings.rb: 565:in `block in to_catalog' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/util/settings.rb: 562:in `each' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/util/settings.rb: 562:in `to_catalog' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/util/settings.rb: 621:in `block in use' /opt/iexpress/ruby/lib/ruby/1.9.1/sync.rb:225:in `sync_synchronize' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/util/settings.rb: 615:in `use' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/application/ agent.rb:442:in `setup' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/application.rb: 305:in `block (2 levels) in run' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/application.rb: 411:in `hook' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/application.rb: 305:in `block in run' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/application.rb: 402:in `exit_on_fail' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/application.rb: 305:in `run'
[Puppet Users] zypprepo on sles 10.3 and 10.4
Hi, I've used the zypprepo type successfully on sles 11.1 to register my server to a repo. However, I can't get it to work on sles 10.3 and 10.4. However using the zypper sa command I can easily register my repos but it seems impossible to make it work using zypprepos. My /etc/ zypp/zypp.conf file exist with the correct information that I specified in my manifest, but there seems to be a problem to add my repos to the repos list. Any help would be appreciated ! Thanks Koukoum -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] [centos 6] error downloading facter-1.6.0-2.el6.noarch.rpm from epel
why don't you just forget yum and use gem instead ? 2011/8/17 remke r.schuurm...@gmail.com: I'm trying to install puppet-server into my centos6 server... but i cann't find the dependency facter anywhere on the internet :(( Any help/ideas ? With kind regards, ~remke http://www.craigdunn.org/2010/08/part-1-installing-puppet-2-6-1-on-centos-with-yumrpm/ [root@localhost yum.repos.d]# yum --enablerepo=epel,epel-puppet,centosplus,extras install puppet-server Loaded plugins: fastestmirror, priorities Loading mirror speeds from cached hostfile * base: ftp.tudelft.nl * centosplus: ftp.uni-bayreuth.de * extras: ftp.tudelft.nl * updates: ftp.tudelft.nl base | 3.7 kB 00:00 centosplus | 3.5 kB 00:00 centosplus/primary_db | 1.4 MB 00:00 http://download.fedoraproject.org/pub/epel/6/x86_64/repodata/repomd.xml: [Errno 12] Timeout on http://nl.mirror.eurid.eu/epel/6/x86_64/repodata/repomd.xml: (28, 'Operation too slow. Less than 1 bytes/sec transfered the last 30 seconds') Trying other mirror. extras | 951 B 00:00 updates | 3.5 kB 00:00 53 packages excluded due to repository priority protections Setting up Install Process Resolving Dependencies -- Running transaction check --- Package puppet-server.noarch 0:0.25.5-1.el6 set to be updated -- Processing Dependency: puppet = 0.25.5-1.el6 for package: puppet-server-0.25.5-1.el6.noarch -- Running transaction check --- Package puppet.noarch 0:0.25.5-1.el6 set to be updated -- Processing Dependency: facter = 1.5 for package: puppet-0.25.5-1.el6.noarch -- Processing Dependency: ruby-shadow for package: puppet-0.25.5-1.el6.noarch -- Processing Dependency: ruby-augeas for package: puppet-0.25.5-1.el6.noarch -- Processing Dependency: ruby(selinux) for package: puppet-0.25.5-1.el6.noarch -- Running transaction check --- Package facter.noarch 0:1.6.0-2.el6 set to be updated --- Package libselinux-ruby.x86_64 0:2.0.94-2.el6 set to be updated --- Package ruby-augeas.x86_64 0:0.3.0-1.el6 set to be updated -- Processing Dependency: augeas-libs = 0.5.1 for package: ruby-augeas-0.3.0-1.el6.x86_64 -- Processing Dependency: libaugeas.so.0(AUGEAS_0.8.0)(64bit) for package: ruby-augeas-0.3.0-1.el6.x86_64 -- Processing Dependency: libaugeas.so.0(AUGEAS_0.1.0)(64bit) for package: ruby-augeas-0.3.0-1.el6.x86_64 -- Processing Dependency: libaugeas.so.0()(64bit) for package: ruby-augeas-0.3.0-1.el6.x86_64 --- Package ruby-shadow.x86_64 0:1.4.1-13.el6 set to be updated -- Running transaction check --- Package augeas-libs.x86_64 0:0.7.2-3.el6 set to be updated -- Finished Dependency Resolution Dependencies Resolved === Package Arch Version Repository Size === Installing: puppet-server noarch 0.25.5-1.el6 epel 22 k Installing for dependencies: augeas-libs x86_64 0.7.2-3.el6 base 289 k facter noarch 1.6.0-2.el6 epel 61 k libselinux-ruby x86_64 2.0.94-2.el6 base 98 k puppet noarch 0.25.5-1.el6 epel 758 k ruby-augeas x86_64 0.3.0-1.el6 epel 20 k ruby-shadow x86_64 1.4.1-13.el6 epel 11 k Transaction Summary === Install 7 Package(s) Upgrade 0 Package(s) -- You received this message because you are subscribed to the Google Groups Puppet Users group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/RpyLzZL0P1YJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Help Getting Puppet to run on HP-UX (as a client)
Hi, what puppet version are you using? We were able to run puppet 2.6.2 with ruby 1.8.4 and 1.8.7 Please note also bug http://projects.puppetlabs.com/issues/8893 reagrding users with shared homedirs. You might also want to check the puppet HP-UX wiki site: http://projects.puppetlabs.com/projects/puppet/wiki/Puppet_HP-UX Kind regards, Martin On 08/17/2011 03:35 PM, jmckin...@thezenith.com wrote: OK I need a little help here. I am trying to get puppet working on an HP-UX 11.31 server. I have ruby, ruby gems, facter and puppet installed (albeit not correctly). So, When i try to start the puppet daemon i get these errors. Thanks in advance. /opt/iexpress/ruby/sbin/puppetd --trace --server puppet --verbose warning: iconv couldn't be loaded, which is required for UTF-8/UTF-16 conversions /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/network/http/ compression.rb:13:in `require' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/network/http/ compression.rb:13:in `module:Active' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/network/http/ compression.rb:12:in `module:Compression' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/network/http/ compression.rb:3:in `top (required)' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/type/file/ content.rb:7:in `require' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/type/file/ content.rb:7:in `top (required)' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/type/file.rb:784:in `require' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/type/file.rb:784:in `top (required)' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/util/autoload.rb: 79:in `load' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/util/autoload.rb: 79:in `block in load' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/util/autoload.rb: 75:in `each' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/util/autoload.rb: 75:in `load' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/metatype/manager.rb: 124:in `type' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/resource.rb:228:in `resource_type' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/resource.rb:417:in `parse_title' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/resource.rb:234:in `to_hash' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/resource.rb:243:in `uniqueness_key' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/resource/catalog.rb: 433:in `resource' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/util/settings.rb: 565:in `block in to_catalog' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/util/settings.rb: 562:in `each' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/util/settings.rb: 562:in `to_catalog' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/util/settings.rb: 621:in `block in use' /opt/iexpress/ruby/lib/ruby/1.9.1/sync.rb:225:in `sync_synchronize' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/util/settings.rb: 615:in `use' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/application/ agent.rb:442:in `setup' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/application.rb: 305:in `block (2 levels) in run' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/application.rb: 411:in `hook' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/application.rb: 305:in `block in run' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/application.rb: 402:in `exit_on_fail' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/application.rb: 305:in `run' /opt/iexpress/ruby/sbin/puppetd:4:in `main' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/util/autoload.rb: 87:in `rescue in block in load' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/util/autoload.rb: 78:in `block in load' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/util/autoload.rb: 75:in `each' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/util/autoload.rb: 75:in `load' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/metatype/manager.rb: 124:in `type' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/resource.rb:228:in `resource_type' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/resource.rb:417:in `parse_title' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/resource.rb:234:in `to_hash' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/resource.rb:243:in `uniqueness_key' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/resource/catalog.rb: 433:in `resource' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/util/settings.rb: 565:in `block in to_catalog' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/util/settings.rb: 562:in `each' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/util/settings.rb: 562:in `to_catalog' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/util/settings.rb: 621:in `block in use' /opt/iexpress/ruby/lib/ruby/1.9.1/sync.rb:225:in `sync_synchronize' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/util/settings.rb: 615:in `use'
Re: [Puppet Users] chaining resources problem
Hi, Thanks for the replies... Currently, I made it work using stages. But I'll try the approach of putting my resource chaining at the bottom and let you know if it works... Regards. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/hCBlfMcy49wJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
RE: [Puppet Users] Help Getting Puppet to run on HP-UX (as a client)
I am using puppet version 2.7.1 Ruby version 1.9.1 root@pasco:~# ruby --version ruby 1.9.1p430 (2010-08-16 revision 28998) [ia64-hpux11.23] root@pasco:~# puppet --version 2.7.1 -- Regards, Jody R. McKinzie Sr. UNIX Administrator Zenith Insurance Company Desk: (941) 906-5177 Cell: (941) 806-8205 Fax: (941) 906-7945 Email: jmckin...@thezenith.com www.TheZenith.com -Original Message- From: puppet-users@googlegroups.com [mailto:puppet-users@googlegroups.com] On Behalf Of Martin Alfke Sent: Wednesday, August 17, 2011 11:21 AM To: puppet-users@googlegroups.com Subject: Re: [Puppet Users] Help Getting Puppet to run on HP-UX (as a client) Hi, what puppet version are you using? We were able to run puppet 2.6.2 with ruby 1.8.4 and 1.8.7 Please note also bug http://projects.puppetlabs.com/issues/8893 reagrding users with shared homedirs. You might also want to check the puppet HP-UX wiki site: http://projects.puppetlabs.com/projects/puppet/wiki/Puppet_HP-UX Kind regards, Martin On 08/17/2011 03:35 PM, jmckin...@thezenith.com wrote: OK I need a little help here. I am trying to get puppet working on an HP-UX 11.31 server. I have ruby, ruby gems, facter and puppet installed (albeit not correctly). So, When i try to start the puppet daemon i get these errors. Thanks in advance. /opt/iexpress/ruby/sbin/puppetd --trace --server puppet --verbose warning: iconv couldn't be loaded, which is required for UTF-8/UTF-16 conversions /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/network/http/ compression.rb:13:in `require' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/network/http/ compression.rb:13:in `module:Active' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/network/http/ compression.rb:12:in `module:Compression' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/network/http/ compression.rb:3:in `top (required)' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/type/file/ content.rb:7:in `require' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/type/file/ content.rb:7:in `top (required)' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/type/file.rb:784:in `require' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/type/file.rb:784:in `top (required)' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/util/autoload.rb: 79:in `load' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/util/autoload.rb: 79:in `block in load' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/util/autoload.rb: 75:in `each' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/util/autoload.rb: 75:in `load' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/metatype/manager.rb: 124:in `type' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/resource.rb:228:in `resource_type' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/resource.rb:417:in `parse_title' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/resource.rb:234:in `to_hash' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/resource.rb:243:in `uniqueness_key' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/resource/catalog.rb: 433:in `resource' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/util/settings.rb: 565:in `block in to_catalog' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/util/settings.rb: 562:in `each' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/util/settings.rb: 562:in `to_catalog' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/util/settings.rb: 621:in `block in use' /opt/iexpress/ruby/lib/ruby/1.9.1/sync.rb:225:in `sync_synchronize' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/util/settings.rb: 615:in `use' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/application/ agent.rb:442:in `setup' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/application.rb: 305:in `block (2 levels) in run' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/application.rb: 411:in `hook' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/application.rb: 305:in `block in run' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/application.rb: 402:in `exit_on_fail' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/application.rb: 305:in `run' /opt/iexpress/ruby/sbin/puppetd:4:in `main' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/util/autoload.rb: 87:in `rescue in block in load' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/util/autoload.rb: 78:in `block in load' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/util/autoload.rb: 75:in `each' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/util/autoload.rb: 75:in `load' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/metatype/manager.rb: 124:in `type' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/resource.rb:228:in `resource_type' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/resource.rb:417:in `parse_title' /opt/iexpress/ruby/lib/ruby/site_ruby/1.9.1/puppet/resource.rb:234:in `to_hash'
[Puppet Users] Dependency Cycle Weirdness
If I have:
class service::common {
file {
'/etc/foo':
ensure = directory;
'/etc/init.d/ss-functions':
content = template('service/etc/init.d/ss-functions.erb'),
require = File['/etc/foo'],
}
}
class platform::common {
include service::common
File {
require = Class['service::common']
}
}
then puppet is telling me:
Aug 17 09:47:01 test01 puppet-agent[14530]: Could not apply complete
catalog: Found 1 dependency cycle: (File[/etc/foo] = Class[Service::Common]
= File[/etc/foo]) Try the '--graph' option and opening the resulting '.dot'
file in OmniGraffle or GraphViz
I don't get it. How does /etc/foo depend on Service::Common? I mean, it's IN
that class... is that why it depends on it? Debugging these is awful...
Doug,
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Announce: Dashboard 1.2rc7
Greetings, Welcome to another Release Candidate for Puppet Dashboard (number 7). This release is available for download at: http://downloads.puppetlabs.com/dashboard/ We have included Debian and RPM packages as well as a tarball. See the Verifying Puppet Download section at: http://projects.puppetlabs.com/projects/puppet/wiki/Downloading_Puppet Please report feedback via the Puppet Labs Redmine site, using an affected version of 1.2rc7 http://projects.puppetlabs.com/projects/dashboard Documentation is available at: http://docs.puppetlabs.com/dashboard/index.html Highlights in 1.2rc7 === * Debian package now reports proper version * Ability to adjust log verbosity (no more raw SQL queries for every page view) * Updated 500 error page * Ensure all references to nodes are named node and not hostname, host, machine, etc 1.2rc7 === 735925f (#9032) Update Debian package to ensure VERSION is packaged 620de4e (#8251 and #8042) Don't use our own logger a2a97ab (#8796) Re-write misleading 500 error message 6b525b1 (#5845) Changed host to node in UI. 49cca0b Add document outlining preferred contribution methods 1.2 series Highlights Include: * Moved to Apache 2.0 License * LOTS of UI improvements * Updated version of Rails * Now Requires Ruby 1.8.7 * Has Delayed Jobs (puppet-dashboard-workers) for async actions * Several performance improvements More Details === 90f5ce0 (#8488) Move tfoot before tbody in reports table ee1f182 (#8488) Make columns consistent between report views e54ecb8 (#8790) Fix reports page column display and alignment 947dcee (#8748) Put sensible umask on pids and logs that delayed_job creates 4ef96b6 (#8785) Close a directory that we open 0bfbbf6 (#8785) - Revert (#8748) Upgrade vendored daemons gem to fix umask on pids 3f88c7f (#8748) Fix my forgetting to add a vendored gem 2f636a9 Allow setting of RUBY for the workers on redhat systems 651511c (#8748) Upgrade vendored daemons gem to fix umask on pids 3a65fd0 (#8694) Add backtrace info to DelayedJobFailure bf22939 Add document outlining preferred contribution methods 803be4f (#8745) Update gitignore to not exclude tmp during tarball creation 45338a (#8691) Fix the order of changed and unchanged resources on the report summary 7653800 Provide clearer error message when report host, kind and time are not unique e86526f (#8686) Handle concurrent DelayedJob workers importing for same node 88771ec (#8589) Report events are now ordered by name. 8bd0ffb (#8544) Make empty inspected resources red. d036276 (#8505) Update the default date stringification. bb99ed9 Properly Quote RAILS_ROOT in get_app_version method 08717e1 (#8508) Add delayed job worker script for debian/ubuntu package 2eef4f4 (#8529) Remove unneeded a print statement from sass.rb af8b6e9 (#8500) Replace README with a smaller one dff2256 (#8499) Update the usage of mktemp in Rakefile to work on mac 3f0afca (#8484) Nodes for this group heading now appears correctly d389d8b (#7568) Relicense to Apache-2.0 License 57d0122 (#8276) Remove MaRuKu dependency a44d9ff (#8262) Show node groups even when node classification is disabled 3996b29 (#8262) Create callbacks for each section of node_classification partial 5dac13a (#8199) Move 'failed' resources to the top when viewing report events 2a3a73c (#7967) Improved user-facing design for delayed job warnings c78b85a (#8266) Back-end logic for splitting read and unread DJ failures. 15bba31 (#8121) Properly generate CSS from SASS in production. a9abf41 (#8101) Updated to new version of Tipsy plugin 9cb5e55 (Maint) More generalized tabbed interface fbe11aa (#8196) Adjust content width based on body classes. e756c25 (#8196) Add a body class describing sidebar state. 23cbef1 (#8196) Clean up body class manipulation. 3670e2b (#8146) Change default DASHBOARD_URL in external_node to localhost 81ec3c0 (#8090) Update .gitignore to ignore plugin files 6f117fc (#8022) Don't fail when installing plugin without `public` directory 07a9407 (#8022) Create a hook for plugins to add items to head in layout 64be352 (#7967) Add default value for read column of delayed_job_failures 240c548 (#7967) Infrastructure for displaying background failures. 8038cce (#7389) Don't auto-start DelayedJob workers. 933ae04 (#7389) Cheaper unique filenames for spooled reports. b4384eb (#7398) Support externally managed DelayedJob workers. 184e65b (#7689) Rake task to support parallel report POSTing. 2333c08 (#5947) Rename Destroy button to Delete 2fb0ac1 (#7976) Fixed static debug data in view 393970d (#7976) Node filter links in sidebar work in all cases 4ba3d23 (#7398) Configurable DelayedJob worker count. e839884 (#7938) Delayed import from file, not YAML string. d24c323 (#7973) Refactor colors for changed/unchanged 58c2b52 (#7398) Use DelayedJob for background processing. 6aefc60 (#7938) Add daemons gem to support DelayedJob 7395369 (#7398) Vendor DelayedJob for background tasks. 05040d9 (#7958) Allow plugins to add top level navigation c4d2f26 (#7597) Better
[Puppet Users] Puppet agent hangs for over a minute, no info in --summarize
Hoping you guys might be able to help me out, I'm not sure what's wrong but puppet agent hangs for over a minute, no resource spikes (CPU, memory, etc all stay basically the same as without starting puppet, barely a blip, and I've got more than enough headroom). It's not a serious issue for continuous usage, but really, really annoying when testing the manifests I'm starting to create. Below is a snippet of the agent's output when run with: puppet agent --test --noop --debug --trace --verbose --waitforcert 0 Master is running as: puppet master --no-daemonize --debug --trace --logdest --summarize Agent log segment: [snip] debug: /File[/var/lib/puppet/state]: Autorequiring File[/var/lib/ puppet] debug: Finishing transaction 70059796256340 debug: Using cached certificate for ca debug: Using cached certificate for ubuntu05.wic.west.com debug: Finishing transaction 70059798542500 debug: Loaded state in 0.00 seconds debug: Using cached certificate for ca debug: Using cached certificate for ubuntu05.wic.west.com debug: Using cached certificate_revocation_list for ca debug: catalog supports formats: b64_zlib_yaml dot marshal pson raw yaml; using pson [snip] debug: Storing state debug: Stored state in 0.01 seconds notice: Finished catalog run in 0.16 seconds Changes: Events: Noop: 2 Total: 2 Resources: Total: 12 Out of sync: 2 Skipped: 6 Time: Filebucket: 0.00 Package: 0.00 Exec: 0.00 Config retrieval: 0.44 Total: 0.45 Last run: 1313600473 debug: Using cached certificate for ca debug: Using cached certificate for ubuntu05.wic.west.com debug: Using cached certificate_revocation_list for ca debug: Value of 'preferred_serialization_format' (pson) is invalid for report, using default (b64_zlib_yaml) debug: report supports formats: b64_zlib_yaml marshal raw yaml; using b64_zlib_yaml Master Log: info: Expiring the node cache of ubuntu05.wic.west.com info: Not using expired node for ubuntu05.wic.west.com from cache; expired at Wed Aug 17 13:00:12 -0400 2011 info: Caching node for ubuntu05.wic.west.com debug: Exec[pwd]: Adding default for logoutput debug: Exec[pwd]: Adding default for path debug: Exec[whoami]: Adding default for logoutput debug: Exec[whoami]: Adding default for path notice: Compiled catalog for ubuntu05.wic.west.com in environment production in 0.04 seconds Agent hangs between: debug: Loaded state in 0.00 seconds debug: Using cached certificate for ca It sits there for over a minute before moving on. I've tried an agent on a different system from the master, agent on the same system (as above), they have the exact same behavior. At first I thought it was the manifest I created (nothing complicated, followed ntp stuff and adapted it slightly for the most part), but running this with absolutely no manifests being applied for the node hangs for the same period of time, in the same place. I'm using webrick for the server, but since right now I have a single client, and that's being fired off manually (not in cron, not a long running client, etc), using webrick shouldn't be an issue as far as I know. I setup minimal config files, (defaults only) as I originally thought maybe the master was delaying things due to not finding the configs it wanted. It reduced the logs, but didn't speed it up at all. I setup everything per the simple recipe, and haven't gone much further than that. Any info needed should be easy to post, but this is just currently an annoyance more than anything. Once I have everything running, I should be fine to have the minute+ delay in with every sync, but for testing manifests, etc it's really slowing things down. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Using back-ported create_resources in 2.6.x
Does anyone have some examples of using this create_resources
function, https://github.com/puppetlabs/puppetlabs-create_resources,
? Based on the README example I can't figure out exactly how to
change from using defines to using this function. Maybe I
misunderstand the purpose of create_resources...is it to replace
defines, or is it to allow ENCs (for example) to use a define?
Below is an example of a define I use for apache virtual hosts. From
the example on the functions readme, does class webserver::instances
use the information in $instances? So if I wanted to create files /
directories from the information in $instances, would that be done in
class webserver::instances or else where?
Here's the example...
node 'webserver' {
apache::vhost {
'drupal-multisite1':
domain = 'com',
docroot = '/var/www/example2.com/html',
options = 'None',
override= 'All',
protocol= 'http';
'drupal-multisite2':
domain = 'com',
docroot = '/var/www/example2.com/html',
create_docroot = false,
options = 'None',
override= 'All',
protocol= 'http';
}
}
define apache::vhost (
$protocol='http',
$cname=$name,
$domain=false,
$server_alias=www.$cname.$domain,
$alias_list=false,
$docroot=false,
$create_docroot=true,
$docroot_owner=false,
$docroot_group=false,
$docroot_mode=false,
$options=false,
$sendfile=true,
$override='None',
$order='allow,deny',
$allowfrom='all',
$denyfrom=false,
$source=false
) {
host{ ${name}.$domain:
ensure = present,
host_aliases= [ $name ],
ip = $ipaddress_eth0,
}
if $create_docroot != false {
file {
$docroot:
ensure = directory,
owner = $docroot_owner ? {
false = undef,
default = $docroot_owner,
},
group = $docroot_group ? {
false = undef,
default = $docroot_group,
},
mode= $docroot_mode ? {
false = undef,
default = $docroot_mode,
},
require = Package['httpd'];
}
}
file { /etc/httpd/conf.d/$cname.conf:
ensure = present,
owner = 'root',
group = 'root',
mode= 644,
content = $source ? {
false = template('apache/
virtualhost_conf.erb'),
default = $source,
},
require = Package['httpd'],
notify = Exec['reload-apache'],
}
}
Thanks
- Trey
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Dependency Cycle Weirdness
Don't think you need to include if there is a require
On Aug 17, 2011 9:50 AM, Douglas Garstang doug.garst...@gmail.com wrote:
If I have:
class service::common {
file {
'/etc/foo':
ensure = directory;
'/etc/init.d/ss-functions':
content = template('service/etc/init.d/ss-functions.erb'),
require = File['/etc/foo'],
}
}
class platform::common {
include service::common
File {
require = Class['service::common']
}
}
then puppet is telling me:
Aug 17 09:47:01 test01 puppet-agent[14530]: Could not apply complete
catalog: Found 1 dependency cycle: (File[/etc/foo] =
Class[Service::Common]
= File[/etc/foo]) Try the '--graph' option and opening the resulting
'.dot'
file in OmniGraffle or GraphViz
I don't get it. How does /etc/foo depend on Service::Common? I mean, it's
IN
that class... is that why it depends on it? Debugging these is awful...
Doug,
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Puppet agent hangs for over a minute, no info in --summarize
Do you have any arp entries for which there is no PTR? On Aug 17, 2011 10:23 AM, Dragonfyre13 dragonfyr...@gmail.com wrote: Hoping you guys might be able to help me out, I'm not sure what's wrong but puppet agent hangs for over a minute, no resource spikes (CPU, memory, etc all stay basically the same as without starting puppet, barely a blip, and I've got more than enough headroom). It's not a serious issue for continuous usage, but really, really annoying when testing the manifests I'm starting to create. Below is a snippet of the agent's output when run with: puppet agent --test --noop --debug --trace --verbose --waitforcert 0 Master is running as: puppet master --no-daemonize --debug --trace --logdest --summarize Agent log segment: [snip] debug: /File[/var/lib/puppet/state]: Autorequiring File[/var/lib/ puppet] debug: Finishing transaction 70059796256340 debug: Using cached certificate for ca debug: Using cached certificate for ubuntu05.wic.west.com debug: Finishing transaction 70059798542500 debug: Loaded state in 0.00 seconds debug: Using cached certificate for ca debug: Using cached certificate for ubuntu05.wic.west.com debug: Using cached certificate_revocation_list for ca debug: catalog supports formats: b64_zlib_yaml dot marshal pson raw yaml; using pson [snip] debug: Storing state debug: Stored state in 0.01 seconds notice: Finished catalog run in 0.16 seconds Changes: Events: Noop: 2 Total: 2 Resources: Total: 12 Out of sync: 2 Skipped: 6 Time: Filebucket: 0.00 Package: 0.00 Exec: 0.00 Config retrieval: 0.44 Total: 0.45 Last run: 1313600473 debug: Using cached certificate for ca debug: Using cached certificate for ubuntu05.wic.west.com debug: Using cached certificate_revocation_list for ca debug: Value of 'preferred_serialization_format' (pson) is invalid for report, using default (b64_zlib_yaml) debug: report supports formats: b64_zlib_yaml marshal raw yaml; using b64_zlib_yaml Master Log: info: Expiring the node cache of ubuntu05.wic.west.com info: Not using expired node for ubuntu05.wic.west.com from cache; expired at Wed Aug 17 13:00:12 -0400 2011 info: Caching node for ubuntu05.wic.west.com debug: Exec[pwd]: Adding default for logoutput debug: Exec[pwd]: Adding default for path debug: Exec[whoami]: Adding default for logoutput debug: Exec[whoami]: Adding default for path notice: Compiled catalog for ubuntu05.wic.west.com in environment production in 0.04 seconds Agent hangs between: debug: Loaded state in 0.00 seconds debug: Using cached certificate for ca It sits there for over a minute before moving on. I've tried an agent on a different system from the master, agent on the same system (as above), they have the exact same behavior. At first I thought it was the manifest I created (nothing complicated, followed ntp stuff and adapted it slightly for the most part), but running this with absolutely no manifests being applied for the node hangs for the same period of time, in the same place. I'm using webrick for the server, but since right now I have a single client, and that's being fired off manually (not in cron, not a long running client, etc), using webrick shouldn't be an issue as far as I know. I setup minimal config files, (defaults only) as I originally thought maybe the master was delaying things due to not finding the configs it wanted. It reduced the logs, but didn't speed it up at all. I setup everything per the simple recipe, and haven't gone much further than that. Any info needed should be easy to post, but this is just currently an annoyance more than anything. Once I have everything running, I should be fine to have the minute+ delay in with every sync, but for testing manifests, etc it's really slowing things down. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Using back-ported create_resources in 2.6.x
On Wed, Aug 17, 2011 at 10:27 AM, treydock treyd...@gmail.com wrote:
Does anyone have some examples of using this create_resources
function, https://github.com/puppetlabs/puppetlabs-create_resources,
? Based on the README example I can't figure out exactly how to
change from using defines to using this function. Maybe I
misunderstand the purpose of create_resources...is it to replace
defines, or is it to allow ENCs (for example) to use a define?
The purpose of create resources is not to replace define, but rather
to declare resource from a hash. This is typically used to work around
ENC limitation of class only so you can provide a hash to generate
resources for a node.
Below is an example of a define I use for apache virtual hosts. From
the example on the functions readme, does class webserver::instances
use the information in $instances? So if I wanted to create files /
directories from the information in $instances, would that be done in
class webserver::instances or else where?
Here's the example...
node 'webserver' {
apache::vhost {
'drupal-multisite1':
domain = 'com',
docroot = '/var/www/example2.com/html',
options = 'None',
override = 'All',
protocol = 'http';
'drupal-multisite2':
domain = 'com',
docroot = '/var/www/example2.com/html',
create_docroot = false,
options = 'None',
override = 'All',
protocol = 'http';
}
}
So if you use create resource, instead of the section above would be:
$vhost = { 'drupal-multisite1' = { domain = 'com', ... } }
create_resource (apache::vhost, $vhost)
It would not change your existing define apache::vhost.
Thanks,
Nan
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Dependency Cycle Weirdness
Oh. I didn't realise that. Thought it was darn Thanks.
On Wed, Aug 17, 2011 at 10:52 AM, Scott Smith sc...@ohlol.net wrote:
Don't think you need to include if there is a require
On Aug 17, 2011 9:50 AM, Douglas Garstang doug.garst...@gmail.com
wrote:
If I have:
class service::common {
file {
'/etc/foo':
ensure = directory;
'/etc/init.d/ss-functions':
content = template('service/etc/init.d/ss-functions.erb'),
require = File['/etc/foo'],
}
}
class platform::common {
include service::common
File {
require = Class['service::common']
}
}
then puppet is telling me:
Aug 17 09:47:01 test01 puppet-agent[14530]: Could not apply complete
catalog: Found 1 dependency cycle: (File[/etc/foo] =
Class[Service::Common]
= File[/etc/foo]) Try the '--graph' option and opening the resulting
'.dot'
file in OmniGraffle or GraphViz
I don't get it. How does /etc/foo depend on Service::Common? I mean, it's
IN
that class... is that why it depends on it? Debugging these is awful...
Doug,
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
--
Regards,
Douglas Garstang
http://www.linkedin.com/in/garstang
Email: doug.garst...@gmail.com
Cell: +1-805-340-5627
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Dependency Cycle Weirdness
Actually, no, I think you DO need it.
On Wed, Aug 17, 2011 at 11:30 AM, Douglas Garstang
doug.garst...@gmail.comwrote:
Oh. I didn't realise that. Thought it was darn Thanks.
On Wed, Aug 17, 2011 at 10:52 AM, Scott Smith sc...@ohlol.net wrote:
Don't think you need to include if there is a require
On Aug 17, 2011 9:50 AM, Douglas Garstang doug.garst...@gmail.com
wrote:
If I have:
class service::common {
file {
'/etc/foo':
ensure = directory;
'/etc/init.d/ss-functions':
content = template('service/etc/init.d/ss-functions.erb'),
require = File['/etc/foo'],
}
}
class platform::common {
include service::common
File {
require = Class['service::common']
}
}
then puppet is telling me:
Aug 17 09:47:01 test01 puppet-agent[14530]: Could not apply complete
catalog: Found 1 dependency cycle: (File[/etc/foo] =
Class[Service::Common]
= File[/etc/foo]) Try the '--graph' option and opening the resulting
'.dot'
file in OmniGraffle or GraphViz
I don't get it. How does /etc/foo depend on Service::Common? I mean,
it's IN
that class... is that why it depends on it? Debugging these is awful...
Doug,
--
You received this message because you are subscribed to the Google
Groups Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
--
Regards,
Douglas Garstang
http://www.linkedin.com/in/garstang
Email: doug.garst...@gmail.com
Cell: +1-805-340-5627
--
Regards,
Douglas Garstang
http://www.linkedin.com/in/garstang
Email: doug.garst...@gmail.com
Cell: +1-805-340-5627
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: Using back-ported create_resources in 2.6.x
Ah ok! That makes more sense now.
Thanks
- Trey
On Aug 17, 12:59 pm, Nan Liu n...@puppetlabs.com wrote:
On Wed, Aug 17, 2011 at 10:27 AM, treydock treyd...@gmail.com wrote:
Does anyone have some examples of using this create_resources
function,https://github.com/puppetlabs/puppetlabs-create_resources,
? Based on the README example I can't figure out exactly how to
change from using defines to using this function. Maybe I
misunderstand the purpose of create_resources...is it to replace
defines, or is it to allow ENCs (for example) to use a define?
The purpose of create resources is not to replace define, but rather
to declare resource from a hash. This is typically used to work around
ENC limitation of class only so you can provide a hash to generate
resources for a node.
Below is an example of a define I use for apache virtual hosts. From
the example on the functions readme, does class webserver::instances
use the information in $instances? So if I wanted to create files /
directories from the information in $instances, would that be done in
class webserver::instances or else where?
Here's the example...
node 'webserver' {
apache::vhost {
'drupal-multisite1':
domain = 'com',
docroot = '/var/www/example2.com/html',
options = 'None',
override = 'All',
protocol = 'http';
'drupal-multisite2':
domain = 'com',
docroot = '/var/www/example2.com/html',
create_docroot = false,
options = 'None',
override = 'All',
protocol = 'http';
}
}
So if you use create resource, instead of the section above would be:
$vhost = { 'drupal-multisite1' = { domain = 'com', ... } }
create_resource (apache::vhost, $vhost)
It would not change your existing define apache::vhost.
Thanks,
Nan
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: Puppet agent hangs for over a minute, no info in --summarize
Not as far as I can tell. I can honestly say I didn't look that far down the chain yet though, except that name resolution is occurring quickly and successfully for each of the boxes in play (I did test on fqdn, ip, and hostname FYI, so it's not a resolution issue). Note also that tcp and udp connections and packets between these servers are in the single digit ms range from my tests (although of course ARP resolution would be below either of these), and they are sitting behind a single switch prior to exiting to the primary lab switches. I would anticipate that puppet wouldn't be the only application with this issue if it were at the ARP level though, and I'm able to communicate between the systems fine via other methods. If you want to direct me to something on how I can confirm, I'm more than happy to try. Not entirely sure to check existing PTR entries against the ARP cache. On Aug 17, 12:54 pm, Scott Smith sc...@ohlol.net wrote: Do you have any arp entries for which there is no PTR? On Aug 17, 2011 10:23 AM, Dragonfyre13 dragonfyr...@gmail.com wrote: Hoping you guys might be able to help me out, I'm not sure what's wrong but puppet agent hangs for over a minute, no resource spikes (CPU, memory, etc all stay basically the same as without starting puppet, barely a blip, and I've got more than enough headroom). It's not a serious issue for continuous usage, but really, really annoying when testing the manifests I'm starting to create. Below is a snippet of the agent's output when run with: puppet agent --test --noop --debug --trace --verbose --waitforcert 0 Master is running as: puppet master --no-daemonize --debug --trace --logdest --summarize Agent log segment: [snip] debug: /File[/var/lib/puppet/state]: Autorequiring File[/var/lib/ puppet] debug: Finishing transaction 70059796256340 debug: Using cached certificate for ca debug: Using cached certificate for ubuntu05.wic.west.com debug: Finishing transaction 70059798542500 debug: Loaded state in 0.00 seconds debug: Using cached certificate for ca debug: Using cached certificate for ubuntu05.wic.west.com debug: Using cached certificate_revocation_list for ca debug: catalog supports formats: b64_zlib_yaml dot marshal pson raw yaml; using pson [snip] debug: Storing state debug: Stored state in 0.01 seconds notice: Finished catalog run in 0.16 seconds Changes: Events: Noop: 2 Total: 2 Resources: Total: 12 Out of sync: 2 Skipped: 6 Time: Filebucket: 0.00 Package: 0.00 Exec: 0.00 Config retrieval: 0.44 Total: 0.45 Last run: 1313600473 debug: Using cached certificate for ca debug: Using cached certificate for ubuntu05.wic.west.com debug: Using cached certificate_revocation_list for ca debug: Value of 'preferred_serialization_format' (pson) is invalid for report, using default (b64_zlib_yaml) debug: report supports formats: b64_zlib_yaml marshal raw yaml; using b64_zlib_yaml Master Log: info: Expiring the node cache of ubuntu05.wic.west.com info: Not using expired node for ubuntu05.wic.west.com from cache; expired at Wed Aug 17 13:00:12 -0400 2011 info: Caching node for ubuntu05.wic.west.com debug: Exec[pwd]: Adding default for logoutput debug: Exec[pwd]: Adding default for path debug: Exec[whoami]: Adding default for logoutput debug: Exec[whoami]: Adding default for path notice: Compiled catalog for ubuntu05.wic.west.com in environment production in 0.04 seconds Agent hangs between: debug: Loaded state in 0.00 seconds debug: Using cached certificate for ca It sits there for over a minute before moving on. I've tried an agent on a different system from the master, agent on the same system (as above), they have the exact same behavior. At first I thought it was the manifest I created (nothing complicated, followed ntp stuff and adapted it slightly for the most part), but running this with absolutely no manifests being applied for the node hangs for the same period of time, in the same place. I'm using webrick for the server, but since right now I have a single client, and that's being fired off manually (not in cron, not a long running client, etc), using webrick shouldn't be an issue as far as I know. I setup minimal config files, (defaults only) as I originally thought maybe the master was delaying things due to not finding the configs it wanted. It reduced the logs, but didn't speed it up at all. I setup everything per the simple recipe, and haven't gone much further than that. Any info needed should be easy to post, but this is just currently an annoyance more than anything. Once I have everything running, I should be fine to have the minute+ delay in with every sync, but for testing manifests, etc it's really slowing things down. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to
Re: [Puppet Users] Re: Puppet agent hangs for over a minute, no info in --summarize
Run arp -a If it hangs at any point, that is likely the problem. I'm not suggesting that arp is the problem, rather that you might have entries for IP addresses that have no PTR. See: http://projects.puppetlabs.com/issues/8247 -scott On Wed, Aug 17, 2011 at 12:40 PM, Dragonfyre13 dragonfyr...@gmail.comwrote: Not as far as I can tell. I can honestly say I didn't look that far down the chain yet though, except that name resolution is occurring quickly and successfully for each of the boxes in play (I did test on fqdn, ip, and hostname FYI, so it's not a resolution issue). Note also that tcp and udp connections and packets between these servers are in the single digit ms range from my tests (although of course ARP resolution would be below either of these), and they are sitting behind a single switch prior to exiting to the primary lab switches. I would anticipate that puppet wouldn't be the only application with this issue if it were at the ARP level though, and I'm able to communicate between the systems fine via other methods. If you want to direct me to something on how I can confirm, I'm more than happy to try. Not entirely sure to check existing PTR entries against the ARP cache. On Aug 17, 12:54 pm, Scott Smith sc...@ohlol.net wrote: Do you have any arp entries for which there is no PTR? On Aug 17, 2011 10:23 AM, Dragonfyre13 dragonfyr...@gmail.com wrote: Hoping you guys might be able to help me out, I'm not sure what's wrong but puppet agent hangs for over a minute, no resource spikes (CPU, memory, etc all stay basically the same as without starting puppet, barely a blip, and I've got more than enough headroom). It's not a serious issue for continuous usage, but really, really annoying when testing the manifests I'm starting to create. Below is a snippet of the agent's output when run with: puppet agent --test --noop --debug --trace --verbose --waitforcert 0 Master is running as: puppet master --no-daemonize --debug --trace --logdest --summarize Agent log segment: [snip] debug: /File[/var/lib/puppet/state]: Autorequiring File[/var/lib/ puppet] debug: Finishing transaction 70059796256340 debug: Using cached certificate for ca debug: Using cached certificate for ubuntu05.wic.west.com debug: Finishing transaction 70059798542500 debug: Loaded state in 0.00 seconds debug: Using cached certificate for ca debug: Using cached certificate for ubuntu05.wic.west.com debug: Using cached certificate_revocation_list for ca debug: catalog supports formats: b64_zlib_yaml dot marshal pson raw yaml; using pson [snip] debug: Storing state debug: Stored state in 0.01 seconds notice: Finished catalog run in 0.16 seconds Changes: Events: Noop: 2 Total: 2 Resources: Total: 12 Out of sync: 2 Skipped: 6 Time: Filebucket: 0.00 Package: 0.00 Exec: 0.00 Config retrieval: 0.44 Total: 0.45 Last run: 1313600473 debug: Using cached certificate for ca debug: Using cached certificate for ubuntu05.wic.west.com debug: Using cached certificate_revocation_list for ca debug: Value of 'preferred_serialization_format' (pson) is invalid for report, using default (b64_zlib_yaml) debug: report supports formats: b64_zlib_yaml marshal raw yaml; using b64_zlib_yaml Master Log: info: Expiring the node cache of ubuntu05.wic.west.com info: Not using expired node for ubuntu05.wic.west.com from cache; expired at Wed Aug 17 13:00:12 -0400 2011 info: Caching node for ubuntu05.wic.west.com debug: Exec[pwd]: Adding default for logoutput debug: Exec[pwd]: Adding default for path debug: Exec[whoami]: Adding default for logoutput debug: Exec[whoami]: Adding default for path notice: Compiled catalog for ubuntu05.wic.west.com in environment production in 0.04 seconds Agent hangs between: debug: Loaded state in 0.00 seconds debug: Using cached certificate for ca It sits there for over a minute before moving on. I've tried an agent on a different system from the master, agent on the same system (as above), they have the exact same behavior. At first I thought it was the manifest I created (nothing complicated, followed ntp stuff and adapted it slightly for the most part), but running this with absolutely no manifests being applied for the node hangs for the same period of time, in the same place. I'm using webrick for the server, but since right now I have a single client, and that's being fired off manually (not in cron, not a long running client, etc), using webrick shouldn't be an issue as far as I know. I setup minimal config files, (defaults only) as I originally thought maybe the master was delaying things due to not finding the configs it wanted. It reduced the logs, but didn't speed it up at all. I setup everything per the simple recipe, and haven't gone much further
[Puppet Users] Re: Using back-ported create_resources in 2.6.x
On Aug 17, 12:59 pm, Nan Liu n...@puppetlabs.com wrote:
On Wed, Aug 17, 2011 at 10:27 AM, treydock treyd...@gmail.com wrote:
Does anyone have some examples of using this create_resources
function,https://github.com/puppetlabs/puppetlabs-create_resources,
? Based on the README example I can't figure out exactly how to
change from using defines to using this function. Maybe I
misunderstand the purpose of create_resources...is it to replace
defines, or is it to allow ENCs (for example) to use a define?
The purpose of create resources is not to replace define, but rather
to declare resource from a hash. This is typically used to work around
ENC limitation of class only so you can provide a hash to generate
resources for a node.
Below is an example of a define I use for apache virtual hosts. From
the example on the functions readme, does class webserver::instances
use the information in $instances? So if I wanted to create files /
directories from the information in $instances, would that be done in
class webserver::instances or else where?
Here's the example...
node 'webserver' {
apache::vhost {
'drupal-multisite1':
domain = 'com',
docroot = '/var/www/example2.com/html',
options = 'None',
override = 'All',
protocol = 'http';
'drupal-multisite2':
domain = 'com',
docroot = '/var/www/example2.com/html',
create_docroot = false,
options = 'None',
override = 'All',
protocol = 'http';
}
}
So if you use create resource, instead of the section above would be:
$vhost = { 'drupal-multisite1' = { domain = 'com', ... } }
create_resource (apache::vhost, $vhost)
It would not change your existing define apache::vhost.
Thanks,
Nan
Having a bit of trouble now...and the error I'm getting is of no help.
Here's my parameter in node definition
$redmine_instances = {
'default' = {
docroot = '/var/www/rails/redmine',
db = 'redmine',
db_user = 'redmine',
db_pass = '',
},
}
create_resources('redmine::instance', $redmine_instances)
And the defines this is going to...
define redmine::instance (
$instances = {}
) {
file { $instances[docroot]:
ensure = directory,
owner = 'apache',
}
file {$instances[docroot]/config/database.yml:
content = production:
adapter: mysql
database: $instances[db]
host: localhost
username: $instances[db_user]
password: $instances[db_pass]
encoding: utf8
,
}
}
That's a trimmed down example, but the error I get is
# puppetd --test --debug -v --noop
debug: Puppet::Type::User::ProviderDirectoryservice: file /usr/bin/
dscl does not exist
debug: Puppet::Type::User::ProviderPw: file pw does not exist
debug: Puppet::Type::User::ProviderLdap: true value when expecting
false
debug: Puppet::Type::User::ProviderUser_role_add: file roleadd does
not exist
debug: Puppet::Type::File::ProviderMicrosoft_windows: feature
microsoft_windows is missing
debug: Failed to load library 'ldap' for feature 'ldap'
debug: /File[/var/lib/puppet/clientbucket]: Autorequiring File[/var/
lib/puppet]
debug: /File[/var/lib/puppet/facts]: Autorequiring File[/var/lib/
puppet]
debug: /File[/var/lib/puppet/state/state.yaml]: Autorequiring File[/
var/lib/puppet/state]
debug: /File[/var/lib/puppet/ssl/certs/client.tld.pem]: Autorequiring
File[/var/lib/puppet/ssl/certs]
debug: /File[/var/lib/puppet/client_data]: Autorequiring File[/var/lib/
puppet]
debug: /File[/var/lib/puppet/ssl/certs/ca.pem]: Autorequiring File[/
var/lib/puppet/ssl/certs]
debug: /File[/etc/puppet/puppet.conf]: Autorequiring File[/etc/puppet]
debug: /File[/var/lib/puppet/state/last_run_report.yaml]:
Autorequiring File[/var/lib/puppet/state]
debug: /File[/var/lib/puppet/ssl]: Autorequiring File[/var/lib/puppet]
debug: /File[/var/lib/puppet/ssl/certs]: Autorequiring File[/var/lib/
puppet/ssl]
debug: /File[/etc/puppet/namespaceauth.conf]: Autorequiring File[/etc/
puppet]
debug: /File[/var/lib/puppet/ssl/private_keys]: Autorequiring File[/
var/lib/puppet/ssl]
debug: /File[/var/lib/puppet/ssl/certificate_requests]: Autorequiring
File[/var/lib/puppet/ssl]
debug: /File[/var/lib/puppet/ssl/private_keys/client.tld.pem]:
Autorequiring File[/var/lib/puppet/ssl/private_keys]
debug: /File[/var/lib/puppet/state/last_run_summary.yaml]:
Autorequiring File[/var/lib/puppet/state]
debug: /File[/var/lib/puppet/ssl/crl.pem]: Autorequiring File[/var/lib/
puppet/ssl]
debug: /File[/var/lib/puppet/lib]: Autorequiring File[/var/lib/puppet]
debug: /File[/var/lib/puppet/classes.txt]: Autorequiring File[/var/lib/
puppet]
debug: /File[/var/lib/puppet/client_yaml]: Autorequiring File[/var/lib/
puppet]
debug: /File[/var/lib/puppet/ssl/private]:
Re: [Puppet Users] chaining resources problem
On Wed, Aug 17, 2011 at 8:27 AM, dieterdm dieterdeme...@gmail.com wrote: Hi, Thanks for the replies... Currently, I made it work using stages. But I'll try the approach of putting my resource chaining at the bottom and let you know if it works... The ordering was my first-guess at the problem, but I would believe it to be incorrect. Instead, I would presume that it is indeed bug 8040 hitting you. Also, check out this comment about bug 8040 also being applicable for Run Stages -- https://projects.puppetlabs.com/issues/5709#note-5 -Gary Regards. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/hCBlfMcy49wJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- Gary Larizza Professional Services Engineer Puppet Labs Join us for PuppetConf http://bit.ly/puppetconfsig, September 22nd and 23rd in Portland, OR! -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: scoping question - I want a node specific global var
On Tue, Aug 16, 2011 at 4:46 PM, Scott Smith sc...@ohlol.net wrote: Some times doing things the right way requires going through the pain of changing your current practices for the better. Sometimes your schedule doesn't allow you to refactor that much right now. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] facter-1.6.0 incorrectly identifies hardware node as virtual
I've installed facter-1.6.0 and puppet-2.7.3 on a number of SLES 10 hardware nodes (HP DL580) running the Virtuozzo hosting software. Well, facter correctly identifies such a machine as a hardware node (virtual = openvzhn) but somehow concludes that the hardware node is in fact virtual. (is_virtual = true) This breaks some rather important logic. If anyone knows of a patch floating around out there for 1.6.0 I'd be obliged. Even better would be to get this officially fixed for facter-1.6.1. Joe -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: Corrupted inventory.txt - how to rebuild?
You guys do realize that it's not necessary to share node certs with puppetmasters if your CA is separated, right? It's signed for a reason :) On Aug 16, 2011 8:13 AM, Luke Bigum luke.bi...@lmax.com wrote: Also I think Nigel posted a load balanced solution using entirely Apache that's floating around on the list, configs and all. Was a few months ago now if you want to go searching. On Aug 16, 4:12 pm, Luke Bigum luke.bi...@lmax.com wrote: Sean, Previously I've set up a cluster of Puppet Masters with one machine acting as the software load balancer (IPVS) as well as the Puppet Certificate Authority. The relevant puppet.conf options are ca_port and ca_server to specify where your CA is. The Puppet Master service on the CA server listened on the ca_port and signed CA requests. The default puppet port 8140 was load balanced to a pool of slave Puppet Masters and these masters all NFS mounted the ssl/ca/ directory so they knew about all signed puppet agents. You could then go even further and make your CA server resilient with Pacemaker / Heartbeat or other HA techniques. I didn't bother to go that far though ;) Hope that helps, -Luke On Aug 16, 3:25 pm, Sean Carolan scaro...@gmail.com wrote: How do you all handle load balancing and certificate management? Is there a way to have a master authority cert server, that all the other nodes turn to for all things SSL? -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: scoping question - I want a node specific global var
On Wed, Aug 17, 2011 at 6:44 AM, jcbollinger john.bollin...@stjude.org wrote:
* We're not using ENC
Fair enough. I don't use one either, but it was worth pointing out
the possibility.
Yes, and it is an additional argument to migrate there eventually.
* I want the special information right alongside the node decl. This
reduces chance for error and makes the data more maintainable.
So that's the constraint that is really biting you, in more ways than
one, and I feel obligated to observe that it is a style / practices
issue, not an infrastructure issue.
But it is a good style. It is bad style to spread the information in
several places where they can get out of sync with each other. We did
our best to deploy our puppet deployment according to the best
practices at the time, and it would even still work with the current
version of puppet; I just don't want to depend on dynamic scoping
which is going away.
Yes, the ENC solves that, but I need a workaround now, not later after
we've migrated to ENC. We have a deadline for implementing the
failover and I'm trying to find the cleanest interim solution.
Ok, so that rules out regex hostname matching, both in node
declarations and in selector expressions. It makes it less palatable,
but by no means impossible to use a selector somewhere to choose a
value for $failover. It remains your stipulation that $failover be
assigned in the node declaration that narrows your options here.
Yes - I don't want the failover variable buried in manifests further
below. It is an attribute of the node, not the classes the node
includes.
Your constraint that the failover information be in the node
declarations is again what's driving you here. It is not consistent
to insist that node declarations must contain more information, but at
the same time complain that they become longer / more complex.
It is consistent if I have to jump through hoops of making them more
complex just to set an attribute :)
Maybe the answer is to make a case statement in the nodes.pp that sets
$IMSPECIAL globally based on the hostname... which was one of your
suggestions. But I don't like maintaining two lists of host regex's,
which could get out of date.
Is there no specifier to reach my node's scope? i.e.,
$mynode::IMSPECIAL? Maybe in Ruby?
Only dynamic scoping, as far as I know, and that's going away. Also,
it doesn't work with node inheritance the way you would like it to do.
That's unfortunate.. 'cause I can refer to an arbitrary class with
$foo::var. I'd hoped there was some scoping sugar to refer to my node
scope.
I can refer to my parent class by name, so I 'd think it natural to
want to refer to node scopes.
node a { include c }
class b { $b = 1 }
class c inherits b { notice($b::b) }
or
class b {
$b = 1
notice($c::c)
}
class c {
$c = 2
include b
notice($b::b)
}
It may be that Hiera provides a way to paper over this problem. I
We'll definitely check out Hiera someday, but right now isn't the time.
Alternatively, you could drop the plan to use node inheritance. You
must have a viable plan for identifying your failover nodes by their
hostnames (even if its just knowing specific names),
We have specific names, but it is prone to error as we add more. I'm
not the only one maintaining this puppet environment. The real
problem is that we deployed this failover site using the same naming
conventions as non-failover systems in the same datacenter.
We do have a machine database that we query inside of puppet to make
some variables... i.e., $machine_database::location,
$machine_database::category. I think THAT is how we're going to have
to solve this problem for now -- which is sort of like solving it with
an ENC. Eventually we want to have this db drive the ENC anyway.
for your original
idea is predicated on such a plan. Therefore, instead of applying
that logic to choose which node declaration to apply, you can instead
use it either within node declarations or without to set your magic
variable or class parameter, or to include a different / extra class.
For example:
node /.*our-db\d+/ {
$failover = $hostname ? { /our-db\d+/ = false, default = true }
include system:our_db
}
I'm not following -- doesn't that example have the same problem? The
variable $failover has no visibility outside of this scope.
Anyway, discussing it more internally, we're going to use an attribute
of the machine database.
Thanks for all the suggestions -- saves me time from heading down wrong paths!
Rich
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: Puppet agent hangs for over a minute, no info in --summarize
Yup, that was definitely it. Threw something in the hosts file to just dummy out a hostname for the returned IP, and now it's quite speedy. Thanks, never would have found that left to my own devices. On Aug 17, 2:49 pm, Scott Smith sc...@ohlol.net wrote: Run arp -a If it hangs at any point, that is likely the problem. I'm not suggesting that arp is the problem, rather that you might have entries for IP addresses that have no PTR. See:http://projects.puppetlabs.com/issues/8247 -scott On Wed, Aug 17, 2011 at 12:40 PM, Dragonfyre13 dragonfyr...@gmail.comwrote: Not as far as I can tell. I can honestly say I didn't look that far down the chain yet though, except that name resolution is occurring quickly and successfully for each of the boxes in play (I did test on fqdn, ip, and hostname FYI, so it's not a resolution issue). Note also that tcp and udp connections and packets between these servers are in the single digit ms range from my tests (although of course ARP resolution would be below either of these), and they are sitting behind a single switch prior to exiting to the primary lab switches. I would anticipate that puppet wouldn't be the only application with this issue if it were at the ARP level though, and I'm able to communicate between the systems fine via other methods. If you want to direct me to something on how I can confirm, I'm more than happy to try. Not entirely sure to check existing PTR entries against the ARP cache. On Aug 17, 12:54 pm, Scott Smith sc...@ohlol.net wrote: Do you have any arp entries for which there is no PTR? On Aug 17, 2011 10:23 AM, Dragonfyre13 dragonfyr...@gmail.com wrote: Hoping you guys might be able to help me out, I'm not sure what's wrong but puppet agent hangs for over a minute, no resource spikes (CPU, memory, etc all stay basically the same as without starting puppet, barely a blip, and I've got more than enough headroom). It's not a serious issue for continuous usage, but really, really annoying when testing the manifests I'm starting to create. Below is a snippet of the agent's output when run with: puppet agent --test --noop --debug --trace --verbose --waitforcert 0 Master is running as: puppet master --no-daemonize --debug --trace --logdest --summarize Agent log segment: [snip] debug: /File[/var/lib/puppet/state]: Autorequiring File[/var/lib/ puppet] debug: Finishing transaction 70059796256340 debug: Using cached certificate for ca debug: Using cached certificate for ubuntu05.wic.west.com debug: Finishing transaction 70059798542500 debug: Loaded state in 0.00 seconds debug: Using cached certificate for ca debug: Using cached certificate for ubuntu05.wic.west.com debug: Using cached certificate_revocation_list for ca debug: catalog supports formats: b64_zlib_yaml dot marshal pson raw yaml; using pson [snip] debug: Storing state debug: Stored state in 0.01 seconds notice: Finished catalog run in 0.16 seconds Changes: Events: Noop: 2 Total: 2 Resources: Total: 12 Out of sync: 2 Skipped: 6 Time: Filebucket: 0.00 Package: 0.00 Exec: 0.00 Config retrieval: 0.44 Total: 0.45 Last run: 1313600473 debug: Using cached certificate for ca debug: Using cached certificate for ubuntu05.wic.west.com debug: Using cached certificate_revocation_list for ca debug: Value of 'preferred_serialization_format' (pson) is invalid for report, using default (b64_zlib_yaml) debug: report supports formats: b64_zlib_yaml marshal raw yaml; using b64_zlib_yaml Master Log: info: Expiring the node cache of ubuntu05.wic.west.com info: Not using expired node for ubuntu05.wic.west.com from cache; expired at Wed Aug 17 13:00:12 -0400 2011 info: Caching node for ubuntu05.wic.west.com debug: Exec[pwd]: Adding default for logoutput debug: Exec[pwd]: Adding default for path debug: Exec[whoami]: Adding default for logoutput debug: Exec[whoami]: Adding default for path notice: Compiled catalog for ubuntu05.wic.west.com in environment production in 0.04 seconds Agent hangs between: debug: Loaded state in 0.00 seconds debug: Using cached certificate for ca It sits there for over a minute before moving on. I've tried an agent on a different system from the master, agent on the same system (as above), they have the exact same behavior. At first I thought it was the manifest I created (nothing complicated, followed ntp stuff and adapted it slightly for the most part), but running this with absolutely no manifests being applied for the node hangs for the same period of time, in the same place. I'm using webrick for the server, but since right now I have a single client, and that's being fired off manually (not in cron, not a long running client, etc),
Re: [Puppet Users] Help Getting Puppet to run on HP-UX (as a client)
On Wed, 17 Aug 2011, jmckin...@thezenith.com wrote: /opt/iexpress/ruby/sbin/puppetd:4:in `main' err: Could not create resources for managing Puppet's files and directories in sections [:main, :agent, :ssl]: Could not autoload file: Unable to find library 'libz.so'. - /opt/iexpress/ruby/lib/ruby/ 1.9.1/ia64-hpux11.23/zlib.so Where is libz.so? -- Tim Connors -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
