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
to.
Apr 17 10:55:37 test1 puppet-agent[1807]:
(/Stage[main]/Testserver/File[/var/lib/mysql/backups/current.sql.gz]/mode)
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+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
