Did anyone ever get this working. I am also looking to modify the core
parameters on my system. Any help would be appreciated.
On Saturday, May 30, 2009 4:46:07 AM UTC-4, Greg wrote:
>
> 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 view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/EhEyWFHeVSUJ.
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.
