Puppet users - Apr 2011 - Duplicate definition: Service[cron] is already defined

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. 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''ve found the Service["cron", "rsyslog",
"atd"] { ...} syntax but it
didn''t work either, saying it can only be used to override definitions
of a parent class (IIRC).

If anyone knows I''d be delighted to know.


Cheers,

Wilmer van der Gaast.

-- 
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 04/18/2011 11: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. 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''ve found the Service["cron", "rsyslog",
"atd"] { ...} syntax but it
> didn''t work either, saying it can only be used to override
definitions
> of a parent class (IIRC).
Hi,

that''s one way to do it. Add a subclass to the class that defines the
service in question and override the service definition such as to
subscribe the appropriate resources. Then include that subclass at will.
However...
> If anyone knows I''d be delighted to know.
This case is much simpler. Add a ''notify =>
Service["cron"]'' to the file
resources instead of using subscribe.

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.

On Apr 18, 4:50 am, Wilmer van der Gaast <lin...@gmail.com>
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.