do not specify file modes unless relevant
MODULES-10583 makes a good point: "why are you messing with my file
permissions"? In my case, the entire reason I made the following
change (in PR #906):
ab2e06b72f2be8dc38d6e3ecec68dc2cdacbce4e MODULES-10548: make files readonly
... is exactly *because* Puppet was changing the file modes from under
me. I was migrating from our own in-house APT module to the forge one,
and our module did *not* intervene in those file modes: it left the
file resources alone. Which means we could have a directive like this:
File {
owner => root,
group => root,
mode => '444',
ensure => file,
}
... which made all files readonly by default. So when I migrated to
the Puppetlabs APT module, modes were changed to be writable, which I
did not want.
As I reasoned in MODULES-10548, having files readonly provides an
excellent indicator that a file is managed by Puppet, even if some
module does not add a warning header - either because it forgot or
because it's impossible. But I also understand if people do not like
that policy.
I think the proper way of doing this is not specifying a mode at all,
and let local site-specific policies apply. I specifically proppose
this as an alternative to #921 because I believe adding more
parameters to the resources will needlessly complicate the script,
when we have a native, Puppet-DSL supported way of changing those
modes according to the right scope and context.
In a similar way, we might want to reconsider user and group ownership
of the files, but that can be done in a later time.
This reverts commit
316fd8f4dd1eb6595b3be495ccc5f4924da4de1b.
Signed-off-by: Antoine Beaupré <anarcat@debian.org>