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

Bug #8847

Symlinks in directories copied in a recursive 'file' resource will not be copied if they don't resolve on the puppet master

Added by Sam Cannell over 2 years ago. Updated 8 months ago.

Status:Needs More InformationStart date:08/08/2011
Priority:NormalDue date:
Assignee:Nigel Kersten% Done:

0%

Category:file
Target version:-
Affected Puppet version:2.6.2 Branch:
Keywords:

We've Moved!

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

This ticket may be automatically exported to the PUP project on JIRA using the button below:


Description

Consider the following puppet module:

puppetmaster:/etc/puppet # find modules/symlinktest/
modules/symlinktest/
modules/symlinktest/files
modules/symlinktest/files/tmp
modules/symlinktest/files/tmp/symlinktest
modules/symlinktest/files/tmp/symlinktest/symlink
modules/symlinktest/manifests
modules/symlinktest/manifests/init.pp 

puppetmaster:/etc/puppet # cat modules/symlinktest/manifests/init.pp 
class symlinktest {
    file { "/tmp/symlinktest":
        source  => "puppet://${servername}/modules/${module_name}/tmp/symlinktest",
        recurse => true,
    }
}

‘symlink’ in the symlinktest directory is a symbolic link pointing to a file outside the directory being copied:

puppetmaster:/etc/puppet # ls -l modules/symlinktest/files/tmp/symlinktest/symlink 
lrwxrwxrwx 1 root puppet 9 2011-08-09 17:00 modules/symlinktest/files/tmp/symlinktest/symlink -> /etc/file 

The file referenced by the symbolic link does not exist on the puppet master:

puppetmaster:/etc/puppet # ls -l /etc/file
ls: cannot access /etc/file: No such file or directory

Trying to run this module on a client will fail trying to create ‘symlink’:

client:~ # puppetd -tv
info: Caching catalog for puppetmaster.domain
info: Applying configuration version '1312866094'
notice: /Stage[main]/Symlinktest/File[/tmp/symlinktest]/ensure: created
err: /File[/tmp/symlinktest/symlink]: Could not evaluate: Could not retrieve information from source(s) puppet://puppetmaster.domain/modules/symlinktest/tmp/symlinktest/symlink
notice: Finished catalog run in 10.50 seconds

If I create the file on the puppet master (once again, note that this file is outside the /etc/puppet tree) the module runs fine:

puppetmaster:/etc/puppet # touch /etc/file 

client:~ # puppetd -tv
info: Caching catalog for puppetmaster.domain
info: Applying configuration version '1312866094'
notice: /Stage[main]/Symlinktest/File[/tmp/symlinktest]/ensure: created
notice: /File[/tmp/symlinktest/symlink]/ensure: created
notice: Finished catalog run in 10.51 seconds

client:~ # ls -l /tmp/symlinktest/
total 0
lrwxrwxrwx 1 root puppet 9 2011-08-09 17:06 symlink -> /etc/file

This issue occurs whether the class is contained within a module or the base manifests. It appears to affect puppet 2.6.2 but not 0.25.4.

History

#1 Updated by James Turnbull over 2 years ago

  • Status changed from Unreviewed to Needs More Information
  • Assignee set to Sam Cannell

Hi Sam – what behaviour were you expecting? Should Puppet create a dangling symlink?

#2 Updated by Sam Cannell over 2 years ago

Hi James,

Creating a dangling symlink on the client works fine, but that’s not what I’m trying to do here.

The issue I’m having is that the symlink will not be created on the client if the link’s target does not exist on the puppet master – i.e., in the example above if ‘/etc/file’ does not exist on the master.

Here’s a real-world example — let’s say you’re trying to push out an /etc/apache/ directory to a web server. The directory contains symlinks – for instance, ‘/etc/apache/sites-enabled/000-default’ is a symlink to ‘/etc/apache/sites-available/default’.

If apache is not installed on the puppet master, and thus /etc/apache/sites-available/default does not exist, then creation of the symlink on the puppet client will fail.

#3 Updated by James Turnbull over 2 years ago

  • Assignee changed from Sam Cannell to Nigel Kersten

Oh. Okay that’s weird and probably a bug,

Nigel – bug? Lots of twisty paths all alike….

#4 Updated by Nigel Kersten over 2 years ago

This should be what links => manage was meant to cover.

http://docs.puppetlabs.com/references/stable/type.html#file

Does that work for you Sam?

#5 Updated by Sam Cannell over 2 years ago

Hi Nigel,

No, the behavior I’ve described occurs whether or not ‘links => manage’ is explicitly set in the file resource.

Thanks,

Sam

#6 Updated by Bengt Giger 8 months ago

Hi

We ran into this bug with Puppet v3.1.1

Our use case are files that are placed on clients, on the puppet master they reside in different repositories but not at the path set in the symlinks.

Or they are generated on the clients and do not exist on the master. Placing fake files to make the symlinks valid is not really an option as it would clutter the disk of the master with misplaced files.

The result of copying or skipping a (not intended) dangling link is the same: something probably will fail. But the result of skipping a intended dangling link is not the same, the system fails while it would not if the link would have been copied.

And if the source is a dangling link, there should be no check if the target is a valid or a dangling link. The link target may or may not exist, depending of what the system administrator wants to achieve.

Regards Bengt

Also available in: Atom PDF