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 #650

puppet replaces configuration directories when they are symlinks

Added by Karl Pietri almost 9 years ago. Updated almost 5 years ago.

Status:ClosedStart date:
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:settings
Target version:2.6.9
Affected Puppet version:0.24.7 Branch:
Keywords:puppetcamp-eu-2011

We've Moved!

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


Description

[karl@testserver etc]$ sudo ls -l | grep puppet
lrwxrwxrwx  1 root root      22 May 30 05:36 puppet -> /home/karl/puppet/etc/
drwxr-xr-x  3 root root    4096 May 15 05:03 puppet.old
[karl@testserver etc]$ sudo service puppetmaster start
Starting puppetmaster: Can not use a non-existent file for parsing
                                                           [FAILED]
[karl@testserver etc]$ sudo ls -l | grep puppet
drwxr-xr-x  2 root root    4096 May 30 05:36 puppet
drwxr-xr-x  3 root root    4096 May 15 05:03 puppet.old

Related issues

Related to Puppet - Bug #4394: It should be possible to follow symlinks and create direc... Accepted 07/29/2010
Related to Puppet - Bug #5981: Puppet shouldn't overwrite symlinks when specifying conte... Accepted 01/23/2011
Duplicated by Puppet - Bug #2690: puppet insists on /etc/puppet/manifests being a folder Duplicate 10/01/2009
Duplicated by Puppet - Bug #2996: Puppetmaster not working with symlinks for puppet data di... Duplicate 12/30/2009
Duplicated by Puppet - Bug #7008: Puppet master destroys manifests directory on restart Duplicate 04/07/2011

History

#1 Updated by Luke Kanies over 8 years ago

Marking #750 as a duplicate.

#2 Updated by Luke Kanies almost 9 years ago

I’d like to fix this, but it’s not so critical it needs to be in beaker.

#3 Updated by Zach Wily over 8 years ago

One more vote to fix this. It does the same thing to /var/lib/puppet. Removed the symlink I made there and creates a skeleton dir.

#4 Updated by Luke Kanies almost 8 years ago

Marking #1239 as a duplicate.

#5 Updated by Redmine Admin almost 8 years ago

  • Status changed from 1 to Accepted

#6 Updated by Luke Kanies over 7 years ago

  • Target version changed from 0.25.0 to 4
  • Affected Puppet version set to 0.24.7

#7 Updated by James Turnbull over 6 years ago

  • Target version changed from 4 to 0.25.4

#8 Updated by James Turnbull over 6 years ago

  • Target version changed from 0.25.4 to 0.25.5

#9 Updated by James Turnbull about 6 years ago

  • Target version changed from 0.25.5 to 49

#10 Updated by Luke Kanies almost 6 years ago

  • Assignee deleted (Luke Kanies)

#11 Updated by Luke Kanies almost 6 years ago

Note that you can set ‘manage_internal_file_permissions’ to false to disable this behaviour.

#12 Updated by Jason Harvey over 5 years ago

  • Target version deleted (49)

I would love to see this fixed. I really want to use symlinks for my puppet.conf file. The manage_internal_file_permissions option only applies to file mode and ownership. It does not prevent puppet from trying to remove a symlink’d puppet.conf.

#13 Updated by Jason Harvey over 5 years ago

Also would like to add that this issue still exists in 2.6.

#14 Updated by Markus Roberts over 5 years ago

  • Status changed from Accepted to Needs Decision

Earlier discussions of this and similar issues seemed to stall on security concerns, though I’m not at the moment recalling the details. In any case, we certainly haven’t moved on it in the two+ years since it was accepted.

We should probably either do it or document the reason we are not doing it rather than leaving it in accepted but never acted on limbo.

#15 Updated by Nigel Kersten over 5 years ago

  • Status changed from Needs Decision to Investigating
  • Assignee set to Nigel Kersten

In the absence of any concrete reason to not allow symlinks, I suggest we extend ‘manage_internal_file_permissions = false’ to not replace symlinks.

Even allowing that the name of the option would then be somewhat misleading, I really don’t think it warrants yet another option.

I’ll take ownership of this while trying to track down any info about potential security issues that has come up before.

#16 Updated by Nigel Kersten over 5 years ago

  • Status changed from Investigating to Accepted

so that search was faster than I expected. I can’t see how a symlink race condition could be a problem in this situation given the perms on /etc/puppet itself.

Not targeted to a specific release yet.

#17 Updated by Nigel Kersten over 5 years ago

  • Assignee deleted (Nigel Kersten)
  • Target version set to 2.7.x

This is a big usability problem in my opinion. We’ve had regular IRC visitors complaining about this. Targeting to statler.

#18 Updated by Leo Simons over 5 years ago

Here’s another vote to get this fixed! Seriously baffling behavior if you ask me :)

#19 Updated by Ryan Ausanka-Crues about 5 years ago

Another vote for fixing this, makes it really hard to keep everything in version control.

#20 Updated by Kiall Mac Innes about 5 years ago

Another +1 here – baffling behaviour alright!

#21 Updated by Lance Reed about 5 years ago

+1 For all the examples already stated. This breaks current use of version control process.

#22 Updated by Nigel Kersten about 5 years ago

We’ve definitely decided to fix this.

It is a change in behavior that we’re not going to push in 2.6.x however.

#23 Updated by Karl Pietri about 5 years ago

Just thought i would chime in on a thought i had a while back. it would be nice if the file type supported directory or symlink which would solve this issue (i assume at the core puppet uses the file resource to ensure thats a directory) and be useful in a number of other situations.

-Karl Pietri

#24 Updated by armando migliaccio about 5 years ago

Another +1 here – I find it very odd that Puppetmasterd screws symlinks up.

#25 Updated by Nigel Kersten about 5 years ago

We’ve decided to fix this.

More +1’s in the ticket log really aren’t needed :)

Feel free to vote up above though with the up/down arrows.

#26 Updated by James Turnbull about 5 years ago

It does support directories and symlinks. Check the documentation

#27 Updated by Anonymous almost 5 years ago

  • Keywords set to puppetcamp-eu-2011

#28 Updated by Nick Lewis almost 5 years ago

Does this need to be supported for the command-line also, or just from puppet.conf?

#29 Updated by Nigel Kersten almost 5 years ago

It would be incredibly confusing if you could only do this in the config file and not from the command line.

#30 Updated by Nigel Kersten almost 5 years ago

  • Target version changed from 2.7.x to 2.7.0

Nigel Kersten wrote:

We’ve definitely decided to fix this.

It is a change in behavior that we’re not going to push in 2.6.x however.

Given that the proposed fix looks to be minimal, not intrusive and provide significant benefit, this is getting targeted at 2.6.x as well.

#31 Updated by Nick Lewis almost 5 years ago

  • Status changed from Accepted to Merged - Pending Release

Merged to 2.6.x in commit:e62734c661b660f6b8620da28589da7c6472808e.

Puppet will now set links => follow on file resources creating by settings, rather than links => manage. The behavior of these symlinks is the same as any other file resource. That is, if the target of the symlink doesn’t exist, Puppet will consider this an error. Similarly, if the target of the symlink is a file, then the symlink will still be replaced with a directory, rather than replacing its target.

#32 Updated by Mat Ellis almost 5 years ago

Any idea when this will be released? I just tested with 2.7.1 and it still blows away a symlinked folder.

#33 Updated by James Turnbull almost 5 years ago

Matt – it’s in 2.6.9. The 2.7.0 release was frozen in RC when it was done so those commits will be merged upstream in 2.7.2.

#34 Updated by Mat Ellis almost 5 years ago

Aha! Thanks so much for clarifying James.

#35 Updated by James Turnbull almost 5 years ago

  • Status changed from Merged - Pending Release to Closed
  • Target version changed from 2.7.0 to 2.6.9

Also available in: Atom PDF