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.
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. > > 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 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. > > ######################## > 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. 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. > > 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"], ################## > > 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. 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/ 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. > > But I would welcome anyone telling me I'm wrong! > > Look forward to people's thoughts. > > Cheers > > 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<puppet-users%2bunsubscr...@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/puppet-users?hl=en. > > -- 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.
