On 14/12/10 18:53, Peter Meier wrote:
OK - I think this should be a "feature request". The logic would go:
"If installing a file on the target, create the path to the target
root.root, mode 0755.
Only the edge cases of other ownerships or different modes would need
explicit configuration then.
Uh, that sounds easier as it is, just have a look at [1] to get an idea
of a lot of edge cases that you didn't think of.
Hi Peter,
I would disagree there. Agreed - it is quite common to have to fix the
file modes, but at "the last place" we had a near microscopic number of
*directories* that had files dist'd into them where mode 0755 wasn't
good enough and we had to have a separate perl script to fix those up
prior to disting out the contents.
The edge case was generally things like where ssl private keys sat, but
we didn't dist those as the one weakness with our system was it was
necessarily on world readable NFS.
Puppet does have that one big advantage that secure files can be sent out.
##################
At first glance puppet seems extremely verbose (though I do like the
certificate handling). To my mind a config management system should
be solid
in its code but simple in its managemnet and I'm not getting the
"simple in
its management" right now.
Simple and verbose are not mutually exclusive. In fact, you could
argue that
they often go hand-in-hand. There's very little ambiguity in what Puppet
does. This means that you have to instruct it precisely, yes, but it also
means that troubleshooting often becomes simpler.
True - but if I need to ship out an arbitrary file in a hurry (say a
modules blacklist to work around a vulnerable kernel module) I would
like to just be able to lob a file in and have it go without creating
several aspects of the config, each one prone to typos and thus not
working.
Puppet gives you a lot of possibilities, but you can always abstract
things away to "enforce" your convention. If you really want to stick
with _your_ convention (mirror fs-tree) then you can always create a
define, like:
define myconvention::file(
$owner, $group, $mode
){
file {$name:
mode => $mode,
owner => $owner,
group => $group,
source => "puppet:///files/${name}"
}
}
As you can already see, path and ensure are anyway already unnecessary
in your example.
So this would then make your syslog class look the following way:
class syslog {
myconvention::file{"/etc/syslog-ng/syslog-ng.conf":
mode => 644,
owner => root,
group => root,
notify => Service[syslog],
}
}
And you wrapped away most things that were verbose to you.
Bingo! OK - I am liking this much more now! I hadn't go into the power
of the "define". Looking promising...
I like policy because it makes it easier for the "other guy" IME - once
they get used to the convention, they can quickly know where to find
stuff. My colleague likes puppet (or to be honest I would have just
reimplemented the "last place"'s system - but he agrees our current
actual puppet setup isn't very good - so at least I can fix that without
upsetting him.
Anyway as other people mentioned /files/ is rather deprecated and you
should look into modules to organize your code.
Does that stop me from keeping all my config files under a common tree?
I agree that documentation is sometimes out of date or weak in particular
areas, but that's a typical weakness of fast-moving open source
applications. That's also why wikis are community-editable.
That's understood - no problems with that.
Also note, that puppetlabs (especially James) happily accept
documentation tickets (and patches!)
What I think is missing either from puppet or the docs is a "how to ship
half dozen sshd_config files by host class". If puppet can achieve this
(and I think it is conceptually vital that it can as it is such a common
admin function) I'm more than happy to write up a wiki howto.
There are some modules out there in the wild that do that.
I'll keep an eye out. I might well write my own - puppet does at least
have a way AFAICS to add user code in.
~pete
[1] http://projects.puppetlabs.com/issues/86
Many thanks for all this - your powers of advocacy are excellent!
--
Tim Watts
Personal Email
--
You received this message because you are subscribed to the Google Groups "Puppet
Users" group.
To post to this group, send email to puppet-us...@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.
