http://groups.google.com/group/puppet-users/browse_thread/thread/b6378c7df1e9356f/3d224f60ff762ec8?#3d224f60ff762ec8


cheers,
Ohad

On Wed, Dec 9, 2009 at 7:46 PM, Rus Hughes <russell.hug...@gmail.com> wrote:

> Ok, I've managed to 'fix' this issue by, on each puppet run, forcing
> /etc/munin/puppet to purge and empty itself before collecting
>
>    file { "/etc/munin/puppet":
>        ensure      => directory,
>        owner       => munin,
>        group       => munin,
>        mode        => 755,
>        require => Package["munin"],
>        purge       => true,
>        recurse     => true,
>        force       => true,
>        source      => "puppet:///munin/empty"
>    }
>
> and making the exported file require it
>
>        @@file { "/etc/munin/puppet/${fqdn}":
>                ensure => present,
>                content => template("munin/node.erb"),
>                tag => 'munin',
>                 require => File["/etc/munin/puppet"],
>        }
>
> I think this is horrible though, as each time puppet runs, even if
> nothing changes, it will purge, collect and concatenate, very messy ..
>
> There must be a nicer way?
>
> On Wed, Dec 9, 2009 at 10:28 AM, Rus Hughes <russell.hug...@gmail.com>
> wrote:
> > We are using the puppet built in mechanisms with Nagios and that
> > concatenated_file.pp for Munin, that puppetstoredconfigclean.rb script
> > works like a charm, but I'm still having difficulty purging the now
> > unmanaged elements. Puppet isn't removing any of the unmanaged files
> > from the filesystem so concatenated_file.pp is still including them.
> >
> >        @@file { "/etc/munin/puppet/${fqdn}":
> >                ensure => present,
> >                content => template("munin/node.erb"),
> >                tag => 'munin',
> >        }
> >
> >        File <<| tag == 'munin' |>>
> >
> >        concatenated_file { "/etc/munin/munin.conf":
> >                dir => "/etc/munin/puppet",
> >                header => "/etc/munin/munin.conf.header",
> >                require => File["/etc/munin/puppet"],
> >        }
> >
> > Should I be explicitly purging directories that contain the managed
> > files, e.g. /etc/munin/puppet? And if so how?
> >
> > Thanks
> >
> > On Wed, Dec 9, 2009 at 7:31 AM, David Schmitt <da...@dasz.at> wrote:
> >> On 08.12.2009 17:53, Rus Hughes wrote:
> >>> Hi,
> >>>
> >>> We're using thin stored configs heavily to manage things like Munin
> >>> and Nagios and we're currently wondering what to do when nodes go
> >>> away, or change considerably.
> >>>
> >>> If we get rid of a server then all it's stored config is still present
> >>> in the database, as well as it's nagios and munin configurations.
> >>>
> >>> We created a script that iterates through the database deleting
> >>> associated lines from
> >>> hosts/fact_values/resources/resource_tags/param_values tables cleaning
> >>> out information for old hosts, but then doing a puppet run on say our
> >>> Munin or Nagios doesn't seem to fix things, Puppet doesn't seem to
> >>> notice that the extra Nagios or virtual configurations we're using for
> >>> Munin have vanished, so isn't rebuilding the Nagios/Munin files.
> >>>
> >>> Does anyone have any idea how we can solve this problem? We're using
> >>> Puppet 0.25.1.
> >>
> >> There is a puppetstoredconfigclean.rb in the ext/ directory of the
> >> puppet distribution. You can use that to cleanly remove nodes from
> >> stored configs.
> >>
> >> On the matter of managing munin and nagios, you need to use a mechanism
> >> like concatenated_file[1], which purges unmanaged parts. After deleting
> >> a node from the stored configs db, the resources formerly collected
> >> become unmanaged and will be removed by purging.
> >>
> >>
> >>
> >> Regards, DavidS
> >>
> >> [1]
> http://github.com/puppet-modules/puppet-common/blob/0caa32db1aaad6dabc9542c5e0aa20e76ea94f48/manifests/defines/concatenated_file.pp
> >>
> >> --
> >>
> >> You received this message because you are subscribed to the Google
> Groups "Puppet Users" group.
> >> To post to this group, send email to puppet-us...@googlegroups.com.
> >> To unsubscribe from this group, send email to
> puppet-users+unsubscr...@googlegroups.com<puppet-users%2bunsubscr...@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-us...@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-users+unsubscr...@googlegroups.com<puppet-users%2bunsubscr...@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-us...@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.


Reply via email to