Having trouble trying to model some behaviour in puppet and would appreciate some suggestions on how I could achieve it.
I'm trying to write out multiple similar items to a file, think shares in smb.conf to take one example I'll use throughout (although there's other places I need to do this aswell).
An extra caveat is that I'd like to be able to define these shares in a few places. So say, some shares under a node definition and some shares in an included class (e.g. all servers have one share, but only some servers have another share).
Then in my ruby template, I'd guess I'd loop over some list, writing out the config as I go.
So the problems I'm having are: The naive solutions results in me trying to manage the same file multiple times, which obviously isn't possible Trying to bring them all together by, in my resource definition, importing a class and assigning to a list in that class but fails because 1) I dont think the +> syntax works for lists and 2) you cant assign to variables in another class.
I've got a nasty feeling I'm missing a really obvious nice way to do this, but I just cant get my head round it, hence any advice would be appreciated. It's really easy for services like apache that allow you to do "include /etc/.../conf.d" as you can just stick in seperate files but when you cant I get stuck :)
> Having trouble trying to model some behaviour in puppet and would
> appreciate some suggestions on how I could achieve it.
> I'm trying to write out multiple similar items to a file, think shares in
> smb.conf to take one example I'll use throughout (although there's other
> places I need to do this aswell).
> An extra caveat is that I'd like to be able to define these shares in a
> few places. So say, some shares under a node definition and some shares in
> an included class (e.g. all servers have one share, but only some servers
> have another share).
> Then in my ruby template, I'd guess I'd loop over some list, writing out
> the config as I go.
> So the problems I'm having are:
> The naive solutions results in me trying to manage the same file multiple
> times, which obviously isn't possible
> Trying to bring them all together by, in my resource definition, importing
> a class and assigning to a list in that class but fails because 1) I dont
> think the +> syntax works for lists and 2) you cant assign to variables in
> another class.
> I've got a nasty feeling I'm missing a really obvious nice way to do this,
> but I just cant get my head round it, hence any advice would be
> appreciated. It's really easy for services like apache that allow you to
> do "include /etc/.../conf.d" as you can just stick in seperate files but
> when you cant I get stuck :)
> Having trouble trying to model some behaviour in puppet and would > appreciate some suggestions on how I could achieve it.
> I'm trying to write out multiple similar items to a file, think > shares in > smb.conf to take one example I'll use throughout (although there's > other > places I need to do this aswell).
> An extra caveat is that I'd like to be able to define these shares > in a > few places. So say, some shares under a node definition and some > shares in > an included class (e.g. all servers have one share, but only some > servers > have another share).
> Then in my ruby template, I'd guess I'd loop over some list, writing > out > the config as I go.
This is a relatively common problem, and people who don't write native resource types use a kind of file snippet system -- make a definition that writes the appropriate samba config for each share to something like /etc/samba.d, then have an exec that combines these into the correct configuration file, using 'subscribe' to trigger the exec.
Make sense?
Isn't there one of these published somewhere?
-- The most likely way for the world to be destroyed, most experts agree, is by accident. That's where we come in; we're computer professionals. We cause accidents. --Nathaniel Borenstein --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
> This is a relatively common problem, and people who don't write native > resource types use a kind of file snippet system -- make a definition > that writes the appropriate samba config for each share to something > like /etc/samba.d, then have an exec that combines these into the > correct configuration file, using 'subscribe' to trigger the exec.
> Make sense?
> Isn't there one of these published somewhere?
DavidS' common module [1] has something like that integrated.
> On Jun 27, 2008, at 10:32 AM, Ross.McKerc...@sophos.com wrote:
> > Having trouble trying to model some behaviour in puppet and would > > appreciate some suggestions on how I could achieve it.
> > I'm trying to write out multiple similar items to a file, think > > shares in > > smb.conf to take one example I'll use throughout (although there's > > other > > places I need to do this aswell).
> > <snip>
> > Then in my ruby template, I'd guess I'd loop over some list, writing > > out > > the config as I go.
> This is a relatively common problem, and people who don't write native > resource types use a kind of file snippet system -- make a definition > that writes the appropriate samba config for each share to something > like /etc/samba.d, then have an exec that combines these into the > correct configuration file, using 'subscribe' to trigger the exec.
Thanks for all the help.
I've checked out David's common module: it can definitely achieve some (but not all) of what I'm looking for.
The "natural" way that I first tried to model this kind of behaviour is as follows (please forgive my slightly wacky puppet-pseudocode, hopefully you'll get the idea):
class a { $settings = [a,b] file {"/etc/file.conf": content => template('erb file with content: settings.join(",")') #Contents of file.conf will be out a,b
}
class b inherits a { $settings +> [c,d] #Contents of file.conf will be out a,b,c,d
}
Of course this doesn't work - lists are immutable and it appears you actually have to explicitly duplicate the file definition in all subclasses to use the assoicated overridden variable.
Is this, or something similar (the above is obv. limited to each "setting" only having one variable), a sensible feature request? It seems to be quite a natural thing to be able to do with resorting to any exec-based black magic.
