I think I've hit a minor permissions bug using
puppet-2.6.13-2.el6.noarch from EPEL on CentOS 6. In order to
reproduce production bugs on a test environment, I use puppet to copy
the latest backup to a test server, followed by the remainder of the
puppet-driven configuration necessary. I just started using symlinks,
so I added links => follow to the file type.

File {
group => root,
owner => root,

file { "/var/lib/mysql/backups/current.sql.gz":
backup => false,
links => follow,
source => "puppet:///files/backups/current.sql.gz",

When I kicked puppet on the test machine, it set the file permissions
to the permissions of the link itself, not the file the link pointed

Apr 17 10:55:37 test1 puppet-agent[1807]:
mode changed '644' to '777'

So the obvious workaround is to explicitly set the permissions on the
file type, instead of relying on puppet to preserve the permissions of
the source file.

puppetmaster # ls -l /var/lib/mysql/backups
-rw-r--r-- 1 root root 4330512 Apr 17 00:22 2012-04-17.sql.gz
lrwxrwxrwx 1 root root 14 Apr 17 10:45 current.sql.gz -> 2012-04-17.sql.gz

Put in a bug for this? (I don't currently appear to have permissions to do so.)

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+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.

Search Discussions

Discussion Posts

Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 1 of 3 | next ›
Discussion Overview
grouppuppet-users @
postedApr 17, '12 at 3:42p
activeApr 18, '12 at 6:29p

2 users in discussion

Adam Heinz: 2 posts Jcbollinger: 1 post



site design / logo © 2022 Grokbase