[Puppet Users] Re: Duplicate definition of resources in the same class
Hi Axel
Thanks a lot, you solution is right.
Le vendredi 10 août 2012 12:40:21 UTC+2, Rost a écrit :
>
> Hi all,
>
> I am struggling on how to do this :
>
> $path = '/tmp/lib'
>
> file { $path:
>ensure => directory,
>recurse => true,
>purge => true,
> }
>
> file { $path:
>ensure => directory,
>resurce => true,
>source => 'puppet:///modules/jboss/lib
> }
>
> When puppet compiles the manifest, I get the following error:
>
> * Duplicate declaration: File[/tmp/lib] is already declared in file
> /etc/puppet/modules/srhjboss/manifests/purge.pp at line 4; cannot redeclare
> at /etc/puppet/modules/srhjboss/manifests/purge.pp:10 on node frparsrnlinnto
> *
> *
> *
> It seems that i can't purge the directory before to copy the new one from
> the source.
>
> Suggestions ??
> Thanks
>
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/2YJqTnc2n6AJ.
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.
[Puppet Users] Re: Duplicate definition of resources in the same class
easy. every resource may only be defined _once_.
you try ... twice (file { $path : ... } and file { $path: ... }, right?)
why not simply
file { $path:
ensure => directory,
recurse => true,
purge => true,
source => 'puppet:///modules/jboss/lib
}
?
if you _need_ to do this twice for whatever reason, do something like this
(but you SHOULD NOT):
file { "$path/0":
$path => $path,
ensure => directory,
recurse => true,
purge => true,
}
file { "$path/1":
path => $path,
ensure => directory,
resurce => true,
source => 'puppet:///modules/jboss/lib
}
cause puppet identifies the resource by the title, which must differ, which
it does not. note THAT THIS IS NOT THE RIGHT WAY :) .
HTH & greetings,
Axel.
Am Freitag, 10. August 2012 12:40:21 UTC+2 schrieb Rost:
>
> Hi all,
>
> I am struggling on how to do this :
>
> $path = '/tmp/lib'
>
> file { $path:
>ensure => directory,
>recurse => true,
>purge => true,
> }
>
> file { $path:
>ensure => directory,
>resurce => true,
>source => 'puppet:///modules/jboss/lib
> }
>
> When puppet compiles the manifest, I get the following error:
>
> * Duplicate declaration: File[/tmp/lib] is already declared in file
> /etc/puppet/modules/srhjboss/manifests/purge.pp at line 4; cannot redeclare
> at /etc/puppet/modules/srhjboss/manifests/purge.pp:10 on node frparsrnlinnto
> *
> *
> *
> It seems that i can't purge the directory before to copy the new one from
> the source.
>
> Suggestions ??
> Thanks
>
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/sxb-OBGRKiAJ.
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.
[Puppet Users] Re: Duplicate definition + parameterized classes + class scope
On Mar 6, 1:00 pm, Justin Lloyd wrote:
> John,
>
> I'm running into some snags of my own and your explanations have been
> helpful. However, I'd like to ask if you can comment a bit more on the
> emphasis Puppet Labs has on parameterized classes versus include. For one,
> I'm thinking of modules available via github. Take the
> puppetlabs/mcollective module, for example. It's highly parameterized and I
> have some "wrapper classes" like this:
>
> class puppet_base ( $puppet_master = false, $mcollective_client = false
> ) {
>
> class { 'system_base': } # basics needed by all systems
>
> class { 'puppet':
> master => $puppet_master,
> require => Class['system_base'],
> }
>
> class { 'mcollective_server':
> mcollective_client => $mcollective_client,
> }
> }
>
> class mcollective_server ( $mcollective_client => false ) {
> package { 'stomp':
> ensure => present,
> provider => 'gem',
> }
>
> if $mcollective_client {
> class { 'activemq':
> require => Package['stomp'],
> before => Class['mcollective'],
> }
> }
>
> class { 'mcollective': # puppetlabs/mcollective module
> client => $mcollective_client,
> }
> }
>
> This seemed to me like an appropriate use of parameterized classes and a
> way of keeping node definitions simple and readable, like so:
>
> node 'regular-host' {
> class { 'puppet_base':
> stage => 'first'
> }
> }
>
> node 'mco-admin-host': {
> class { 'puppet_base':
> stage => 'first',
> mcollective_client => true,
> }
> }
>
> node 'puppet-master' {
> class { 'puppet_base':
> stage => 'first',
> puppet_master => true,
> }
> }
>
> I am running into some snags with ensuring curl and rubygems packages are
> installed prior to the puppet_base being evaluated (that's a long story),
> but that may be more of an issue with better use of stages.
>
> Can you comment on the above and how it is impacted by your explanations of
> includes (and smarter classes) vs. parameterization?
First, I think run stages are a better tool in principle than they are
in practice. There is nothing you can do with stages that you cannot
also do with ordinary resource / class relationships, and people
sometimes get into trouble with run stages because they end up with
more implied relationships than they needed or wanted. If people have
run stages working well for them then great, but I recommend
approaching them with caution. If ordinary relationships can do the
job without too much trouble, then I think that's a better bet. Above
all, do not use run stages without specific need.
Second, here are some of my design principles for classes:
1) 'include' classes wherever a class or definition has either a
logical or a functional dependency. That is,
1a) If one class (or definition) refers to variables or resources
declared in another, then the former should directly or indirectly
'include' the latter
1b) If the configuration described by one class (or definition)
depends for client-side correctness or proper function on separate
configuration described by a different class, then the former should
directly or indirectly 'include' the latter (even if (1a) does not
apply)
2) Declare all needed resource relationships, as specifically as
possible. In particular, prefer resource / resource relationships to
resource / class and class / class relationships.
3) Define and document modules' and classes' scope and external
interfaces.
4) Avoid use of dynamic scoping.
Regarding (1): as of 2.7.x, this principle is not usable with
parameterized classes. That is my own biggest reason for avoiding
them. Also, principle (1) implies that some classes will be
'include'd more than once, which is just fine. The overall result of
applying this principle is that you can declare (via 'include' or
'require') any class in any place in your manifest without worrying
about parse-order issues or broken configurations (for lack of needed
other classes). Not being able to rely on that result is a
significant weakness of any class that does not apply principle (1),
among them all classes that declare parameterized classes.
Regarding (2): this one wil be controversial, at least with regard to
cross-module relationships. Looking ahead to (3), however, I consider
those resources available for cross-module relationships to be part of
modules' external interfaces, to be referenced only if documented.
Declaring relationships as precisely as possible gives Puppet the
greatest freedom to find an acceptable order of resource application.
Ideally, one module would not have to worry about the details of
application order within a different module, but it is very hard to
keep modules so self-co
[Puppet Users] Re: Duplicate definition + parameterized classes + class scope
On Mar 6, 12:40 pm, "chris_sny...@sra.com" wrote: > I have to say I'm very disapointed right now with the state of Puppet. It > seems that the official documentation is pushing parameterized classes but > at the same time there are very serious drawbacks to their usage. I agree that that is a sore spot, and I can assure you that the PuppetLabs staff is aware of it. As with any small company, however, there is more work to be done than hands to do it, even if you factor in community contributions. The staff is very responsive to community comment, so perhaps you can see your way clear to cutting PuppetLabs some slack. > Additionally, they are trying to sunset the use of dynamically scoped > variables which appear (to me anyway) to be the preferred method of the > community at large (based upon my research on the web and this mailing > list) to completing tasks. (I've lost track of the number of references > I've seen that basically say, 'ignore them and go on'.) Dynamic scoping is a preferred method because at one time it was the *only* method. Even then it posed unavoidable consistency problems, however, and these sometimes bit real users. Many uses of dynamically scoped variables can trivially be converted to fully-qualified variables. You should not be writing new code that relies on dynamic scoping, and you should be wary of third-party code that relies on it. Getting rid of dynamic scoping is a good thing. > Regardless, it appears to me that no matter what I do, I will probably find > my self having to refactor large portions of my code when 2.8 is released; > either I'll be removing lots of 'includes' or changing lots of class defs > and updating usage. This does not instill confidence in me, nor does it > inspire me to dive right in. I really feel I've approached Puppet at a > very unstable point in it's existence where there is no 'right answer' and > the 'recommended patterns' will probably radically change in a year or so > and at this time I'm not sure it's worth the effort. I do not work for PL, but I am confident in assuring you that you can write modules that will work fine now and for the foreseeable future. I think it's also safe to assume that most third-party modules that are worth using will be updated for Telly soon after it is released (though I confess that my criteria for "worth using" include being supported by the author). Puppet remains an actively developed project. I think that's a good thing, but it has meant approimately one new major version every year since I have used the software. Backwards compatibility has been pretty good, with the upcoming removal of dynamic scoping being the only absolutely breaking change I can think of over the last few years. Nevertheless, Puppet development is fast-moving. > I hate to say it, but I think I need to go investigate a few other tools (a > la Chef, CFEngine, etc.) before I commit any more time to Puppet. By all means do consider your alternatives. I think Puppet is a great tool, but no one tool is best for everyone. John -- 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.
Re: [Puppet Users] Re: Duplicate definition + parameterized classes + class scope
John,
I'm running into some snags of my own and your explanations have been
helpful. However, I'd like to ask if you can comment a bit more on the
emphasis Puppet Labs has on parameterized classes versus include. For one,
I'm thinking of modules available via github. Take the
puppetlabs/mcollective module, for example. It's highly parameterized and I
have some "wrapper classes" like this:
class puppet_base ( $puppet_master = false, $mcollective_client = false
) {
class { 'system_base': } # basics needed by all systems
class { 'puppet':
master => $puppet_master,
require => Class['system_base'],
}
class { 'mcollective_server':
mcollective_client => $mcollective_client,
}
}
class mcollective_server ( $mcollective_client => false ) {
package { 'stomp':
ensure => present,
provider => 'gem',
}
if $mcollective_client {
class { 'activemq':
require => Package['stomp'],
before => Class['mcollective'],
}
}
class { 'mcollective': # puppetlabs/mcollective module
client => $mcollective_client,
}
}
This seemed to me like an appropriate use of parameterized classes and a
way of keeping node definitions simple and readable, like so:
node 'regular-host' {
class { 'puppet_base':
stage => 'first'
}
}
node 'mco-admin-host': {
class { 'puppet_base':
stage => 'first',
mcollective_client => true,
}
}
node 'puppet-master' {
class { 'puppet_base':
stage => 'first',
puppet_master => true,
}
}
I am running into some snags with ensuring curl and rubygems packages are
installed prior to the puppet_base being evaluated (that's a long story),
but that may be more of an issue with better use of stages.
Can you comment on the above and how it is impacted by your explanations of
includes (and smarter classes) vs. parameterization?
Thanks,
Justin
On Tue, Mar 6, 2012 at 8:50 AM, jcbollinger wrote:
>
>
> On Mar 6, 8:51 am, "chris_sny...@sra.com"
> wrote:
> > Crap. I'm trying to dump Bcfg2 and move to something reasonable. But so
> > far, all my initial assumptions and patterns for Puppet fail. I think in
> > terms of heirarchy and inheritence for my systems (all nodes install a
> core
> > set of packages, some have exceptions for those core set of packages,
> etc)
> > and as best as I can understand it Puppet's DSL really wants me to
> create a
> > set of flat, non-hierarchial, non-inheritable set of nodes/classes. And
> for
> > me that's completely un-managable.
> >
> > I'm reviewing the Puppet-user archives now and I'm seeing a lot of people
> > with similar problems but no good patterns for solutions.
> >
> > I want to be able do something like this (hierarchial, inheritance with
> > overloading):
> >
> > class base {
> >package { 'sshd' : ensure => present }
> >package {'ntp: ensure => present }
> >
> > }
> >
> > node a,b,c {
> >class { 'base' : }
> >
> > }
> >
> > node d {
> >class { 'base' : }
> >Package{'sshd': ensure => false }
> >
> > }
> >
> > What I'm afraid I have to do is this (flat, redefine lots of nodes and
> > duplicate data):
> >
> > class base
> >package {'ntp: ensure => present }
> ># More common packages defined
> >
> > }
> >
> > node a,b,c {
> >class { 'base' : }
> >package { 'sshd' : ensure => present }
> >
> > }
> >
> > node d {
> >class { 'base' : }
> >package { 'sshd' : ensure => false}
> >
> > }
> >
> > or worse (sometype of parameter passing in the worst, un-managable way):
> >
> > class base ( # list ever possible ensure parameter, etc ) {
> >package { 'sshd' : ensure => $ssh_ensure }
> >package {'ntp: ensure => $ntp_ensure }
> ># More common packages defined
> >
> > }
> >
> > node a,b,c {
> >class { 'base' : }}
> >
> > }
> >
> > node d {
> >class { 'base' : ssh_ensure => false}
> >
> > }
> >
> > I'm open to any and all suggestions.
>
>
> Surprisingly, you have named one of the few types of problems for
> which Puppet's class inheritance offers a reasonable solution:
>
> class ssh {
> package { 'sshd': ensure => 'present' }
> }
>
> class ssh::absent inherits ssh {
> Package[ 'sshd' ] { ensure => 'absent' }
> }
>
> node default {
> include 'sshd'
> }
>
> node d inherits default {
> include 'ssh::absent'
> # no problem that class ssh is also declared
> }
>
>
> All the same, a more forward-looking, probably better solution would
> be to rely on hierarchical data instead of hierarchical nodes and
> classes. Using the 'hiera' module recently adopted into Puppet, you
> could achieve the same effect via just
>
> class ssh {
> package { 'sshd': ensure => hiera('sshd_ensure') }
> }
>
> node default {
> include 'sshd'
> }
>
> CAVEAT: hiera configuration an
[Puppet Users] Re: Duplicate definition + parameterized classes + class scope
On Mar 6, 8:51 am, "chris_sny...@sra.com"
wrote:
> Crap. I'm trying to dump Bcfg2 and move to something reasonable. But so
> far, all my initial assumptions and patterns for Puppet fail. I think in
> terms of heirarchy and inheritence for my systems (all nodes install a core
> set of packages, some have exceptions for those core set of packages, etc)
> and as best as I can understand it Puppet's DSL really wants me to create a
> set of flat, non-hierarchial, non-inheritable set of nodes/classes. And for
> me that's completely un-managable.
>
> I'm reviewing the Puppet-user archives now and I'm seeing a lot of people
> with similar problems but no good patterns for solutions.
>
> I want to be able do something like this (hierarchial, inheritance with
> overloading):
>
> class base {
> package { 'sshd' : ensure => present }
> package {'ntp: ensure => present }
>
> }
>
> node a,b,c {
> class { 'base' : }
>
> }
>
> node d {
> class { 'base' : }
> Package{'sshd': ensure => false }
>
> }
>
> What I'm afraid I have to do is this (flat, redefine lots of nodes and
> duplicate data):
>
> class base
> package {'ntp: ensure => present }
> # More common packages defined
>
> }
>
> node a,b,c {
> class { 'base' : }
> package { 'sshd' : ensure => present }
>
> }
>
> node d {
> class { 'base' : }
> package { 'sshd' : ensure => false}
>
> }
>
> or worse (sometype of parameter passing in the worst, un-managable way):
>
> class base ( # list ever possible ensure parameter, etc ) {
> package { 'sshd' : ensure => $ssh_ensure }
> package {'ntp: ensure => $ntp_ensure }
> # More common packages defined
>
> }
>
> node a,b,c {
> class { 'base' : }}
>
> }
>
> node d {
> class { 'base' : ssh_ensure => false}
>
> }
>
> I'm open to any and all suggestions.
Surprisingly, you have named one of the few types of problems for
which Puppet's class inheritance offers a reasonable solution:
class ssh {
package { 'sshd': ensure => 'present' }
}
class ssh::absent inherits ssh {
Package[ 'sshd' ] { ensure => 'absent' }
}
node default {
include 'sshd'
}
node d inherits default {
include 'ssh::absent'
# no problem that class ssh is also declared
}
All the same, a more forward-looking, probably better solution would
be to rely on hierarchical data instead of hierarchical nodes and
classes. Using the 'hiera' module recently adopted into Puppet, you
could achieve the same effect via just
class ssh {
package { 'sshd': ensure => hiera('sshd_ensure') }
}
node default {
include 'sshd'
}
CAVEAT: hiera configuration and data not shown. It isn't hard to set
up and use, but it isn't automagical, either.
John
--
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.
[Puppet Users] Re: Duplicate definition + parameterized classes + class scope
On Mar 6, 7:53 am, "chris_sny...@sra.com" wrote: > I don't understand Puppet Language. How can you take object-oriented > constructs such as 'class' and 'inheritance' and then not allow things like > multiple instances of a class, albeit with differing parameters. That would be a travesty, but it's not what Puppet has done. Instead, Puppet has taken entirely different constructs and named them in a manner that confuses you. You know, just to keep you on your toes. > Defined > resource types don't help me as they don't have inheritance (which is > something I very much want). No, you don't. Or at least, the object-oriented kind of inheritance that you think you want is not available from Puppet, so the fact that neither defined types nor classes offer it does not distinguish between the two. Puppet's class inheritance is designed expressly for allowing the properties of resources declared in a superclass to be overridden by a subclass. Even that probably excites the OO programmer in you more than it should. In practice, overriding resource properties is never more than a convenience. Puppet offers several alternatives, some of them cleaner. Supposing that you're a good OO programmer, you will be aware of the classic question of inheritance vs. composition. In my experience, the better choice in OO programming is more often "composition" than many practitioners recognize, but in Puppet DSL, "composition" is *almost always* the better choice. John -- 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.
[Puppet Users] Re: Duplicate definition + parameterized classes + class scope
On Mar 5, 2:23 pm, "chris_sny...@sra.com"
wrote:
> I apologize if this horse has already been beaten to death, but I'm
> new here and very, very confused. I'm just starting to work with
> Puppet and I can not make heads or tails of the language: specifically
> how to use parameterized classes.
My usual advice is to avoid using parameterized classes. There is a
host of problems associated with their current design. My
understanding is that there will be substantial improvements on that
front in 'Telly', the next major release, but for now, just don't do
it.
Instead of using class parameters, either make your classes smarter,
or use an exteral data store via hiera or extlookup.
> I've spent a week reading the docs
> and testing manifests and I can't make any progress. I have a feeling
> that my confusion comes from the fact I have a programming background
> and that my understanding of certain terms (i.e. 'class' and 'scope')
> don't mean the same thing for Puppet as they do everywhere else.
You are probably right.
The usage of the term 'class' in Puppet is not derived from its usage
in many (but not all) object-oriented languages. Instead, both are
independently derived from from the more general-purpose meaning of
the word (a synonym of "kind"). I suspect Puppet's choice was
intended to evoke the concept of classification (of nodes).
Other documentation and language-design choices make it worse by
muddying the waters. In particular, I think it was a poor idea to
name Puppet's facility for declaring variant classifications
"inheritance". Puppet class inheritance is quite different from OO
class inheritance, and you just have to get over the hurdle that the
word means something different here. Fortunately, class inheritance
is rarely needed or appropriate in Puppet, so you can probably just
pretend it doesn't exist. In fact, I recommend that you do.
The word "scope" is probably not the same kind of problem for you, but
you may be running into one of these scope-related gotchas:
1) Most blocks in Puppet DSL do not establish their own scopes. If
you're used to curly-brace programming languages then this takes some
getting used to, but it is useful and appropriate for Puppet. Only (I
think) these Puppet DSL constructs establish their own scopes: node
declaration bodies, class bodies, and definition bodies.
2) Through version 2.7.x, Puppet uses dynamic scoping. This is not a
Puppet innovation, but it *has* proved to be a sore thumb. You will
make your life better if you write DSL code as if there were only two
scopes: local scope and global scope. Use a fully-qualified name to
refer to any variable not belonging to the local lexical scope.
Starting in Telly, that will be required.
3) That brings us to to the point that all declared classes,
resources, and variables have global visibility. Thus, Puppet scoping
establishes name spaces and affects name resolution, but does not
limit variable accessibility.
That last point might seem problematic until you grasp that Puppet
classes cannot be multiply declared. The Puppet docs continue their
flirtation with OO terminology by describing this as all classes being
Singletons. There is therefore never any issue of choosing the right
"instance" of a class from which to read variable values. Instances
of defined types could present a problem in this regard, except that
there is no syntax in the DSL for addressing their variables.
> (And I thought I understood the concept of 'declarative language', but
> maybe not.)
There are two main points there:
1) Once anything is defined, it cannot be redefined (even to the same
value) in the same manifest set.
2) Puppet DSL is not executable. This is a rather fine distinction,
because the DSL interacts with the execution of the Puppet manifest
compiler, and the compiled catalogs strongly influence the execution
of the Puppet agent. Nevertheless, to become a Puppet master you must
jettison the idea of classes and resources "running".
> Here's an example of what I feel should work:
>
> class bar ($x='default') {
> notify { "x=${x}": }
>
> }
>
> class foo {
> notify { 'Inside class foo': }
> class { 'bar' : x => 'inside foo', }
>
> }
>
> class baz {
> notify { 'Inside class baz': }
> class { 'bar' : x => 'inside baz', }
>
> }
>
> class { 'foo' : }
> class { 'baz' : }
>
> However, when I run this I get the following error:
>
> Duplicate definition: Class[Bar] is already defined in file
> test5.pp at line 10; cannot redefine at test5.pp:15
>
> As I understand it, each class definition has it's own scope. So why
> can't I declare the same parameterized class from two different
> classes, especially when the parameters are different?
Because all declared classes are global. Declaring a class in Puppet
is not analogous to instantiating one in, say, C++. Instead,
declaring a class simply says "the node (is a member of / has) class
". (Contrast this with declaring an insta
Re: [Puppet Users] Re: Duplicate definition
On Fri, Nov 18, 2011 at 12:40 PM, Peter Horvath
wrote:
> As you recommended i change all my file resources
> define vhost ($servername = "${hostname}.${domain}", $serveralias =
> "www.${hostname}.${domain}", $inorout = "1") {
> file{ "/etc/apache2/sites-available/${servername}":
> ensure => present,
> content =>
> template('/etc/puppet/modules/apache2/templates/vhost.erb'),
> }
> file{ "/etc/apache2/sites-enabled/${servername}":
> ensure => link,
> target =>
> "/etc/apache2/sites-available/${servername}",
> require =>
> File["/etc/apache2/sites-available/${servername}"],
> }
> file{ "/var/www/${servername}":
> ensure => directory,
> }
> file{ "/var/www/${servername}/html/":
> ensure => directory,
> require => File["/var/www/${servername}"],
> }
> file{ "/var/www/${servername}/html/index.html":
> ensure => present,
> content => "Welcome to hell of ${servername}",
> }
> service{ "${servername}":
> name => 'apaceh2',
> ensure => running,
> restart => 'service apache2 reload',
> require => [
> File["/etc/apache2/sites-enabled/${servername}"],
> File["/var/www/${servername}/html/"] ],
> subscribe => [
> File["/etc/apache2/sites-enabled/${servername}"] ],
> }
> }
> as you stated apache restart will fail my defined resource type usage how
> can i reload apache with every new vhost? Virtualization works pretty much
> the same as using unique variable defined names.
> Puppet::Parser::AST::Resource failed with error ArgumentError: Cannot alias
> Service[test.eurweb] to ["apache2"]; resource ["Service", ["apache2"]]
> already exists at /etc/puppet/modules/apache2/manifests/vhost.pp:33 on node
> eurwebtest02.eurweb
> Am i wrong?
The service should not be in the define, it should be in a separate
class, and instead of service require => File, in the define specify
file { ...: notify => Service["apache2'] }
Nan
--
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.
Re: [Puppet Users] Re: Duplicate definition
As you recommended i change all my file resources
define vhost ($servername = "${hostname}.${domain}", $serveralias =
"www.${hostname}.${domain}", $inorout = "1") {
file{ "/etc/apache2/sites-available/${servername}":
ensure => present,
content =>
template('/etc/puppet/modules/apache2/templates/vhost.erb'),
}
file{ "/etc/apache2/sites-enabled/${servername}":
ensure => link,
target =>
"/etc/apache2/sites-available/${servername}",
require =>
File["/etc/apache2/sites-available/${servername}"],
}
file{ "/var/www/${servername}":
ensure => directory,
}
file{ "/var/www/${servername}/html/":
ensure => directory,
require => File["/var/www/${servername}"],
}
file{ "/var/www/${servername}/html/index.html":
ensure => present,
content => "Welcome to hell of ${servername}",
}
service{ "${servername}":
name=> 'apaceh2',
ensure => running,
restart => 'service apache2 reload',
require => [
File["/etc/apache2/sites-enabled/${servername}"],
File["/var/www/${servername}/html/"] ],
subscribe => [
File["/etc/apache2/sites-enabled/${servername}"] ],
}
}
as you stated apache restart will fail my defined resource type usage how
can i reload apache with every new vhost? Virtualization works pretty much
the same as using unique variable defined names.
Puppet::Parser::AST::Resource failed with error ArgumentError: Cannot alias
Service[test.eurweb] to ["apache2"]; resource ["Service", ["apache2"]]
already exists at /etc/puppet/modules/apache2/manifests/vhost.pp:33 on node
eurwebtest02.eurweb
Am i wrong?
On 18 November 2011 15:15, Martijn Grendelman wrote:
> On 18-11-11 15:58, Peter Horvath wrote:
> > Seems i dont understand how get over this.
> > I have this defined resource type
> >
> > vhost.pp
> >
> > define vhost ($docroot = "/var/www", $servername =
> > "${hostname}.${domain}", $serveralias = "www.${hostname}.${domain}",
> > $inorout = "1") {
> > file{ 'conf':
>
> So, if you use this define twice, you would end up with two File resources
> named 'conf'...
>
> > path=>
> > "/etc/apache2/sites-available/${servername}",
> > ensure => present,
> > content =>
> > template('/etc/puppet/modules/apache2/templates/vhost.erb'),
> > }
> >
> > file{ 'link':
>
> So, if you use this define twice, you would end up with two File resources
> named 'link'...
>
> Etcetera. You have to make sure that your resource names are globally
> unique. Why not just do:
>
> file { "/etc/apache2/sites-enabled/${servername}": ... }
>
> That would solve most of your problems, but keep on reading...
>
>
> > path=>
> "/etc/apache2/sites-enabled/${servername}",
> > ensure => link,
> > target =>
> > "/etc/apache2/sites-available/${servername}",
> > require => File['conf'],
> > }
> >
> > file{ "${docroot}":
> > ensure => directory,
> > }
>
> If you do this, you have to make sure your $docroot is different for each
> vhost.
>
> >
> > file{ "${docroot}/${servername}":
> > ensure => directory,
> > require => File["${docroot}"],
> > }
> >
> > file{ "${docroot}/${servername}/html/":
> > ensure => directory,
> > require => File["${docroot}/${servername}"],
> > }
> >
> > file{ 'defrem':
> > path=>
> '/etc/apache2/sites-enabled/000-default',
> > ensure => absent,
> > }
>
> This resource doesn't contain any variable components at all, so this will
> always result in a duplicate definition.
>
> To fix this, you have to do what John Bollinger explained: move this
> resource outside the defined type. You can either make it virtual and
> realize() it here, or you can move it to a dedicated class and include the
> class here. Both methods will work, but I think that current best
> practices prefer the virual resource over the class inclusion.
>
> >
> > file{ 'index':
> > path=>
> "${docroot}/${servername}/html/index.html",
> > ensure => present,
> > content => "Welcome to hell of
> ${servername}",
> > }
> >
> > service{ 'apache2':
> > ensure => running,
> > restart => 'service apache2 reload',
> >
Re: [Puppet Users] Re: Duplicate definition
On 18-11-11 15:58, Peter Horvath wrote:
> Seems i dont understand how get over this.
> I have this defined resource type
>
> vhost.pp
>
> define vhost ($docroot = "/var/www", $servername =
> "${hostname}.${domain}", $serveralias = "www.${hostname}.${domain}",
> $inorout = "1") {
> file{ 'conf':
So, if you use this define twice, you would end up with two File resources
named 'conf'...
> path=>
> "/etc/apache2/sites-available/${servername}",
> ensure => present,
> content =>
> template('/etc/puppet/modules/apache2/templates/vhost.erb'),
> }
>
> file{ 'link':
So, if you use this define twice, you would end up with two File resources
named 'link'...
Etcetera. You have to make sure that your resource names are globally
unique. Why not just do:
file { "/etc/apache2/sites-enabled/${servername}": ... }
That would solve most of your problems, but keep on reading...
> path=> "/etc/apache2/sites-enabled/${servername}",
> ensure => link,
> target =>
> "/etc/apache2/sites-available/${servername}",
> require => File['conf'],
> }
>
> file{ "${docroot}":
> ensure => directory,
> }
If you do this, you have to make sure your $docroot is different for each
vhost.
>
> file{ "${docroot}/${servername}":
> ensure => directory,
> require => File["${docroot}"],
> }
>
> file{ "${docroot}/${servername}/html/":
> ensure => directory,
> require => File["${docroot}/${servername}"],
> }
>
> file{ 'defrem':
> path=> '/etc/apache2/sites-enabled/000-default',
> ensure => absent,
> }
This resource doesn't contain any variable components at all, so this will
always result in a duplicate definition.
To fix this, you have to do what John Bollinger explained: move this
resource outside the defined type. You can either make it virtual and
realize() it here, or you can move it to a dedicated class and include the
class here. Both methods will work, but I think that current best
practices prefer the virual resource over the class inclusion.
>
> file{ 'index':
> path=> "${docroot}/${servername}/html/index.html",
> ensure => present,
> content => "Welcome to hell of ${servername}",
> }
>
> service{ 'apache2':
> ensure => running,
> restart => 'service apache2 reload',
> require => [ File['conf'], File['link'],
> File["${docroot}/${servername}/html/"] ],
> subscribe => [ File['conf'], File['defrem'] ],
> }
> }
>
> and this is my node config
>
> node eurwebtest02 {
> include apache2
> include apache2::mods
> include apache2::pringo
> import "apache2/vhost.pp"
>
> vhost { 'local':
> }
>
> vhost { 'test':
> servername => "test.${domain}",
> serveralias => "www.test.${domain}",
> inorout => '0',
> }
> }
>
>
> I tried to virtualize vhost in vhost.pp with @
> and realize them in the node config, but seems i cant get a working
> solution to use vhost resource type more than 1.
>
> Can you point me to the right direction? How can i create 100 vhost with
> that defined class or something like this
Best regards,
Martijn Grendelman
>
> On 18 November 2011 11:19, Peter Horvath > wrote:
>
> As i figured out the source of my problem was that i used the defined
> resource type twice in a manifest.
> I didn't know that a defined resource type cannot be used twice in the
> same manifest as you can use multiple times a built in one.
>
> hmmm
>
>
> On 17 November 2011 22:14, jcbollinger > wrote:
>
>
>
> On Nov 17, 1:50 pm, Peter Horvath > wrote:
> > i know all of this and i did grep before i wrote this email :)
> > There is no other file[conf]
>
>
> In that case, the one declaration must be processed twice. It must
> appear inside a defined type that you instantiate more than once.
>
> If both definition instances are supposed to declare the same file,
> then move the declaration outside the definition, make it virtual, and
> have the definition 'realize' it instead of declaring it. If the
> definitions are each supposed to delare a different file then you have
> a bug in your manifest. With respect to the latter possibility, I
Re: [Puppet Users] Re: Duplicate definition
Seems i dont understand how get over this.
I have this defined resource type
vhost.pp
define vhost ($docroot = "/var/www", $servername = "${hostname}.${domain}",
$serveralias = "www.${hostname}.${domain}", $inorout = "1") {
file{ 'conf':
path=>
"/etc/apache2/sites-available/${servername}",
ensure => present,
content =>
template('/etc/puppet/modules/apache2/templates/vhost.erb'),
}
file{ 'link':
path=>
"/etc/apache2/sites-enabled/${servername}",
ensure => link,
target =>
"/etc/apache2/sites-available/${servername}",
require => File['conf'],
}
file{ "${docroot}":
ensure => directory,
}
file{ "${docroot}/${servername}":
ensure => directory,
require => File["${docroot}"],
}
file{ "${docroot}/${servername}/html/":
ensure => directory,
require => File["${docroot}/${servername}"],
}
file{ 'defrem':
path=> '/etc/apache2/sites-enabled/000-default',
ensure => absent,
}
file{ 'index':
path=>
"${docroot}/${servername}/html/index.html",
ensure => present,
content => "Welcome to hell of ${servername}",
}
service{ 'apache2':
ensure => running,
restart => 'service apache2 reload',
require => [ File['conf'], File['link'],
File["${docroot}/${servername}/html/"] ],
subscribe => [ File['conf'], File['defrem'] ],
}
}
and this is my node config
node eurwebtest02 {
include apache2
include apache2::mods
include apache2::pringo
import "apache2/vhost.pp"
vhost { 'local':
}
vhost { 'test':
servername => "test.${domain}",
serveralias => "www.test.${domain}",
inorout => '0',
}
}
I tried to virtualize vhost in vhost.pp with @
and realize them in the node config, but seems i cant get a working
solution to use vhost resource type more than 1.
Can you point me to the right direction? How can i create 100 vhost with
that defined class or something like this
On 18 November 2011 11:19, Peter Horvath wrote:
> As i figured out the source of my problem was that i used the defined
> resource type twice in a manifest.
> I didn't know that a defined resource type cannot be used twice in the
> same manifest as you can use multiple times a built in one.
>
> hmmm
>
>
> On 17 November 2011 22:14, jcbollinger wrote:
>
>>
>>
>> On Nov 17, 1:50 pm, Peter Horvath wrote:
>> > i know all of this and i did grep before i wrote this email :)
>> > There is no other file[conf]
>>
>>
>> In that case, the one declaration must be processed twice. It must
>> appear inside a defined type that you instantiate more than once.
>>
>> If both definition instances are supposed to declare the same file,
>> then move the declaration outside the definition, make it virtual, and
>> have the definition 'realize' it instead of declaring it. If the
>> definitions are each supposed to delare a different file then you have
>> a bug in your manifest. With respect to the latter possibility, I
>> observe that the resource title is not an absolute path. That could
>> be a sign that a variable in the Files' titles was unexpectedly
>> undefined, but even if not, it's unlikely to be what you want.
>>
>>
>> John
>>
>> --
>> 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.
Re: [Puppet Users] Re: Duplicate definition
As i figured out the source of my problem was that i used the defined resource type twice in a manifest. I didn't know that a defined resource type cannot be used twice in the same manifest as you can use multiple times a built in one. hmmm On 17 November 2011 22:14, jcbollinger wrote: > > > On Nov 17, 1:50 pm, Peter Horvath wrote: > > i know all of this and i did grep before i wrote this email :) > > There is no other file[conf] > > > In that case, the one declaration must be processed twice. It must > appear inside a defined type that you instantiate more than once. > > If both definition instances are supposed to declare the same file, > then move the declaration outside the definition, make it virtual, and > have the definition 'realize' it instead of declaring it. If the > definitions are each supposed to delare a different file then you have > a bug in your manifest. With respect to the latter possibility, I > observe that the resource title is not an absolute path. That could > be a sign that a variable in the Files' titles was unexpectedly > undefined, but even if not, it's unlikely to be what you want. > > > John > > -- > 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.
[Puppet Users] Re: Duplicate definition
On Nov 17, 1:50 pm, Peter Horvath wrote: > i know all of this and i did grep before i wrote this email :) > There is no other file[conf] In that case, the one declaration must be processed twice. It must appear inside a defined type that you instantiate more than once. If both definition instances are supposed to declare the same file, then move the declaration outside the definition, make it virtual, and have the definition 'realize' it instead of declaring it. If the definitions are each supposed to delare a different file then you have a bug in your manifest. With respect to the latter possibility, I observe that the resource title is not an absolute path. That could be a sign that a variable in the Files' titles was unexpectedly undefined, but even if not, it's unlikely to be what you want. John -- 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.
[Puppet Users] Re: Duplicate definition: Service[cron] is already defined
On Apr 18, 4:50 am, Wilmer van der Gaast wrote:
> Hello,
>
> To avoid silly micro-management of my "fleet" I've started using
> Puppet. Now I'm probably missing some "best practices".
>
> I'm currently getting a "Duplicate definition: Service[cron] is
> already defined" on my configs. Indeed there are two places that
> define the service. One's the duplicity module:
>
> # Ensure that cron is enabled and running.
> @service { cron:
> ensure => running,
> enable => true,
> }
>
> The other one is in my timezone update class:
>
> service { ["cron", "rsyslog", "atd"]:
> subscribe => [File["/etc/localtime"], File["/
> etc/timezone"]];
> }
>
> These are two *completely* independent things.
No, they're not. Both declare the resource Service['cron']. They
don't even declare the same properties for it, though it wouldn't
matter if they did. Perhaps you expected the properties to be
cumulative, but that's not the way Puppet works: you must set all the
properties of a resource at the point where you declare it (but see
below). For example:
# No effect on the client unless this resource is realized somewhere
@service { "cron":
ensure => running,
enable => true,
subscribe => [ File["/etc/localtime"], File["/etc/timezone"] ];
}
You can have multiple declarations of a resource as long as only one
is processed for each node. You can achieve that using conditional
statements in your manifests, or by putting the different declarations
into different classes, and making sure no node includes more than one
of those classes.
In some cases it may also be appropriate to override the properties of
resources declared in one class by creating a subclass. That's sort of
an exception to setting all the resource properties at the point of
declaration, but overriding does not involve separate resource
declarations.
> I suppose I can just
> remove the clause from duplicity since I don't see why I would not be
> running cron everywhere, but I still wonder how one is supposed to
> deal with a situation like this, since it will probably happen to me
> again.
I don't see why de-duplication need involve running cron everywhere.
1) You've already declared Service['cron'] virtually, so it will only
be managed on those nodes for which you realize it.
2) You could use one of the techniques described above to control
which of several Service['cron'] declarations is used on different
nodes (some of which might express ensure => stopped)
3) You could also use a selector to control a single declaration, like
so:
service { "cron":
... # other properties
ensure => $cron_should_not_run ? {
"yes" => stopped,
default => running
}
}
4) Or you could use extlookup():
service { "cron":
... # other properties
# depends on an external data file:
ensure => extlookup("cron_ensure")
}
5) Or there are other, more involved alternatives
Regards,
John
--
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.
