The Puppet Labs Issue Tracker has Moved: https://tickets.puppetlabs.com
https://tickets.puppetlabs.com. See the following page for information on filing tickets with JIRA:
puppet replaces configuration directories when they are symlinks
|Affected Puppet version:||0.24.7||Branch:|
Ticket tracking is now hosted in JIRA: https://tickets.puppetlabs.com
[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
#12 Updated by Jason Harvey over 5 years ago
- Target version deleted (
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.
#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.
#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.
#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.