The Puppet Labs Issue Tracker has Moved: https://tickets.puppetlabs.com

This issue tracker is now in read-only archive mode and automatic ticket export has been disabled. Redmine users will need to create a new JIRA account to file tickets using https://tickets.puppetlabs.com. See the following page for information on filing tickets with JIRA:

Bug #3299

owner of files created by nagios resource types

Added by Frederic Descamps about 6 years ago. Updated over 2 years ago.

Status:In Topic Branch Pending ReviewStart date:02/25/2010
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:nagios
Target version:-
Affected Puppet version:3.1.1 Branch:https://github.com/puppetlabs/puppet/pull/2060
Keywords:

We've Moved!

Ticket tracking is now hosted in JIRA: https://tickets.puppetlabs.com

This ticket is now tracked at: https://tickets.puppetlabs.com/browse/PUP-1327


Description

Currently the files are created with the permission 600 and are owned by root

it will be nice to have the possibility to change the owner and/or the permissions of those resources

example :

nagios_host{ "korin": 
ensure          => "present",
use             => "linux-server",
alias           => "korin",
address         =>  "192.168.109.84",
hostgroups      => "linux-servers",
target          => "/etc/nagios/host_korin.cfg",
**owner           => "nagios"**;
}    

Related issues

Related to Puppet - Bug #2158: Nagios files are created mode 600 Accepted 04/14/2009
Duplicated by Puppet - Feature #14429: Naginator should provide a way to change mode, owner and ... Duplicate 05/11/2012

History

#1 Updated by Frederic Descamps about 6 years ago

I’ll check Override Exported Ressources in 0.25

#2 Updated by James Turnbull about 6 years ago

  • Project changed from Naginator to Puppet
  • Status changed from Unreviewed to Needs Decision
  • Assignee set to Luke Kanies
  • Affected Puppet version set to 0.25.4

#3 Updated by Luke Kanies almost 6 years ago

  • Assignee deleted (Luke Kanies)

Can’t you just manage the files separately using a ‘file’ resource in Puppet?

#4 Updated by Karsten Elfenbein over 5 years ago

the alternative is to ignore nagios_host and do this with templates but that defeats the hole thing

still present in Puppet 2.6.4

#5 Updated by James Turnbull over 5 years ago

  • Assignee set to Nigel Kersten

#6 Updated by Nigel Kersten over 5 years ago

  • Status changed from Needs Decision to Needs More Information

Why isn’t the workaround of using a file resource satisfactory?

#7 Updated by Stefan Goethals over 5 years ago

Just by the fact that it is a workaround, not a solution.

#8 Updated by Nigel Kersten over 5 years ago

ok. Given we have a workaround, this isn’t a high priority for us to do the development work, but we’d be more than happy to accept patches to get the desired functionality.

I’m concerned about parameter explosion, as once you add owner you’re going to want group, and probably mode as well.

#9 Updated by Nigel Kersten over 5 years ago

  • Status changed from Needs More Information to Unreviewed
  • Assignee deleted (Nigel Kersten)

#10 Updated by James Turnbull about 5 years ago

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

#11 Updated by Sam Pointer over 4 years ago

Nigel Kersten wrote:

ok. Given we have a workaround, this isn’t a high priority for us to do the development work, but we’d be more than happy to accept patches to get the desired functionality.

I’m concerned about parameter explosion, as once you add owner you’re going to want group, and probably mode as well.

If you’re worried about parameter explosion then perhaps a better default would be to create the files 0640 root:root and only offer the group parameter.

This would be backwards compatible with existing installations that expect only root to be able to read the files, but enable those with Nagios installs running under non-root users to amend the group to something more appropriate for reading the config files, such as ‘nagios’.

#12 Updated by Alexander Swen over 4 years ago

still a problem in 2.7.9

question about the workarround “Can’t you just manage the files separately using a ‘file’ resource in Puppet?” how do i do that? should I define files with ensure => present or so for each file that would be created by a puppet nagios_* resourse??? imho that is not very efficient.

I don’t understand why it’s not possible to create the files with mode 640, group nagios to make this resource work. please motivate the current setting 600-root:root.

#13 Updated by Nigel Kersten over 4 years ago

We’d take a patch for that Alexander.

#14 Updated by Justin Honold over 4 years ago

Here’s what I’m doing in order to have each resource change properly permissioned with service restart notification:

  • define configs using the nagios_* types as usual
  • set a global default on all of the used types to notify a refreshonly exec
  • have the refreshonly exec run a chown and notify the service class

This works, but it seems wonky to me and I was genuinely surprised with the root:root 600 thing.

#15 Updated by Joshua Hoblitt over 3 years ago

I feel that all of the nagios_* types should allow owner, group, & mode similar to the file type.

#16 Updated by Andrew McNaughton about 3 years ago

If this bug is not going to be resolved, then the ‘target’ parameter is severely limited. At a minimum, this shortcoming should be documented in the notes on the ‘target’ parameter on each of puppet’s nagios types.

Either that or just fix the thing. If people don’t need the extra parameters, they won’t use them. I can’t see that having an extra file resource with those parameters is in any way preferable.

#17 Updated by Klavs Klavsen about 3 years ago

  • Affected Puppet version changed from 0.25.4 to 3.1.1

Why is this ridiculous bug really still around?

If you don’t want to support the nagios_* types anymore – remove them, instead of rendering them unusable :(

#18 Updated by Mark Ruys over 2 years ago

Klavs Klavsen wrote:

Why is this ridiculous bug really still around?

If you don’t want to support the nagios_* types anymore – remove them, instead of rendering them unusable :(

Can’t agree more…

#19 Updated by Felix Frank over 2 years ago

Guys, guys…less moping, more patching ;–)

Almost there.

#20 Updated by Felix Frank over 2 years ago

  • Status changed from Accepted to In Topic Branch Pending Review
  • Branch set to https://github.com/puppetlabs/puppet/pull/2060

Enjoy. It’s currently a little light on tests. Will rectify that soon-ish.

#21 Updated by Anonymous over 2 years ago

Redmine Issue #3299 has been migrated to JIRA:

https://tickets.puppetlabs.com/browse/PUP-1327

Also available in: Atom PDF