Hullo I''ve not used Puppet yet, so this could be an obvious misunderstanding on my part. I''ve seen many manifest entries for files that write rules about file ownership and permissions. Surely these types of attributes should be managed through the package managers, with a possible override if there are any package errors. Otherwise, you''ve got to replicate an existing set of information in a new format. Am I missing something, or is there a simple way of working that just uses the ownership and permissions available in the package managers? cheers Tim -- 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.
Hi Tim,
You can just tell Puppet not to manage the file permissions at all,
like this, which just specifies the content:
file { "/etc/syslog.conf":
source => ...
}
I''ll assume you''re talking about something like this?
file { "/etc/syslog.conf":
owner => "root",
group => "root",
mode => "0644",
source => ...
}
So the idea being to enforce permissions on specific files, usually so
it''s owned by the right person for the software, and for enforcing
security. You''re right, it''s replicated in whatever package
system
you''re using though. Sometimes you might want to override the package
manager''s settings though.
Taking the "rpm" package provider for an example, I guess Puppet could
use ''rpm --verify'' to find out if the permissions on the file
you''re
interested in have changed, but not what they''ve changed from without
unpacking the RPM. An ''rpm --freshen'' would overwrite the
content of
the file in question (or drop in an .rpmnew file) so not the best idea
either.
Theoretically Puppet could do it, but it would be quite a development
task: there''s a lot of package providers, each backing onto different
package management systems that do their file permissions in all
different ways (or maybe sometimes not at all?), then you''d have to
add to the File resource itself to query said package management
systems regarding a specific package that this file is created by,
that''s a lot of overhead.
-Luke
On Mar 9, 11:11 am, Tim Coote <tim.coo...@googlemail.com>
wrote:> Hullo
> I''ve not used Puppet yet, so this could be an obvious
misunderstanding
> on my part. I''ve seen many manifest entries for files that write
rules
> about file ownership and permissions. Surely these types of attributes
> should be managed through the package managers, with a possible
> override if there are any package errors. Otherwise, you''ve got to
> replicate an existing set of information in a new format.
>
> Am I missing something, or is there a simple way of working that just
> uses the ownership and permissions available in the package managers?
>
> cheers
>
> Tim
--
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.
Hi Luke Thanks. Your examples are correct and I''m sorry for not including them in my original post. I think that your first suggestion is the way for me to go. I do think that this should be elaborated as best practice (if that''s what it is). I did have rpm (yum) in mind as the PM. There are some circumstances where I''d want to overwrite the permissions/ownership of a file in an rpm, but in that case, I ought to roll my own rpm, I think. I know that it''s tough to put a consistent abstraction over package managers, but I want to avoid encouraging my people to do the wrong things by clearly defining the distinction between the PM and Puppet. If I''ve got it right, the basic idea behind using Puppet is that I apply its rules to known build start points. The tests for a particular set of rules should allow me to move from one version of a start point to another and confirm that the upgrade hasn''t broken anything (eg go from RHEL 7 to RHEL 8, or from my internal version of something equivalent. I must be able to replicate the build of the start point. If I''m writing anything that modifies start point configurations, I''m likely to start breaking them in unpredictable ways as much effort will have gone into getting them consistent and my mods are likely to interfere with that consistency. Tim On Mar 9, 3:40 pm, Luke Bigum <Luke.Bi...@lmax.com> wrote:> Hi Tim, > > You can just tell Puppet not to manage the file permissions at all, > like this, which just specifies the content: > > file { "/etc/syslog.conf": > source => ... > > } > > I''ll assume you''re talking about something like this? > > file { "/etc/syslog.conf": > owner => "root", > group => "root", > mode => "0644", > source => ... > > } > > So the idea being to enforce permissions on specific files, usually so > it''s owned by the right person for the software, and for enforcing > security. You''re right, it''s replicated in whatever package system > you''re using though. Sometimes you might want to override the package > manager''s settings though. > > Taking the "rpm" package provider for an example, I guess Puppet could > use ''rpm --verify'' to find out if the permissions on the file you''re > interested in have changed, but not what they''ve changed from without > unpacking the RPM. An ''rpm --freshen'' would overwrite the content of > the file in question (or drop in an .rpmnew file) so not the best idea > either. > > Theoretically Puppet could do it, but it would be quite a development > task: there''s a lot of package providers, each backing onto different > package management systems that do their file permissions in all > different ways (or maybe sometimes not at all?), then you''d have to > add to the File resource itself to query said package management > systems regarding a specific package that this file is created by, > that''s a lot of overhead. > > -Luke[snip] -- 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.