puppet turning a file into a directory

134 views
Skip to first unread message

Chris

unread,
Dec 2, 2014, 11:03:53 PM12/2/14
to puppet...@googlegroups.com
Hi,

This is a very strange one. On my CA server (which also runs puppet as
an agent to control various things), sometimes a file gets turned into a
directory. It's only this file and on this server (the other puppet
controlled servers don't have this issue).

Using puppet 3.7.3 from the puppetlabs yum repo.

My manifest has this:

file { '/usr/local/sbin/duplicity-backup.sh':
ensure => file,
owner => 'root',
group => 'root',
mode => '0755',
source => 'puppet:///modules/duplicity/duplicity-backup.sh',
}

so pretty simple. The source exists and is a bash script.

It starts off as a file:

Dec 2 23:47:28 server puppet-agent[1072]:
(/Stage[main]/Duplicity/File[/usr/local/sbin/duplicity-backup.sh]/ensure) defined
content as '{md5}db1ad110a94782a2e0edc9f1b650a854'

but turns into a directory:

Dec 3 00:54:12 server puppet-agent[23986]:
(/Stage[main]/Duplicity/File[/usr/local/sbin/duplicity-wrapper.sh])
Could not evaluate: Could not retrieve file metadata for
puppet:///modules/duplicity/duplicity-wrapper.sh: Could not intern from
text/pson: undefined method `delete' for
#<Puppet::Resource::Catalog:0x7f3b29db1468>
Dec 3 00:54:12 server puppet-agent[23986]:
(/Stage[main]/Duplicity/File[/usr/local/sbin/duplicity-wrapper.sh])
Wrapped exception:
Dec 3 00:54:12 server puppet-agent[23986]:
(/Stage[main]/Duplicity/File[/usr/local/sbin/duplicity-wrapper.sh])
Could not intern from text/pson: undefined method `delete' for
#<Puppet::Resource::Catalog:0x7f3b29db1468>
Dec 3 00:54:12 server puppet-agent[23986]:
(/Stage[main]/Duplicity/File[/usr/local/sbin/duplicity-backup.sh]/ensure) ensure
changed 'file' to 'directory'


Any help/ideas/suggestions would be great :)

Thanks!
--
Postgresql & php tutorials
http://www.designmagick.com/

jcbollinger

unread,
Dec 3, 2014, 9:31:19 AM12/3/14
to puppet...@googlegroups.com


I suggest you examine the node's cached copy of its catalog immediately after such an event (before it is overwritten by the next catalog request).  If in fact the resource File[/usr/local/sbin/duplicity-backup.sh] has 'file' as the value of its 'ensure' property, then file a bug report, and tick up the severity / priority.  Bugs involving Puppet destroying data should -- and generally do -- get quick attention.  The catalog is human-readable, though not exactly easy to read.

My suspicion, however, is that that catalog actually specifies 'ensure' => 'directory'.  In that case, you'll need to focus your troubleshooting on why that's so.  The declaration you presented clearly specifies 'file', but it is possible for that to be overridden elsewhere in your manifest set.  Alternatively, it may be that the declaration you present is not always the one that is used.  If you have multiple masters (e.g. in a load-balancing setup) and their manifest sets, ENCs, or hiera data are not in sync, then you might randomly get a different declaration.  Or if you have multiple environments defined, and for some reason the affected server is occasionally assigned to the wrong one, then you might get a different declaration.  There are many other possibilities.


John

Trevor Vaughan

unread,
Dec 3, 2014, 10:29:23 AM12/3/14
to puppet...@googlegroups.com
Also, check to see if you have an exec somewhere that might be causing this and you're seeing a flapping issue.

Trevor

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/0e69cfd0-d7c6-4f9a-97ee-74ce59660ec8%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.



--
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699
tvau...@onyxpoint.com

-- This account not approved for unencrypted proprietary information --

Chris

unread,
Dec 9, 2014, 4:04:39 PM12/9/14
to puppet...@googlegroups.com
Just posting a follow up.

On 04/12/14 01:31, jcbollinger wrote:
> Or if you have multiple environments defined, and for some reason the
> affected server is occasionally assigned to the wrong one, then you
> might get a different declaration. There are many other possibilities.

This was the case. I had other environments where it was declared as
just 'present' rather than 'file' and it was switching to one of those.
Since I've updated the other environments, it hasn't happened again.

Thanks for the help and ideas.

jcbollinger

unread,
Dec 10, 2014, 9:15:59 AM12/10/14
to puppet...@googlegroups.com


On Tuesday, December 9, 2014 3:04:39 PM UTC-6, chris smith wrote:
Just posting a follow up.

On 04/12/14 01:31, jcbollinger wrote:
> Or if you have multiple environments defined, and for some reason the
> affected server is occasionally assigned to the wrong one, then you
> might get a different declaration.  There are many other possibilities.

This was the case. I had other environments where it was declared as
just 'present' rather than 'file' and it was switching to one of those.
Since I've updated the other environments, it hasn't happened again.

Thanks for the help and ideas.



Thanks for the followup.

This is still strange, however: ensuring 'present' should never modify a file or directory that is in fact initially present.  It certainly should not convert a file to a directory, for if neither file nor directory nor symlink is initially present, then ensuring 'present' creates an empty file.  In any case, I'm glad the issue is resolved.


John

Reply all
Reply to author
Forward
0 new messages