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

Bug #1915

File resources fail when original is a dangling symlink

Added by micah - almost 6 years ago. Updated over 2 years ago.

Status:ClosedStart date:01/28/2009
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:file
Target version:2.7.9
Affected Puppet version:0.24.7 Branch:
Keywords:Problem #85

We've Moved!

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

This issue is currently not available for export. If you are experiencing the issue described below, please file a new ticket in JIRA. Once a new ticket has been created, please add a link to it that points back to this Redmine ticket.


Description

If before puppet has run, my host has the following dangling symlink:

$ ls -l /etc/motd
lrwxrwxrwx 1 root root 13 2006-09-26 23:46 /etc/motd -> /var/run/motd
$ ls -ld /var/run/motd
ls: cannot access /var/run/motd: No such file or directory

Then I define a file resource for this host as follows:

    file{"/etc/motd":
        content => ("foo"),
        owner => root, group => 0, mode => 0644;
    }

Puppet then files to create that file, due to the dangling symlink:

err: //motd::client/File[/etc/motd]: Failed to retrieve current state of resource: Could not read /etc/motd: No such file or directory - /etc/motd

I’ve tried various parameters to the file resource to override this such as backup => false, link => ignore, force => true and they all fail.

It seems like puppet should just remove the dangling symlink and replace it with what should be there, rather than error when the current state of the resource is in error.


Related issues

Duplicated by Puppet - Bug #3453: puppet client silently ignores symlinks Duplicate 03/30/2010

History

#1 Updated by Luke Kanies almost 6 years ago

  • Status changed from Unreviewed to Needs More Information

Have you tried ‘links => manage’?

#2 Updated by micah - almost 6 years ago

Yes, links => manage fails in the same way.

Incidentally, the documentation mentions that ‘ignore’ is an option to links, but when i tried it I got this error:

err: Could not create /etc/motd: Parameter links failed: Invalid ‘links’ value “ignore”. Valid values are follow, manage.

#3 Updated by Luke Kanies over 5 years ago

  • Status changed from Needs More Information to Accepted

#4 Updated by Teyo Tyree about 5 years ago

  • Keywords set to Problem #85

I have a workaround, but it’s horrible.

SETUP:

ln -s foo bar

run puppet on the following test.pp: $filename = “/Users/jbarratt/bar” file { “$filename”: ensure => file, links => manage, replace => true, content => “well, crap.”, force => true, }

And you fail on the error:

debug: //File[/Users/jbarratt/bar]/checksum: Initializing checksum hash debug: //File[/Users/jbarratt/bar]/checksum: Not checksumming symlink err: //File[/Users/jbarratt/bar]: Failed to retrieve current state of resource: Could not read /Users/jbarratt/bar: No such file or directory – /Users/jbarratt/bar debug: Finishing transaction 16030800 with 0 changes

The workaround is to add an extra exec { }:

$filename = “/Users/jbarratt/bar”

exec { “uglyhack$filename”: command => “/bin/rm -f $filename”, onlyif => “/bin/test -L $filename”, } file { “$filename”: ensure => file, links => manage, replace => true, content => “well, crap.”, force => true, require => Exec[“uglyhack$filename”], }

Which works, but is horrible and hackish.

debug: //File[/Users/jbarratt/bar]/require: requires Exec[uglyhack/Users/jbarratt/bar] debug: //Exec[uglyhack/Users/jbarratt/bar]: Skipping automatic relationship with File[/Users/jbarratt/bar] debug: //Exec[uglyhack/Users/jbarratt/bar]: Executing check ‘/bin/test -L /Users/jbarratt/bar’ debug: Executing ‘/bin/test -L /Users/jbarratt/bar’ debug: //Exec[uglyhack/Users/jbarratt/bar]: Changing returns debug: //Exec[uglyhack/Users/jbarratt/bar]: 1 change(s) debug: //Exec[uglyhack/Users/jbarratt/bar]: Executing ‘/bin/rm -f /Users/jbarratt/bar’ debug: Executing ‘/bin/rm -f /Users/jbarratt/bar’ notice: //Exec[uglyhack/Users/jbarratt/bar]/returns: executed successfully debug: //File[/Users/jbarratt/bar]: File does not exist debug: //File[/Users/jbarratt/bar]: Changing ensure debug: //File[/Users/jbarratt/bar]: 1 change(s) debug: //File[/Users/jbarratt/bar]/checksum: Initializing checksum hash debug: //File[/Users/jbarratt/bar]: Creating checksum {md5}b670e3a1c7408e76521f9a4edeaa822a notice: //File[/Users/jbarratt/bar]/ensure: content changed ‘{md5}b670e3a1c7408e76521f9a4edeaa822a’ to ‘{md5}b670e3a1c7408e76521f9a4edeaa82

If puppet is managing a canonical resource on a filesystem, it should be able to specify and modify any attribute of that resource.

Ideally,

file { “/path/name”: content => “…”, ensure => file, }

should be all I need to do. Puppet’s job would be to transform my system to match the way the resources are modeling it’s reality.

#5 Updated by Luke Kanies about 5 years ago

  • Target version set to 2.6.0

#6 Updated by James Turnbull almost 5 years ago

  • Target version changed from 2.6.0 to 2.7.x

#7 Updated by Miguel Di Ciurcio Filho almost 3 years ago

I was reading the Learning Guide and the page http://docs.puppetlabs.com/learning/manifests.html suggests changing the login message by setting the content of /etc/motd. This is how I bumped into the same problem.

root@puppetmaster:/etc# ls -l /etc/motd
lrwxrwxrwx 1 root root 13 Jan  8 20:01 /etc/motd -> /var/run/motd
root@puppetmaster:/etc# cat /etc/motd
cat: /etc/motd: No such file or directory
file { "motd":
        path    => "/etc/motd",
        ensure  => present,
        content => "Message of the day!\n",
}
  • Running the code above, Puppet returns success but nothing happens. The target /var/run/motd is not created.
  • Using ‘links => follow’ Puppet overwrites the symlink and create a regular file at /etc/motd. This is not the documented behavior: “… and follow will manage the file to which the link points.” from http://docs.puppetlabs.com/references/stable/type.html
  • Using ‘links => manage’ nothing happens.

Another point is that the documentation about ‘links’ is inconsistent. It says:

How to handle links during file actions. During file copying, follow will copy the target 
file instead of the link, manage will copy the link itself, and ignore will just pass it by.
When not copying, manage and ignore behave equivalently (because you cannot really ignore
links entirely during local recursion), and follow will manage the file to which the link
points. Valid values are follow, manage.

It mentions ‘ignore’ but it is not a valid value as mentioned in the last phrase.

# puppet apply motd.pp 
Parameter links failed: Invalid value "ignore". Valid values are follow, manage.

Bottom line is that ‘links => follow’ is not creating the target file if the symlink is dangling and the documentation about ‘links’ needs some corrections.

I did my tests using version 2.7.6.

#8 Updated by Wil Cooley almost 3 years ago

  • Status changed from Accepted to Closed

This appears to have been fixed with 2.7.9:

    exec { 'mklink':
      command => '/bin/ln -sf /tmp/foo-1915 /tmp/bar-1915'
    }
    exec { 'test-pre-file1':
      command   => '/bin/ls -lF /tmp',
      require   => Exec['mklink'],
      logoutput => true,
    }
    file { '/tmp/bar-1915':
      content => 'foo',
      require => Exec['test-pre-file1'],
    }
    exec { 'test-post-file1':
      command   => '/bin/ls -lF /tmp',
      require   => File['/tmp/bar-1915'],
      logoutput => true,
    }
    exec { 'test-post-file2':
      command => '/bin/cat /tmp/bar-1915',
      require => Exec['test-post-file1'],
      logoutput => true,
    }                   

Output:

notice: /Stage[main]//Exec[mklink]/returns: executed successfully
notice: /Stage[main]//Exec[test-pre-file1]/returns: total 0
notice: /Stage[main]//Exec[test-pre-file1]/returns: lrwxrwxrwx 1 wcooley wcooley 13 Jan 21 13:21 bar-1915 -> /tmp/foo-1915
notice: /Stage[main]//Exec[test-pre-file1]/returns: -rw------- 1 wcooley wcooley  0 Jan 21 13:21 puppet.5886.0
notice: /Stage[main]//Exec[test-pre-file1]/returns: executed successfully
notice: /Stage[main]//File[/tmp/bar-1915]/ensure: defined content as '{md5}acbd18db4cc2f85cedef654fccc4a4d8'
notice: /Stage[main]//Exec[test-post-file1]/returns: total 4
notice: /Stage[main]//Exec[test-post-file1]/returns: -rw-r--r-- 1 wcooley wcooley  3 Jan 21 13:21 bar-1915
notice: /Stage[main]//Exec[test-post-file1]/returns: -rw------- 1 wcooley wcooley  0 Jan 21 13:21 puppet.5886.0
notice: /Stage[main]//Exec[test-post-file1]/returns: executed successfully
notice: /Stage[main]//Exec[test-post-file2]/returns: foo
notice: /Stage[main]//Exec[test-post-file2]/returns: executed successfully
notice: Finished catalog run in 0.29 seconds

As you can tell from the output, /tmp/bar-1915 exists and points to the non-existent /tmp/foo-1915. The file resource is created as a regular file and has the appropriate content.

#9 Updated by Anonymous over 2 years ago

  • Target version changed from 2.7.x to 2.7.9

Also available in: Atom PDF