Hi and thanks for the detailed reply :)
On 14/12/10 16:38, Rameses Mss wrote:
General suggestions:
- Try not to fight Puppet. It's good but does require a certain way of
thinking. Work with it and you'll get where you want to go.
- Verbosity is not necessarily a bad thing in relatively static
configuration files. Perlophiles usually hate verbosity, I know, but it has
its place.
- To reduce verbosity, look into resource defaults. They're handy.
OK - I shall do that.
More specifics inline.
On Tue, Dec 14, 2010 at 10:33 AM, Tim Watts<t...@dionic.net> wrote:
Hi,
I'm learning puppet as that is what they use at my current work, though
that could change...
Question 1:
Last place of work, we wrote our own perl based system which was extremely
simple and concise to drive - eg to distribute a file, we would put it in:
<nfsdir>/noarch/dist/etc/syslog-ng/syslog-ng.conf/ # which means create a
file /etc/syslog-ng/syslog-ng.conf on the target
The contents of the file would be derived from a class based system, eg, in
the above<nfsdir> the following might exist:
BASE
SERVER
CLIENT
somehost
each with a copy of syslog-ng.conf applicable to that class of host.
Each host would be in one or more classes, where a class was also a class
member - until you hit the root class, eg:
somewebserver [isin] WEBSERVER [isin] SERVER [isin] BASE
somelabpc [isin] LAB1PC [isin] LABPC [isin] CLIENT [isin] BASE
Order matters and the class list for a host deterministically resolves to
an ordered list.
So for the example of somewebserver (the host name), it would pick up
/etc/syslog-ng/syslog-ng.conf from
<nfsdir>/noarch/dist/etc/syslog-ng/syslog-ng.conf/SERVER
as that is the most specific applicable class.
Everything would by default use
<nfsdir>/noarch/dist/etc/syslog-ng/syslog-ng.conf/BASE
unless a more specific case existed.
It is trivially possible to add a per host exception for myhost just by
adding a new file called "myhost" into
<nfsdir>/noarch/dist/etc/syslog-ng/syslog-ng.conf/
[We had a simple way of dealing with file modes etc which I'll leave out
for brevity]
This is not the way Puppet works.
Right. Now I'm not sure I see further down a solution unless it falls
out of one of the environment or selector bits - I'll offer a standard
"problem" and ask what the "puppet way" is if I may...
OK - /etc/ssh/sshd_config - it's very common on a large uni site to have
several versions - one for servers, one for staff PCs, another for
student PCs, another for a "really secure server" and also to have
ad-hoc exceptions on odd named PCs.
If you don't like sshd_config, then mentally substitute /root/.k5login
How does one handle this cleanly and concisely in puppet, based on the
node inheritance scheme?
In Puppet I seem to have to write a module/whatever.pp to set up the fact a
file is managed. OK, fair enough - I "get" that part of the model.
I also see some sort of linear class inheritance scheme in nodes.pp/
What I don't get is how to leverage that inheritance scheme...
Are there any magic variables that allow me to do something like:
source => [ "puppet:///files/resolv.conf/$mostspecificclass
"puppet:///files/resolv.conf/BASE"
]
Note my use of "class" differs from puppets, so please work around that - I
don't know the correct terminology but it is the on ebased on the
inheritance scheme in nodes.pp which seems sensible.
There aren't magic variables for that, no. But you can use environments,
facter variables, parameters provided by a custom nodes script or
extlookup() source
That sounds interesting.
to accomplish the same thing. You'll also want to look up
selectors and other conditionals in
http://docs.puppetlabs.com/guides/language_tutorial.html.
Finally, it's usually better to use ERB templates for files that differ
slightly than it is to use totally separate files.
OK - will look into these.
########################
Question 2
Related:
In a simple case as per documentation:
class syslog {
file { "/etc/syslog-ng/syslog-ng.conf":
path => "/etc/syslog-ng/syslog-ng.conf",
ensure => file,
mode => 644,
owner => root,
group => root,
notify => Service[syslog],
source => "puppet:///files/etc/syslog-ng/syslog-ng.conf"
}
}
is there no variable for the first instance of
"/etc/syslog-ng/syslog-ng.conf"
???
Mentioning a string 3 times or more strikes me as unnecessarily verbose and
likely to lead to typos.
There's no variable for it, but you only need one of them. If undefined,
"path" defaults to the name of the resource --
"/etc/syslog-ng/syslog-ng.conf" -- so you can just leave path out.
ah yes - I did figure that out in the meantime - one line down, good.
Source can be pared down to "puppet:///<modulename>/syslog-ng.conf" In your
file structure, that file would be located in
<modulepath>/<modulename/files/syslog-ng.conf. There's no reason to rebuild
your entire file system hierarchy below there as well.
It's personal taste - I prefer to mirror my sources with my targets -
when you eventually get into a 100+ files it's far easier IME to find
what sources what.
I really need to have a new guy be able to look at the source tree and
easily spot "ah that file affects this file on these hosts". It's the
way our homebrew system worked by designed evolution and I think it is
the best way once you get beyond a few files and a couple of "classes"
of hosts.
Question 3
#######################
What if /etc/syslog-ng doesn't exist?
Things will blow up.
I had to resolve that with this syslog.pp :
class syslog {
file { "/etc/syslog-ng":
path => "/tmp/etc/syslog-ng",
ensure => directory,
mode => 755,
owner => root,
group => root,
}
file { "/etc/syslog-ng/syslog-ng.conf":
path => "/tmp/etc/syslog-ng/syslog-ng.conf",
ensure => file,
mode => 644,
owner => root,
group => root,
notify => Service[syslog],
source => "puppet:///files/etc/syslog-ng/syslog-ng.conf"
}
}
or with a recurse:
class syslog {
file { "/etc/syslog-ng/syslog-ng.conf":
path => "/tmp/etc/syslog-ng",
recurse => true,
mode => 644,
owner => root,
group => root,
source => "puppet:///files/etc/syslog-ng"
}
}
First case is verbose again (yuk).
Second case is probably OK but if we have two modules that might want to
create files in a common directory that may or may not exist it's a bit
horrible.
Is there a simple way to say "just create any directories you need to with
default modes"?
I had a quick look at some of the source but couldn't spot any...
There isn't a way to automatically create the directories. In general, the
first way is the right way with this addition in the second file resource:
require => File["/etc/syslog-ng"],
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.
##################
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.
I am open minded but the documentation is a bit scattered (I even bought the
book "Pulling Strings with Puppet" and I'm going off it right now even to
the point of re-implementing the last system I thought was good.
I've found that the best way to learn Puppet is to do it with these pages
open in a browser:
http://docs.puppetlabs.com/guides/language_tutorial.html
http://docs.puppetlabs.com/references/latest/type.html
http://docs.puppetlabs.com/guides/style.html
http://docs.puppetlabs.com/guides/best_practices.html
All these are linked off http://docs.puppetlabs.com/
OK - thanks for those - I shall read them.
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.
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.
What I'm trying to find is the way to get there...
Many thanks for your time,
Tim
--
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.
