Puppet users - May 2009 - Managing core files using coreadm (Solaris + Puppet)

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+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

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+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

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+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

Whilst the format is undocumented, if you stick to what coreadm -p
produces, you should be fine. It''s just not really worth the hassle.
Here''s
what we do:

    # The format of /etc/coreadm.conf is *undocumented* and subject to
change
    # without notice, this *should* use coreadm(1) to check and edit, but
    # in the absence of a provider or custom type we just retain the file.
    # NOTE: "coreadm -u" rewrites the file, replacing any comments
with
    # a standard header, so cannot keep version info there or puppet will
    # keep trying to overwrite the updated file with it''s source copy.
    # The "source" below must be kept identical to "coreadm
-u" output;
    # if the options change, use coreadm to update them on a system, then
    # take an exact copy of it''s output file to replace the file below.
    file { ''/etc/coreadm.conf'':
        ensure => present,
        owner  => root,
        group  => other,
        mode   => 0644,
        source =>
''puppet:///modules/security/etc/coreadm.conf'',
        notify => Exec[''coreadm''],
    }
    exec { ''coreadm'':
        command     => ''coreadm -u'',
        refreshonly => true,
        path        => ''/bin:/usr/bin'',
    }



On 9 January 2013 08:50, skhan@.... <skhan@pccwglobal.com> wrote:
> 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+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
>


-- 
John Warburton
Ph: 0417 299 600
Email: jwarburton@gmail.com

-- 
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.