On Aug 27, 1:54 pm, Elijah Wright <elijah.wri...@gmail.com> wrote:
> We're having an odd, sort of interesting issue with one of our puppet file
> objects. We've had it in place for several months, and are now trying to
> move the content to a directory on another (emptier) filesystem, and make
> the old file object a straight-up symlink to the new location.
>
> When we roll the new revision of the puppet manifest out, puppet was failing
> to realize that the directory had been turned into a symlink, and tried to
> back up the TARGET of the symlink into the clientbucket.
So there you had a config that ran without error (i.e. unlike the
variations you describe below)?
> After some consultation with folks in the channel, we made some tweaks and
> wound up with this:
>
> (//Node[default]/sched-node/sched-bits/mongrel-directories/File[/home/rails/someclient/production/shared/log]/ensure)
> change from absent to link failed: Could not set link on ensure: No such
> file or directory - /mnt/railslog or
> /home/rails/someclient/production/shared/log/ at
> /etc/puppet/manifests/classes/mongrel.pp:261
>
> At this point we had an object definition that looked like this:
>
> file {
> "/home/rails/someclient/$rails_env/shared/log/":
> target => "/mnt/railslog",
> ensure => link,
> backup => false,
> }
>
> When this is run, we get the error above.
Per the docs of the File type (http://reductivelabs.com/trac/puppet/
wiki/TypeReference#file), you must use force => true to change an
existing directory to a symlink. Moreover, no special meaning is
documented for ensure => link, so unless that's an omission from the
docs, the result of your manifest would be a (relative) symlink to
"link". Furthermore, that use of the "target" property does not
appear consistent with its docs.
> Some suggestions from the channel were that we change back to using ensure
> => "/mnt/railslog"; after doing so, we get this trio of errors:
And despite the errors, I think that's what you need.
> stanza:
>
> file {
> "/home/rails/someclient/$rails_env/shared/log/":
>
> ensure => "/mnt/railslog",
> backup => false,
> }
>
> produces:
>
> Aug 27 14:18:37 sched4 puppetd[2725]:
> (//Node[default]/sched-node/sched-bits/mongrel-directories/File[/home/rails/someclient/production/shared/log])
> Not removing directory; use 'force' to override
> Aug 27 14:18:37 sched4 puppetd[2725]:
> (//Node[default]/sched-node/sched-bits/mongrel-directories/File[/home/rails/someclient/production/shared/log])
> Not removing directory; use 'force' to override
> Aug 27 14:18:37 sched4 puppetd[2725]:
> (//Node[default]/sched-node/sched-bits/mongrel-directories/File[/home/rails/someclient/production/shared/log]/ensure)
> change from directory to link failed: Could not remove existing file
>
> Both /home/rails/someclient/production/shared/log and its target,
> /mnt/railslog, already exist and are in an acceptable state.
Puppet is telling you that it will not replace a directory with a
symlink unless you tell it force => true.
> Further attempts - we turned on links => manage and force => true - to no
> real effect. We still get:
>
> Aug 27 14:45:01 sched4 puppetd[4849]:
> (//Node[default]/sched-node/sched-bits/mongrel-directories/File[/home/rails/someclient/production/shared/log]/ensure)
> change from directory to link failed: Could not remove existing file
I think this is the right direction, though I am uncertain whether you
need links => manage.
> Any ideas? This is rather baffling - we have symlinks elsewhere that work,
> work fine, and have worked for a good long while now... but something screwy
> is going on here!
I think the key thing to investigate is why Puppet is unable to remove
the original directory when it tries to do so (last attempt). In my
(limited) experience, Puppet attempts a recursive deletion of the
directory in that case, and it looks like that's failing. Running
with debug output enabled on the client might give you a clue of
what's wrong.
If you want puppet to both move the existing directory and link to the
new location in a single run, then I think you need two separate
resources, with a dependency between them to fix the order.
Presumably an Exec to perform the move and a File to manage the link
would do the trick. If you go that route then do make sure the Exec
has suitable tests to ensure that it only runs when you want it to do.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---
