Using an Exec inside a define

689 views
Skip to first unread message

Ben Beuchler

unread,
Dec 29, 2008, 2:10:47 AM12/29/08
to puppet...@googlegroups.com
I'm working on a definition for activating/deactivating Apache modules
on an Ubuntu system. Inside my Apache class I have this definition:

define module($ensure) {
case $ensure {
enabled: { exec { "a2enmod":
command => "/usr/sbin/a2enmod $name",
logoutput => on_failure,
creates => "/etc/apache2/mods-enabled/$name.load",
notify => Service["apache2"],
}
}
disabled: { exec { "a2dismod":
command => "/usr/sbin/a2dismod $name",
logoutput => on_failure,
unless => "test ! -e
/etc/apache2/mods-enabled/$name.load",
notify => Service["apache2"],
}
}
default: { alert("Invalid option for apache::module.") }
}
}

I call it like so:

apache::module { "proxy_http": ensure => enabled }

This seems to work just fine as long as I only call it once. If I
call it multiple times, each with a different module name, I get this
error:

err: Could not retrieve catalog: Puppet::Parser::AST::Resource failed
with error ArgumentError: Duplicate definition: Exec[a2enmod] is
already defined in file /etc/puppet/manifests/classes/apache.pp at
line 12; cannot redefine at /etc/puppet/manifests/classes/apache.pp:12

I was under the impression that Exec expressly allows duplicate
definitions. What am I misunderstanding? Is there a better way to
structure this definition?

Thanks...

-Ben

RijilV

unread,
Dec 29, 2008, 2:32:35 AM12/29/08
to puppet...@googlegroups.com
2008/12/28 Ben Beuchler <ins...@gmail.com>

I was under the impression that Exec expressly allows duplicate
definitions.  What am I misunderstanding?  Is there a better way to
structure this definition?


 Ah, nope.  No resource title can be duplicated, exec isn't an exception.  Is there somewhere you read that or saw it in an example?

Anyhow, doesn't really matter.  Try something like:

define module($ensure) {
    ...
    exec { "a2enmod-$name":
        command => '/bin/whatever',
        ....
     }
    ...
}

.r'


p.s.  that alert at the end will have the same proble, tack $name in there too.



Ben Beuchler

unread,
Dec 29, 2008, 10:45:07 AM12/29/08
to puppet...@googlegroups.com
> Ah, nope. No resource title can be duplicated, exec isn't an exception.
> Is there somewhere you read that or saw it in an example?

Perhaps I misunderstood what I read here:

http://reductivelabs.com/trac/puppet/wiki/TypeReference#exec

Not only does it seem to be saying that an exec is allowed to have a
duplicate title/name, but the example seems to be demonstrating
exactly that. Am I misreading it?

> exec { "a2enmod-$name":
> command => '/bin/whatever',

I'll give that a shot. Thanks!

-Ben

Robin Lee Powell

unread,
Dec 29, 2008, 2:02:55 PM12/29/08
to puppet...@googlegroups.com
On Mon, Dec 29, 2008 at 09:45:07AM -0600, Ben Beuchler wrote:
>
> > Ah, nope. No resource title can be duplicated, exec isn't an
> > exception. Is there somewhere you read that or saw it in an
> > example?
>
> Perhaps I misunderstood what I read here:
>
> http://reductivelabs.com/trac/puppet/wiki/TypeReference#exec
>
> Not only does it seem to be saying that an exec is allowed to have
> a duplicate title/name, but the example seems to be demonstrating
> exactly that. Am I misreading it?

I agree with you, definately. I suspect, but do not know, that the
cwds need to be different in that case.

-Robin

--
They say: "The first AIs will be built by the military as weapons."
And I'm thinking: "Does it even occur to you to try for something
other than the default outcome?" -- http://shorl.com/tydruhedufogre
http://www.digitalkingdom.org/~rlpowell/ *** http://www.lojban.org/

Paul Lathrop

unread,
Dec 29, 2008, 2:23:01 PM12/29/08
to puppet...@googlegroups.com
Hmm,

I suspect that documentation is wrong. I've never successfully had
multiple Exec resources with the same name. I say file a bug, at the
worst someone will verify/clarify the documentation.

I tend to use "module_name::define_name::$name" as my naming
convention for this sort of thing. That usually guarantees uniqueness.

--Paul
Reply all
Reply to author
Forward
0 new messages