> 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.
>> ##################
>>>
>>> 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.
Anyway as other people mentioned /files/ is rather deprecated and you
should look into modules to organize your code.
>> 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.
~pete
[1] http://projects.puppetlabs.com/issues/86
--
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.
