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

Search Discussions

  • John Warburton at Jan 8, 2013 at 11:16 pm
    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@.... 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 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 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.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppuppet-users @
categoriespuppet
postedJan 8, '13 at 10:08p
activeJan 8, '13 at 11:16p
posts2
users2
websitepuppetlabs.com

2 users in discussion

Skhan: 1 post John Warburton: 1 post

People

Translate

site design / logo © 2022 Grokbase