Martin,
I'm also not a fan of trying to retrofit stuff on top of undocumented
features. My problem is that Puppet runs already take 1 minute every
half hour, I am trying to reduce it if possible - otherwise I am
going
to start getting complaints by users about me taking their precious
CPU time...
I haven't implemented a type of my own before, has anyone got
a guide on what needs to be implemented, etc.? Also how are types
delivered to the puppet clients? Is there something similar to
factsync?
Greg
On May 29, 6:47 pm, martin <martin.engl...@sun.com> wrote:
> Greg,
>
> knowing better than to mess with (readable) but unpublished
> interfaces. /etc/coreadm.conf clearly states that you shouldn't edit
> file directly, which means that they can introduce a new field in a
> patch, which may get you into a world of hurt :)
>
> I use option number 2) - the overhead really isn't that much, but if
> you want to get it down as much as possible:
> create a new type which runs "coreadm" without any options (which
> outputs the contents of /etc/coreadm.conf) and parse that, and adjust
> the incorrect values.
>
> cheers,
> /Martin
>
> On May 28, 2:10 am, Greg <greg.b...@gmail.com> wrote:
>
> > Hi all,
>
> > I have an interesting one - Solaris uses a lot of commands to
> > configure specific items. A simple
> > example is coreadm. In this example:
>
> > # coreadm -p "/var/core/core_%n_%f_%u_%g_%t_%p"
>
> > will set the directory and filename to dump core files (with some
> > expansion).
>
> > The question is - how to get this to run only if the config has
> > changed. I have come up with 2 options, neither of which I'm that
> > happy with, so I'm open to ideas...
>
> > Option 1: Manage the resulting config file.
>
> > file { "/etc/coreadm.conf":
> > owner => root,
> > group => other,
> > mode => 644,
> > source => "puppet:///cores/coreadm.conf"}
>
> > exec { "/usr/bin/coreadm -u":
> > refreshonly => true,
> > subscribe => File["/etc/coreadm.conf"]
>
> > }
>
> > Option 2: Check for individual changes using coreadm:
>
> > exec { "/usr/bin/coreadm -p /var/core/core_%n_%f_%u_%g_%t_%p":
> > onlyif => 'test `coreadm | grep "global core file pattern:" | awk
> > '{print $5}'` -ne /var/core/core_%n_%f_%u_%g_%t_%p'
>
> > }
>
> > The problem with option 1 is that Sun don't recommend messing with the
> > config file directly, and that it
> > relies on a way to force the kernel to re-read the config from the
> > file - this may not be possible with other similar commands... It is
> > the neater option that I have come up with, however...
>
> > The problem with option 2 is that it means that I have to run one exec
> > block for every option I want to control...
>
> > Has anyone else attempted to manage these kinds of resources? If so,
> > what did you do?
>
> > thanks,
>
> > Greg
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
