Resource defaults may help you. If you create a default file resource :
File{
owner => root,
group => root,
mode => 644,
}
The file resources in the class will assume these defaults unless their own
definition specifies otherwise. For large numbers of resources of the same
type there is also a more concise declaration style :
file {
/etc/passwd:
source => 'puppet:///someplace ';
/etc/other:
mode => 400,
source => 'puppet:///someplace/else';
}
Combining these two should be a relatively efficient way of getting there.
On Feb 19, 2012 6:12 AM, "Marc DiBlasi" <marc.dibl...@gmail.com> wrote:
> I have a couple pointers that may help you.
>
> - The default user and group is root.
> - You can set type defaults like this: File { user => "root", group =>
> "root"} and if you put this in a class, it only applies to the class.
> If you put it in site.pp, it applies globally.
> - You can define multiple resources in the same declaration separated
> by a semi-colon. i.e. file { "/etc/passwd": source => "..."; "/etc/
> group": source => "..."}
>
> Hopefully these allow you to speed things up a bit.
>
> On Feb 19, 12:43 am, David <dnblankedel...@gmail.com> wrote:
> > Hi-
> >
> > Being relatively new to the language, I find myself in a situation where
> it
> > seems like there must be an elegant way to handle this situation using
> the
> > DSL, but I'm not really certain what it could be.
> >
> > I'm trying to describe a configuration that contains 20-30 or so file { }
> > resources, all with the same attributes except for their mode and
> source. I
> > could write them all out explicitly like this:
> >
> > file { '/etc/passwd':
> > uid => root,
> > gid => root,
> > mode => 0644,
> > source => 'puppet:///modulename/etc/passwd',}
> >
> > ...
> > file { '/var/lib/someotherfile':
> > uid => root,
> > gid => root,
> > mode => 0400,
> > source => 'puppet:///modulename/var/lib/someotherfile',
> >
> > }
> >
> > but that seems unnecessarily repetitive. I originally started down the
> path
> > of writing something like this (ignore the difference in the mode
> attribute
> > for a moment):
> >
> > file { [ '/etc/passwd', ... , '/var/lib/someotherfile' ]:
> > uid => root,
> > gid => root,
> > mode => 0400,
> > source => "puppet:///modules/modulename/${title}",
> >
> > }
> >
> > but this bug:http://projects.puppetlabs.com/issues/5259
> > and this mailing list discussion:
> https://groups.google.com/d/topic/puppet-users/bj_uPi_WxC4/discussion
> >
> > helped me understand that that attempting to reference the title
> attribute
> > (the file's namevar) would never work and I would have to use a defined
> > resource instead. Taking Nan's advice in that thread, I then wrote:
> >
> > define basefiles::conf($mode){
> > $serversource = 'puppet:///modules/modulename'
> >
> > file { "${name}":
> > source =>"${serversource}/${name}",
> > owner => root,
> > group => root,
> > mode => "${mode}"
> > }
> >
> > }
> >
> > basefiles::conf { '/etc/passwd:' mode => 0644 }
> > ...
> > basefiles::conf { '/var/lib/otherfile:' mode => 0400 }
> >
> > .... and that's all groovy. The manifest looks concise and readable.
> >
> > But here's where I stare at a tree and get lost in the forrest: the
> > manifest I'm writing contains my base list of files. On some of my
> > machines, I will want to override that base and substitute a different
> copy
> > of one or two files from that list (e.g. I will want a different
> > /etc/passwd put in place).
> >
> > Further research leads me to this discussion of overriding defined
> > resources and the futility of trying:
> >
> > https://groups.google.com/d/topic/puppet-users/SDa1F817UBA/discussion
> >
> > That discussion leads me to believe it isn't possible to override defined
> > resources in the same way you might with a class. That makes me think I
> > have to either:
> > a) move the files I might want to override out to their own separate
> > class or
> > b) add some logic to the resource definition to do something magical
> for
> > certain invocations
> >
> > Both of these options seem icky to me because it means the base module
> has
> > to be coded in such a way that it has some specific knowledge about when
> > and how it might be overridden. That feels like bad coding mojo to me.
> >
> > So, is there a concise way to describe a collection of file resources,
> yet
> > be able to override parts of that collection definition in an equally
> > elegant fashion? My instinct says there must be (and it is probably
> > palm-meets-forehead simple), but I can't seem to determine what that
> might
> > be. Thanks for any help you can offer!
> >
> > -- dNb
>
> --
> 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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
