Jira (PUP-1713) removing nagios_* resource from manifest doesn't remove from resulting file
Title: Message Title
Erik M Jacobs commented on an issue
Re: removing nagios_* resource from manifest doesn't remove from resulting file
I've had a couple of additional random thoughts on this. Perhaps they add some color.
I somewhat expected that, because the nagios type operates inside a file, that it would evaluate the context of the entire file under its control and act accordingly. This expectation is based on how Puppet md5sums files under management (file resource) and, if the contents are not as expected, we re-deploy the file. Perhaps that is expecting a little much of the nagios types, as it would have to compile/calculate the resulting file (target) and then md5sum that and THEN decide that it should re-generate the file from scratch.
In reference to PUP-728, since the resource types lay down the files with "incorrect" ownership/permissions, you end up having to manage the file's ownership after use:
nagios_servicegroup { 'test':
target => '/etc/nagios/conf.d/testgroup.cfg',
require => File['nagios-confd'],
} ->
file { '/etc/nagios/conf.d/testgroup.cfg':
owner => "root",
group => "root",
mode => "0644",
purge => true,
recurse => true,
}
However, if you really want to make sure your nagios stuff is "clean", you could purge/recurse the directory... but, when you do that on top of managing the ownership/permissions, you don't actually end up purging the folder. For example:
file { '/etc/nagios/conf.d':
alias => "nagios-confd",
ensure => directory,
purge => true,
recurse => true,
}
nagios_servicegroup { 'test':
target => '/etc/nagios/conf.d/testgroup.cfg',
require => File['nagios-confd'],
}
This results in a purge every run before laying down the type.
file { '/etc/nagios/conf.d':
alias => "nagios-confd",
ensure => directory,
purge => true,
recurse => true,
}
nagios_servicegroup { 'test':
target => '/etc/nagios/conf.d/testgroup.cfg',
require => File['nagios-confd'],
} ->
file { '/etc/nagios/conf.d/testgroup.cfg':
owner => "root",
group => "root",
mode => "0644",
purge => true,
recurse => true,
}
This never purges because the file in the conf.d folder is "known" by puppet and actively managed.
So, at least, in my case, the solution is to place an "rm -f /etc/nagios/conf.d/*.cfg" as a requirement to/before all the service definitions, and that seems to solve the issue. This would probably be super ugly on a very large nagios environment / take a lot of time... but it "solves" the problem of unmanaged resources not remaining.
Jira (PUP-1713) removing nagios_* resource from manifest doesn't remove from resulting file
Title: Message Title Daniele Sluijters assigned an issue to Daniele Sluijters Puppet / PUP-1713 removing nagios_* resource from manifest doesn't remove from resulting file Change By: Daniele Sluijters Assignee: Kylo Ginsberg Daniele Sluijters Add Comment This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/groups/opt_out.
Jira (PUP-1713) removing nagios_* resource from manifest doesn't remove from resulting file
Title: Message Title
Daniele Sluijters commented on an issue
Re: removing nagios_* resource from manifest doesn't remove from resulting file
This is true with all Puppet resources. If a resource is not in a manifest it means it isn't managed, not that it should be removed. Can you imagine what would happen to a system the first time you start Puppet if that would be the case, it would wipe the system clean. There's no option to the nagios types to fully manage the file, it will only manage the entries it knows about and leave the others alone.
If you want this to happen you need to set that block to ensure => absent, and have it run once. The purging of (exported) Nagios resource has been broken since the dawn of time but perhaps https://ask.puppetlabs.com/question/567/remove-old-nagios-services-hosts/ can help you further.
Add Comment
Puppet / PUP-1713
removing nagios_* resource from manifest doesn't remove from resulting file
If you declare a nagios_service resource, it is created in the resulting file. Ex: {code} nagios_service { 'Load': use => 'local-service', host_name => 'server', service_description => 'Load', check_command => 'check_nrpe!check_load', contact_groups => 'admin', target => '/etc/nagios/conf.d/nagios_service.cfg', } {co...
This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede)
Jira (PUP-1713) removing nagios_* resource from manifest doesn't remove from resulting file
Title: Message Title
Erik M Jacobs created an issue
Puppet / PUP-1713
removing nagios_* resource from manifest doesn't remove from resulting file
Issue Type:
Bug
Affects Versions:
3.3.2
Assignee:
Kylo Ginsberg
Components:
Types and Providers
Created:
15/Feb/14 2:31 PM
Environment:
CentOS 2.6.32-431.el6.x86_64 Puppet 3.3.2-1.el6 EPEL
Priority:
Normal
Reporter:
Erik M Jacobs
If you declare a nagios_service resource, it is created in the resulting file. Ex:
nagios_service { 'Load':
use => 'local-service',
host_name => 'server',
service_description => 'Load',
check_command => 'check_nrpe!check_load',
contact_groups => 'admin',
target => '/etc/nagios/conf.d/nagios_service.cfg',
}
However, if you then remove this resource declaration from a manifest and do the puppet run again, this service is not removed.
