Issue #1541 has been reported by marthag.

Bug #1541: nagios objects write files to clientbucket on every change

• Author: marthag
• Status: Unreviewed
• Priority: Normal
• Assigned to:
• Category:
• Target version:
• Complexity: Unknown
• Affected version: 0.24.5
• Keywords:

The nagios_* objects write their configuration files to the clientbucket after every change, even when there are multiple changes in the same puppet run. This makes it extremely slow when you are making a lot of changes at once.

notice: //nagios::server/Nagios_service[puppet-server7]/ensure: created info: Filebucket[/var/lib/puppet/clientbucket]: Adding /etc/nagios/nagios_service.cfg(e8ab872cbbb1efa834d86ae7db9beaa9) info: //nagios::server/Nagios_service[puppet-server7]: Scheduling refresh of Exec[nagios3 reload] notice: //nagios::server/Nagios_service[puppet-server3]/ensure: created info: Filebucket[/var/lib/puppet/clientbucket]: Adding /etc/nagios/nagios_service.cfg(dd4a71ffd9a9df2ccc8de0e39e85cc2b) info: //nagios::server/Nagios_service[puppet-server3]: Scheduling refresh of Exec[nagios3 reload] notice: //nagios::server/Nagios_service[puppet-server5]/ensure: created info: Filebucket[/var/lib/puppet/clientbucket]: Adding /etc/nagios/nagios_service.cfg(115294d431ffebc6847cf02db470842e) info: //nagios::server/Nagios_service[puppet-server5]: Scheduling refresh of Exec[nagios3 reload] notice: //nagios::server/Nagios_service[puppet-server2]/ensure: created info: Filebucket[/var/lib/puppet/clientbucket]: Adding /etc/nagios/nagios_service.cfg(de78f44281018067170921292fd24e2d) info: //nagios::server/Nagios_service[puppet-server2]: Scheduling refresh of Exec[nagios3 reload]

You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://reductivelabs.com/redmine/my/account

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To post to this group, send email to puppet-bugs <at> googlegroups.com
To unsubscribe from this group, send email to puppet-bugs+unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en
-~----------~----~----~----~------~----~------~--~---

Issue #1542 has been reported by marthag.

Bug #1542: cannot purge nagios objects

• Author: marthag
• Status: Unreviewed
• Priority: Normal
• Assigned to:
• Category:
• Target version:
• Complexity: Unknown
• Affected version: 0.25.0
• Keywords:

I tried purging nagios objects by adding the followin in my site.pp:

resources { nagios_host: purge => true; nagios_service: purge => true; nagios_servicedependency: purge => true; }

However, I get the follow error on the client:

notice: Starting catalog run err: //Resources[nagios_servicedependency]: Failed to generate additional resources: undefined method `record_type' for #<Nagios::Base::Servicedependency:0x2aaaaacf1b90> err: //Resources[nagios_host]: Failed to generate additional resources: undefined method `record_type' for #<Nagios::Base::Host:0x2aaaacde3ec0> err: //Resources[nagios_service]: Failed to generate additional resources: undefined method `record_type' for #<Nagios::Base::Service:0x2aaaacde7c78>

and the objects are not purged.

You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://reductivelabs.com/redmine/my/account

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To post to this group, send email to puppet-bugs <at> googlegroups.com
To unsubscribe from this group, send email to puppet-bugs+unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en
-~----------~----~----~----~------~----~------~--~---

Issue #1543 has been reported by marthag.

Bug #1543: puppet dies on nagios parse

• Author: marthag
• Status: Unreviewed
• Priority: Normal
• Assigned to:
• Category:
• Target version:
• Complexity: Unknown
• Affected version: 0.24.5
• Keywords:

This happens when a value for a nagios directive is blank:

notice: /Nagios_host[weblog]/parents: defined 'parents' as '' info: Filebucket[/var/lib/puppet/clientbucket]: Adding /etc/nagios/nagios_host.cfg(fc0cbab23a4bbffeec46acc879997e2c) info: /Nagios_host[weblog]: Scheduling refresh of Exec[nagios3 reload] line 343: syntax error at ' '

You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://reductivelabs.com/redmine/my/account

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To post to this group, send email to puppet-bugs <at> googlegroups.com
To unsubscribe from this group, send email to puppet-bugs+unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en
-~----------~----~----~----~------~----~------~--~---

Issue #1541 has been updated by jamtur01.

• Category set to nagios
• Status changed from Unreviewed to Accepted

Bug #1541: nagios objects write files to clientbucket on every change

• Author: marthag
• Status: Accepted
• Priority: Normal
• Assigned to:
• Category: nagios
• Target version:
• Complexity: Unknown
• Affected version: 0.24.5
• Keywords:

The nagios_* objects write their configuration files to the clientbucket after every change, even when there are multiple changes in the same puppet run. This makes it extremely slow when you are making a lot of changes at once.

notice: //nagios::server/Nagios_service[puppet-server7]/ensure: created info: Filebucket[/var/lib/puppet/clientbucket]: Adding /etc/nagios/nagios_service.cfg(e8ab872cbbb1efa834d86ae7db9beaa9) info: //nagios::server/Nagios_service[puppet-server7]: Scheduling refresh of Exec[nagios3 reload] notice: //nagios::server/Nagios_service[puppet-server3]/ensure: created info: Filebucket[/var/lib/puppet/clientbucket]: Adding /etc/nagios/nagios_service.cfg(dd4a71ffd9a9df2ccc8de0e39e85cc2b) info: //nagios::server/Nagios_service[puppet-server3]: Scheduling refresh of Exec[nagios3 reload] notice: //nagios::server/Nagios_service[puppet-server5]/ensure: created info: Filebucket[/var/lib/puppet/clientbucket]: Adding /etc/nagios/nagios_service.cfg(115294d431ffebc6847cf02db470842e) info: //nagios::server/Nagios_service[puppet-server5]: Scheduling refresh of Exec[nagios3 reload] notice: //nagios::server/Nagios_service[puppet-server2]/ensure: created info: Filebucket[/var/lib/puppet/clientbucket]: Adding /etc/nagios/nagios_service.cfg(de78f44281018067170921292fd24e2d) info: //nagios::server/Nagios_service[puppet-server2]: Scheduling refresh of Exec[nagios3 reload]

You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://reductivelabs.com/redmine/my/account

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To post to this group, send email to puppet-bugs <at> googlegroups.com
To unsubscribe from this group, send email to puppet-bugs+unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en
-~----------~----~----~----~------~----~------~--~---

Issue #1542 has been updated by jamtur01.

• Category set to nagios
• Status changed from Unreviewed to Accepted

Bug #1542: cannot purge nagios objects

• Author: marthag
• Status: Accepted
• Priority: Normal
• Assigned to:
• Category: nagios
• Target version:
• Complexity: Unknown
• Affected version: 0.25.0
• Keywords:

I tried purging nagios objects by adding the followin in my site.pp:

resources { nagios_host: purge => true; nagios_service: purge => true; nagios_servicedependency: purge => true; }

However, I get the follow error on the client:

notice: Starting catalog run err: //Resources[nagios_servicedependency]: Failed to generate additional resources: undefined method `record_type' for #<Nagios::Base::Servicedependency:0x2aaaaacf1b90> err: //Resources[nagios_host]: Failed to generate additional resources: undefined method `record_type' for #<Nagios::Base::Host:0x2aaaacde3ec0> err: //Resources[nagios_service]: Failed to generate additional resources: undefined method `record_type' for #<Nagios::Base::Service:0x2aaaacde7c78>

and the objects are not purged.

You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://reductivelabs.com/redmine/my/account

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To post to this group, send email to puppet-bugs <at> googlegroups.com
To unsubscribe from this group, send email to puppet-bugs+unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en
-~----------~----~----~----~------~----~------~--~---

Issue #1543 has been updated by jamtur01.

• Category set to nagios
• Status changed from Unreviewed to Accepted

Bug #1543: puppet dies on nagios parse

• Author: marthag
• Status: Accepted
• Priority: Normal
• Assigned to:
• Category: nagios
• Target version:
• Complexity: Unknown
• Affected version: 0.24.5
• Keywords:

This happens when a value for a nagios directive is blank:

notice: /Nagios_host[weblog]/parents: defined 'parents' as '' info: Filebucket[/var/lib/puppet/clientbucket]: Adding /etc/nagios/nagios_host.cfg(fc0cbab23a4bbffeec46acc879997e2c) info: /Nagios_host[weblog]: Scheduling refresh of Exec[nagios3 reload] line 343: syntax error at ' '

You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://reductivelabs.com/redmine/my/account

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To post to this group, send email to puppet-bugs <at> googlegroups.com
To unsubscribe from this group, send email to puppet-bugs+unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en
-~----------~----~----~----~------~----~------~--~---

Issue #1544 has been reported by ssm.

Bug #1544: File resource fails when recursing from a source directory that contains dangling symlinks

• Author: ssm
• Status: Unreviewed
• Priority: Normal
• Assigned to:
• Category: file
• Target version:
• Complexity: Unknown
• Affected version: 0.24.4
• Keywords: file directory recurse symlink

Using a file resource with "ensure => directory, recurse => true" fails when the source directory contains dangling symlinks. The directory is created, but none of the content is copied from the source.

Manifest file_directory_recurse_symlink.pp¶

This manifest reproduces the issue. The manifest creates a source directory, containing a file with content, and a dangling symlink. It also creates another directory with the first directory as source, and with "recurse => true".

The destination directory is created, but neither the file, nor the dangling symlink is copied from the source directory. Instead, an error message is displayed:

err: //File[/tmp/ssm_test_copy]: Failed to generate additional resources during transaction: undefined method `each' for nil:NilClass

This was seen when using "puppetd" and "puppetmasterd", the manifest reproduces the same issue when running with "puppet".

Manifest file_directory_recurse_unreadable_file.pp¶

This manifests shows "good" behaviour when encountering unreadable files.

I would normally expect a dangling symlink in a recursed directory to be created in the same way on the puppet node, pointing to the same place.

You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://reductivelabs.com/redmine/my/account

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To post to this group, send email to puppet-bugs <at> googlegroups.com
To unsubscribe from this group, send email to puppet-bugs+unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en
-~----------~----~----~----~------~----~------~--~---

Issue #1427 has been updated by immerda.

• Status changed from Closed to Re-opened
• Assigned to changed from luke to jamtur01
• Priority changed from Normal to High
• Target version set to 0.24.6

This whole commit introduces a new problem:

if we have facter variables with a dot (.) in the name, the template wrapper will fail with the following error:

Tue Sep 02 12:18:11 +0200 2008 Puppet (err): Failed to parse template munin/munin-node.conf.CentOS: ` <at> macaddress_vif3.1' is not allowed as an instance variable name at /srv/puppet/modules-development/munin/manifests/client.pp:68 on node foobar

it is quite logical as ruby can't have variables with a dot in their name. the question is on which side we have to solve that? facter or puppet?

Refactor #1427: using missing_method for variable looking in TemplateWrapper allows trivial conflicts with built-in methods such as 'Kernel#fork'

• Author: daniel
• Status: Re-opened
• Priority: High
• Assigned to: jamtur01
• Category:
• Target version: 0.24.6

G'day.

I have encountered what I think is a problem with template expansion as
part of puppet, and wanted to confirm that my understanding is correct
that this is a bug -- or identify how to work around it.

So, I have created a class (with define) to represent a new
configuration file that I am managing. One of the options in the
configuration file is 'fork', for better or worse.

So, using define I have, roughly, the following:

test.pp:

define foo ($fork = "yes") {
file { "/tmp/output.txt": content => template("test.erb") }
}
node myhost { foo { "bar": } }

test.erb:

The output is 'Fixnum' and a PID on my machine, because ERB resolves the
variable into the kernel method 'fork', forks the puppet process, and
returns that PID to the parent. Ouch.

The same can be demonstrated with 'object_id' in the ERB file, which is
never resolved to an object_id variable no matter what.

Sadly, according to the puppet documentation this should all work, but
it doesn't. Worse, the root cause is the implementation of the template
wrapper, which is all ... exciting:

lib/puppet/parser/templatewrapper.rb:32 says: # Ruby treats variables like methods, so we can cheat here and # trap missing vars like they were missing methods.
def method_missing(name, *args)

Darn! This is never going to work if the ERB code is evaluated in an
environment where Kernel is visible, and I don't believe Ruby allows us
to create a new execution environment where that isn't the case. :?

(We could, in theory, clone the default Binding, excise everything from
it, then insert the ERB code and anything it depends on, including the
Kernel object, at which point we face the same problem. Yay!)

You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://reductivelabs.com/redmine/my/account

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To post to this group, send email to puppet-bugs <at> googlegroups.com
To unsubscribe from this group, send email to puppet-bugs+unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en
-~----------~----~----~----~------~----~------~--~---

Issue #1427 has been updated by jamtur01.

What Facter version do you have running.

Refactor #1427: using missing_method for variable looking in TemplateWrapper allows trivial conflicts with built-in methods such as 'Kernel#fork'

• Author: daniel
• Status: Re-opened
• Priority: High
• Assigned to: jamtur01
• Category:
• Target version: 0.24.6

G'day.

I have encountered what I think is a problem with template expansion as
part of puppet, and wanted to confirm that my understanding is correct
that this is a bug -- or identify how to work around it.

So, I have created a class (with define) to represent a new
configuration file that I am managing. One of the options in the
configuration file is 'fork', for better or worse.

So, using define I have, roughly, the following:

test.pp:

define foo ($fork = "yes") {
file { "/tmp/output.txt": content => template("test.erb") }
}
node myhost { foo { "bar": } }

test.erb:

The output is 'Fixnum' and a PID on my machine, because ERB resolves the
variable into the kernel method 'fork', forks the puppet process, and
returns that PID to the parent. Ouch.

The same can be demonstrated with 'object_id' in the ERB file, which is
never resolved to an object_id variable no matter what.

Sadly, according to the puppet documentation this should all work, but
it doesn't. Worse, the root cause is the implementation of the template
wrapper, which is all ... exciting:

lib/puppet/parser/templatewrapper.rb:32 says: # Ruby treats variables like methods, so we can cheat here and # trap missing vars like they were missing methods.
def method_missing(name, *args)

Darn! This is never going to work if the ERB code is evaluated in an
environment where Kernel is visible, and I don't believe Ruby allows us
to create a new execution environment where that isn't the case. :?

(We could, in theory, clone the default Binding, excise everything from
it, then insert the ERB code and anything it depends on, including the
Kernel object, at which point we face the same problem. Yay!)

You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://reductivelabs.com/redmine/my/account

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To post to this group, send email to puppet-bugs <at> googlegroups.com
To unsubscribe from this group, send email to puppet-bugs+unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en
-~----------~----~----~----~------~----~------~--~---

Issue #1545 has been reported by thegcat.

Feature #1545: Name of the calling module

• Author: thegcat
• Status: Unreviewed
• Priority: Low
• Assigned to:
• Category:
• Target version:
• Complexity: Unknown
• Affected version: 0.24.4
• Keywords:

It's been discussed before in #1104, but I can't find a ticket for that, so I suppose there isn't one as of now.

Anyway, it would be nice to know which module some definition is being called from, this would save me some Common_definition { module => module1, } at the beginning of module1.

You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://reductivelabs.com/redmine/my/account

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To post to this group, send email to puppet-bugs <at> googlegroups.com
To unsubscribe from this group, send email to puppet-bugs+unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en
-~----------~----~----~----~------~----~------~--~---