Puppet users - Dec 2010 - n00b questions - verbosity of config????

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]

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.


########################
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.

Question 3

#######################

What if /etc/syslog-ng doesn''t exist?

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...


##################

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.

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.

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-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.

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 <tw@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-users@googlegroups.com.
> To unsubscribe from this group, send email to
>
puppet-users+unsubscribe@googlegroups.com<puppet-users%2Bunsubscribe@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-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.

On 12/14/2010 7:33 AM, Tim Watts wrote:
> ########################
> 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.
Yeah your a perl guy, I do the same thing, it''s force of habit.  The 
example doesn''t do a great job of highlighting that that string is 
actually 3 completely different things so why not use 3 different names?

class syslog {
     file { "syslog":
         path => "/etc/syslog-ng/syslog-ng.conf",
         ensure => file,
         mode => 644,
         owner => root,
         group => root,
         notify => Service[syslog],
         source => "puppet:///files/base_syslog.conf"
     }
}



-- 
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.

On 14/12/10 17:07, psyber wrote:
> On 12/14/2010 7:33 AM, Tim Watts wrote:
>> ########################
>> 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.
Hi, and thanks for the reply...
> Yeah your a perl guy,
Yep!
>  I do the same thing, it''s force of habit. The
> example doesn''t do a great job of highlighting that that string is
> actually 3 completely different things so why not use 3 different names?
>
> class syslog {
> file { "syslog":
> path => "/etc/syslog-ng/syslog-ng.conf",
> ensure => file,
> mode => 644,
> owner => root,
> group => root,
> notify => Service[syslog],
> source => "puppet:///files/base_syslog.conf"
> }
> }
OK - I did work out that the "path" is optional if the file block
"name"
is the same,

I''m not in agreement with the abbreviated source line though - I like
my
files to be in the same basic tree as the target so I can find stuff and 
naming is fully deterministic - force of habit but I like that habit(!).

I presume, if I really wanted to, I could implement a new "file"
module
with a slightly different name to follow my preferred logic? I like the 
puppet "outer skeleton" but I''m not digging the file
handling...

Have to learn ruby though...

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-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.

> OK - I did work out that the "path" is optional if the file block
"name"
> is the same,
> 
> I''m not in agreement with the abbreviated source line though - I
like my
> files to be in the same basic tree as the target so I can find stuff and
> naming is fully deterministic - force of habit but I like that habit(!).
> 
> I presume, if I really wanted to, I could implement a new "file"
module
> with a slightly different name to follow my preferred logic? I like the
> puppet "outer skeleton" but I''m not digging the file
handling...
I believe most people are bound to write this define sooner or later:

define my_file() {
  file { "$name":
    source => "puppet:///files/$name",
}

It''s a bit trickier to add support for all of file''s options,
but once
that''s in, it''s a huge advantage.

You should try and use modules, BTW. It saves pain down the road.

HTH,
Felix

-- 
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 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<tw@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-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.

On 14/12/10 17:54, Felix Frank wrote:
>> OK - I did work out that the "path" is optional if the file
block "name"
>> is the same,
>>
>> I''m not in agreement with the abbreviated source line though -
I like my
>> files to be in the same basic tree as the target so I can find stuff
and
>> naming is fully deterministic - force of habit but I like that
habit(!).
>>
>> I presume, if I really wanted to, I could implement a new
"file" module
>> with a slightly different name to follow my preferred logic? I like the
>> puppet "outer skeleton" but I''m not digging the file
handling...
>
> I believe most people are bound to write this define sooner or later:
>
> define my_file() {
>    file { "$name":
>      source =>  "puppet:///files/$name",
> }
Ah - I like that...
> It''s a bit trickier to add support for all of file''s
options, but once
> that''s in, it''s a huge advantage.
>
> You should try and use modules, BTW. It saves pain down the road.
OK...

Cheers!

Tim
> HTH,
> Felix
>

-- 
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-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.

On Tue, Dec 14, 2010 at 1:03 PM, Tim Watts <tw@dionic.net> wrote:
> 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?
>
This seems like it encapsulates most of your concerns, so I''m
addressing it.
If I dropped something you really wanted a reply to, say so.

There are many ways to do this, but this is the one I tend towards:

file { "/etc/sshd/sshd_config":
    ensure => present,
    owner  => "root",
    group  => "root",
    mode   => "0644",
    source => "puppet:///sshd/etc/sshd/sshd_config.${sshd_type}",
}

In your base node (i.e., top level inheritance) set a default:

node base {
    $sshd_type="client"
    include sshd
}

node myclient inherits base {
}

node myserver inherits base {
    $sshd_type="server"
}

This would require sshd_config.client. Override it on a per-node basis.
External nodes scripts make this sort of thing simpler.

-- 
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.

> 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-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.

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-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.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
>> 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?
Not explicitly, but the idea of modules is to put code together that
belongs together and separate it from the rest, that is unrelated to
that code. And with code you can read: manifests, configfiles,
templates, providers, facts, functions.

This means that you would find all the syslog related things in the
syslog module and all the sshd related things in the sshd module. Also
this enables you to share modules between different entities of your
company or even with the whole world if you are able to abstract them
that much that you can publish them as free software.

Puppet gives you here again a lot of possibilities how you can organize
your code and it certainly won''t stop you putting all files into one
module (read: the files module).

~pete
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk0H3R4ACgkQbwltcAfKi3/f8ACglx/w4mMaCckH+vM1stXb3tyK
MgUAn0IhAzqqgpq4uORw3tAkg3iTY4uv
=NgOz
-----END PGP SIGNATURE-----

-- 
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.

> I believe most people are bound to write this define sooner or later:
>
> define my_file() {
>   file { "$name":
>     source => "puppet:///files/$name",
>
> }
>
> It''s a bit trickier to add support for all of file''s
options, but once
> that''s in, it''s a huge advantage.
I use a similar define I shamelessly copied from someone else. Pasted
below in case it benefits others:

#Copy a file from the Puppet master.
#
#A good idea sourced from http://narrabilis.com/mybook/puppet/functions.pp
#Basically it''s a little wrapper for the file type that''s used
to copy
#a file from the puppet master. ''module'' and
''path'' are the only
required
#parameters.
#
#PARAMETERS:
#  - path    The path to the source file to copy as relative to
modules/<module name>/files/.
#  - module  The name of the module to copy the file from.
#  - mode    Parameter passed directly to File type.
#  - owner   Parameter passed directly to File type.
#  - group   Parameter passed directly to File type.
#  - ensure  Parameter passed directly to File type.
define remotefile($path, $module, $owner = root, $group = root, $mode
= 0644, $ensure = present) {
  file { $name:
    ensure  => $ensure,
    mode    => $mode,
    owner   => $owner,
    group   => $group,
    source  => "puppet:///modules/$module/$path",
  }
}

-- 
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,

I haven''t followed the entire discussion, but one small thing caught my
attention:

On 14-12-10 19:15, Rameses Mss wrote:
> In your base node (i.e., top level inheritance) set a default:
> 
> node base {
>     $sshd_type="client"
>     include sshd
> }
> 
> node myclient inherits base {
> }
> 
> node myserver inherits base {
>     $sshd_type="server"
> }
> 
> This would require sshd_config.client. Override it on a per-node basis.
> External nodes scripts make this sort of thing simpler.
AFAIK, it doesn''t work if you write it like this. Please correct me if
I
am wrong.

I have tried this, and spent the better part of a day trying to find out
why $ssh_type didn''t have "server" on
''myserver'', but "client". The parse
order matters in this case, and it only works if you write it like this:

node base {
    $sshd_type="client"
}

node myclient inherits base {
    include sshd
}

node myserver inherits base {
    $sshd_type="server"
    include sshd
}

The obvious downside being, that you have to write the include-line for
each node separately.

Best regards,
Martijn.

-- 
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.

> #Copy a file from the Puppet master.
> #
> #A good idea sourced from http://narrabilis.com/mybook/puppet/functions.pp
> #Basically it''s a little wrapper for the file type that''s
used to copy
> #a file from the puppet master. ''module'' and
''path'' are the only
> required
> #parameters.
> #
> #PARAMETERS:
> #  - path    The path to the source file to copy as relative to
> modules/<module name>/files/.
> #  - module  The name of the module to copy the file from.
> #  - mode    Parameter passed directly to File type.
> #  - owner   Parameter passed directly to File type.
> #  - group   Parameter passed directly to File type.
> #  - ensure  Parameter passed directly to File type.
> define remotefile($path, $module, $owner = root, $group = root, $mode
> = 0644, $ensure = present) {
>   file { $name:
>     ensure  => $ensure,
>     mode    => $mode,
>     owner   => $owner,
>     group   => $group,
>     source  => "puppet:///modules/$module/$path",
>   }
> }
> 
This compells me to elaborate a bit more. The problem with the above is
that you cannot have a remotefile that doesn''t care about the mode
(i.e., let puppet accept whatever mode it finds on the client machine).

If you just speicfy
remotefile { "/etc/motd": module => "all" }
the mode will be forced to 0644, which may not be what you want in edge
cases.

This is the pattern we use for this problem:

define remotefile($mode = "") {
  if $mode != "" { File { mode => $mode } }
  file { $name:
    source => "puppet:///.../$name"
  }
}

Actually, our remotefile has similar support for about *all* parameters
that "file" supports, except that owner and group indeed default to
root
(you would not want to not set those explicitly).

Also note that the "path" parameter is optional in our implementation.
Normally the URL uses $name, so if you need to override that behaviour,
you can fall back to specifying the path. This is handled by if-else
logic in the define.

Cheers,
Felix

-- 
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 Felix,

Thanks for this - I am liking it.

>> define remotefile($path, $module, $owner = root, $group = root, $mode
>> = 0644, $ensure = present) {
>>    file { $name:
>>      ensure  =>  $ensure,
>>      mode    =>  $mode,
>>      owner   =>  $owner,
>>      group   =>  $group,
>>      source  =>  "puppet:///modules/$module/$path",
>>    }
>> }
I tweaked it a bit:

define remotefile( $owner = root, $group = root, $mode = 0644, $ensure = 
present) {
    file { $name:
      ensure  => $ensure,
      mode    => $mode,
      owner   => $owner,
      group   => $group,
      source  => "puppet:///files/$name",
    }
  }

and

class syslog {
         remotefile { "/tmp/etc/syslog-ng/syslog-ng.conf": }
}

which is what I call concise (/tmp intentional).


>
> This compells me to elaborate a bit more. The problem with the above is
> that you cannot have a remotefile that doesn''t care about the mode
> (i.e., let puppet accept whatever mode it finds on the client machine).
>
> If you just speicfy
> remotefile { "/etc/motd": module =>  "all" }
> the mode will be forced to 0644, which may not be what you want in edge
> cases.
>
> This is the pattern we use for this problem:
>
> define remotefile($mode = "") {
Sorry - I don;t understand this - is this pure ruby or puppet language?

VVVV
>    if $mode != "" { File { mode =>  $mode } }
If it were ruby, I might have expected File:Stat or whatever - but I 
can''t find any docs on the puppet site describing "File".

any chance of a quick explanation please?

I sort of see what the intent is - but not how it actually works.
>    file { $name:
>      source =>  "puppet:///.../$name"
>    }
> }
>
> Actually, our remotefile has similar support for about *all* parameters
> that "file" supports, except that owner and group indeed default
to root
> (you would not want to not set those explicitly).
>
> Also note that the "path" parameter is optional in our
implementation.
> Normally the URL uses $name, so if you need to override that behaviour,
> you can fall back to specifying the path. This is handled by if-else
> logic in the define.
>
> Cheers,
> Felix
>
Many thanks,

Tim

BTW

I am looking next to try a "define something" to do nodes.pp so I can 
declare "A inherits B" and have it set up some magic that the
remotefile
function can use inherently. Back with more on this if I get something 
working or get stuck...

-- 
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-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.

On Thu, Dec 16, 2010 at 2:57 PM, Tim Watts <tw@dionic.net>
wrote:
> Hi Felix,
>
> Thanks for this - I am liking it.
>
>
>>> define remotefile($path, $module, $owner = root, $group = root,
$mode
>>> = 0644, $ensure = present) {
>>>   file { $name:
>>>     ensure  =>  $ensure,
>>>     mode    =>  $mode,
>>>     owner   =>  $owner,
>>>     group   =>  $group,
>>>     source  =>  "puppet:///modules/$module/$path",
>>>   }
>>> }
>
> I tweaked it a bit:
>
> define remotefile( $owner = root, $group = root, $mode = 0644, $ensure >
present) {
>   file { $name:
>     ensure  => $ensure,
>     mode    => $mode,
>     owner   => $owner,
>     group   => $group,
>     source  => "puppet:///files/$name",
>   }
>  }
>
> and
>
> class syslog {
>        remotefile { "/tmp/etc/syslog-ng/syslog-ng.conf": }
> }
>
> which is what I call concise (/tmp intentional).
>
>
>
>>
>> This compells me to elaborate a bit more. The problem with the above is
>> that you cannot have a remotefile that doesn''t care about the
mode
>> (i.e., let puppet accept whatever mode it finds on the client machine).
>>
>> If you just speicfy
>> remotefile { "/etc/motd": module =>  "all" }
>> the mode will be forced to 0644, which may not be what you want in edge
>> cases.
>>
>> This is the pattern we use for this problem:
>>
>> define remotefile($mode = "") {
>
> Sorry - I don;t understand this - is this pure ruby or puppet language?
Just to indicate it''s an optional parameter, since default behavior is
handled as seen below.
>>   if $mode != "" { File { mode =>  $mode } }
>
> If it were ruby, I might have expected File:Stat or whatever - but I
can''t
> find any docs on the puppet site describing "File".
Resource defaults, definitely a clever use:
http://docs.puppetlabs.com/guides/language_tutorial.html#resource-defaults
> any chance of a quick explanation please?
>
> I sort of see what the intent is - but not how it actually works.
>
>>   file { $name:
>>     source =>  "puppet:///.../$name"
>>   }
>> }
>>
>> Actually, our remotefile has similar support for about *all* parameters
>> that "file" supports, except that owner and group indeed
default to root
>> (you would not want to not set those explicitly).
>>
>> Also note that the "path" parameter is optional in our
implementation.
>> Normally the URL uses $name, so if you need to override that behaviour,
>> you can fall back to specifying the path. This is handled by if-else
>> logic in the define.
>>
>> Cheers,
>> Felix
>>
>
> Many thanks,
>
> Tim
>
> BTW
>
> I am looking next to try a "define something" to do nodes.pp so I
can
> declare "A inherits B" and have it set up some magic that the
remotefile
> function can use inherently. Back with more on this if I get something
> working or get stuck...
>
> --
> 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-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.
>
>
-- 
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.

On 17/12/10 05:37, Nan Liu wrote:
> On Thu, Dec 16, 2010 at 2:57 PM, Tim Watts<tw@dionic.net>  wrote:
<snip>
>> Sorry - I don;t understand this - is this pure ruby or puppet language?
>
> Just to indicate it''s an optional parameter, since default
behavior is
> handled as seen below.
>
>>>    if $mode != "" { File { mode =>    $mode } }
>>
>> If it were ruby, I might have expected File:Stat or whatever - but I
can''t
>> find any docs on the puppet site describing "File".
>
> Resource defaults, definitely a clever use:
> http://docs.puppetlabs.com/guides/language_tutorial.html#resource-defaults
>
<snip>

Thanks Nan.

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-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.

On Tue, 14 Dec 2010, Tim Watts wrote:
> Are there any magic variables that allow me to do something like:
> 
> source => [ "puppet:///files/resolv.conf/$mostspecificclass
>             "puppet:///files/resolv.conf/BASE"
> ]
Well, there are variables like $fqdn, $hostname, $environment,
or you can add your own.

I use a definition roughly like this:

    define my_file (ensure = "file", $user, $group, $mode,
		    $source_prefix)
    {
        file { $name:
	    ensure => $ensure,
	    user => $user,
	    group => $group,
	    mode => $mode,
	    source => [
		"${source_prefix}.$fqdn",
		"${source_prefix}.$hostname",
		"${source_prefix}.$environment",
		"${source_prefix}.BASE",
	    ],
    }

Usage is like this:

    my_file { "/etc/resolv.conf":
	user => root, group => root, mode => 0644,
	source_prefix => "puppet:///modules/my_module/resolv.conf",
    }

You can easily adapt this to use a different list of sources.  With more
trouble, you can generate the list of sources at run time depending on
some other conditions (and I actually do that).
> 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"
> ???
No, but you can define your own variable and use that, or you can wrap
it in a definition and use $name inside the definition.
> Is there a simple way to say "just create any directories you need
> to with default modes"?
No.  You need to specify each level explicitly.  See issue #86
<http://projects.puppetlabs.com/issues/86> for discussion of how such a
new feature might eventually work.

--apb (Alan Barrett)

-- 
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.