Bug #959

Need to override automatically generated resources such as

Added by Derek Whayman over 4 years ago. Updated about 4 years ago.

Status:Closed Start date:
Priority:High Due date:
Assignee:Puppet Community % Done:

0%
Category:-
Target version:0.24.0
Affected Puppet version:0.25.4 Branch:
Keywords:
Votes: 0

Description

Many Puppet config files and directories now become resources automatically. In particular, $config (/etc/puppet/puppet.conf) is one, so when I try to add a resource Puppet reports a conflict.

file { "/etc/puppet/puppet.conf:
   blah
}

The resource is already defined, automatically by puppet.

This is problematic because we generate $config from a template for clients (if you’re interested, it’s because we “write-back” server = <%= blah %>, which means your client “sticks” to the last Puppetmaster it contacted).

puppet959.tgz (2.2 kB) Derek Whayman, 12/12/2007 11:05 am

History

#1
Updated by Luke Kanies over 4 years ago

I can’t reproduce this problem — my hosts copy their puppet.conf files from remote hosts with no problems. Can you post a stack trace?

#2
Updated by Luke Kanies over 4 years ago

  • Status changed from 1 to Closed
  • 7 set to worksforme

#3
Updated by Derek Whayman over 4 years ago

Ouch – this was hard to reduce down to a test case. In order to reproduce you must Run client/server rather than stand-alone Have TWO resources that depend on the “top” resource

Then, Puppet complains:

err: File[/var/lib/puppet] is already being managed

I will attach a reproducing test case.

Cheers, Derek

#4
Updated by Luke Kanies over 4 years ago

  • Status changed from Closed to 4
  • 7 deleted (worksforme)

Okay, I’ve reproduced it.

#5
Updated by Luke Kanies over 4 years ago

  • Status changed from 4 to Closed
  • 7 set to fixed

Hopefully fixed in commit:4ebb8d0cb7c77719a25c689d05f6639f31829c0c.

#6
Updated by Udo Waechter over 4 years ago

In Debian and puppetmaster and client version 0.24.1 this problem still persists. I do copy puppet.conf from the server to the clients, and I get the error that: “ Settings[/etc/puppet/puppet.conf] is already being managed”

#7
Updated by Luke Kanies over 4 years ago

  • Status changed from Closed to 4
  • 7 deleted (fixed)

#8
Updated by Francois Deppierraz over 4 years ago

Replying to [comment:7 do]:

In Debian and puppetmaster and client version 0.24.1 this problem still persists. I do copy puppet.conf from the server to the clients, and I get the error that: “ Settings[/etc/puppet/puppet.conf] is already being managed”

I’ve also experienced this bug with Debian packages version 0.24.1 but only with configuration setting storeconfigs=true on the master.

Settings[/etc/puppetmaster/puppet.conf] is already being managed

#9
Updated by Luke Kanies over 4 years ago

  • Status changed from 4 to Closed
  • 7 set to fixed

Fixed (again) in [8a649ff], hopefully.

#10
Updated by Luke Kanies over 4 years ago

Marking #1036 as a duplicate.

#11
Updated by micah - about 4 years ago

Just wanted to note that that when I hit this bug, applying changeset:4ebb8d0cb7c77719a25c689d05f6639f31829c0c solved it.

#12
Updated by micah - about 4 years ago

Replying to [comment:15 micah]:

Just wanted to note that that when I hit this bug, applying changeset:4ebb8d0cb7c77719a25c689d05f6639f31829c0c solved it.

Sorry, wrong changeset linked there, the one that actually fixed the problem was changeset:8a649ff

#13
Updated by Luke Kanies about 4 years ago

I think I put the last fix in [d0554db]. This should finally clear up the last of these.

Also available in: Atom PDF