FAQ
Maybe one of you can help with this. I have a class that's got a
file{} type directive in it. It populates /etc/security/limits.conf
with specific settings. I have a small handful of hosts where we want
to manage /etc/security/limits.conf manually. Is there a simple way
to tell puppet to exclude this file type just on those hosts, without
copying the entire class?

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

Search Discussions

  • Tim Mooney at Aug 17, 2012 at 10:35 pm

    In regard to: [Puppet Users] Override a file{} directive - is it possible?,...:

    Maybe one of you can help with this. I have a class that's got a
    file{} type directive in it. It populates /etc/security/limits.conf
    with specific settings. I have a small handful of hosts where we want
    to manage /etc/security/limits.conf manually. Is there a simple way
    to tell puppet to exclude this file type just on those hosts, without
    copying the entire class?
    Is there a way that puppet can detect these particular hosts? For
    example, is it true for all hosts that are in a particular datacenter,
    or for which some class (or even user) is present?

    I ask, because the way you would typically do what you're asking is to
    either use facts about systems to trigger the "don't manage
    /etc/security/limits.conf" logic, or to have your manifests key on
    external configuration that you keep in something like extlookup(),
    hiera(), or your ENC (external node classifier).

    So, there are several ways to accomplish what you're looking for, but
    which one is best depends on your needs and how you actually detect that
    hostB shouldn't have limits.conf managed.

    You don't say what version of puppet you're using, whether you're using
    an ENC, or whether you're already using either extlookup() or hiera(),
    so it's really difficult to suggest something that integrates well with
    your current environment.

    I can give you two examples from my environment, though.

    We're using puppet 2.7.14 without an ENC (we have dashboard but don't
    use it for ENC purposes), but we are using hiera. The absolute easiest
    way (but likely *not* best) way to do this would be to do this with
    a hiera setting like:

    common.yaml:
    ---
    manage_limits_conf: 'yes'


    host1.example.com.yaml:
    ---
    manage_limits_conf: 'no'


    and then in your manifest that sets up limits.conf, just wrap with the
    appropriate logic to check hiera() whether it should be managed or not.


    A second example would be if you have a fact (probably a custom fact)
    that could be used to determine the exact set of systems for which
    limits.conf should not be managed. For example, we have a custom fact
    (location) that returns the name of the datacenter a system is located in.
    If you wanted all the systems in location=datacenter1 to not manage
    limits.conf, then you could wrap your file{} resource in a conditional
    that tests the fact.

    Certainly vague answers to your question, but hopefully this gives you
    something to go on. If it's not enough to go on, provide more information
    about your environment. That will hopefully make it easier for someone to
    suggest a method that works well for your environment.

    Tim
    --
    Tim Mooney tim.mooney@ndsu.edu
    Enterprise Computing & Infrastructure 701-231-1076 (Voice)
    Room 242-J6, IACC Building 701-231-8541 (Fax)
    North Dakota State University, Fargo, ND 58105-5164

    --
    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.
  • Sean Carolan at Aug 17, 2012 at 10:41 pm

    You don't say what version of puppet you're using, whether you're using
    an ENC, or whether you're already using either extlookup() or hiera(),
    so it's really difficult to suggest something that integrates well with
    your current environment.
    Sorry I didn't provide more detail. We're using puppet 2.6.13. We
    have a single *.pp config file for each and every host, so specifying
    additional classes is not hard to do on a host-per-host basis. Here's
    the limits.conf config from the class that has been applied to these
    hosts:

    file { "/etc/security/limits.conf":
    owner => "root",
    group => "root",
    mode => "644",
    content => "#<domain>\t\t<type>\t\t<item>\t\t<value>\n*\t\t-\t\tnofile\t\t65000\n*\t\t-\t\tnproc\t\t140000\n*\t\thard\t\tcore\t\tunlimited\ncdc-dev\t\t-\t\tpriority\t\t15\nhtc\t\t-\t\tnofile\t\t250000\n";
    }

    Basically I just want this "file" type to not be active on three
    hosts. I don't need to be able to detect the hosts, as I can specify
    the config manually in each of their config files.

    --
    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.
  • Calvin Walton at Aug 19, 2012 at 4:45 am

    On Fri, 2012-08-17 at 15:41 -0700, Sean Carolan wrote:
    You don't say what version of puppet you're using, whether you're using
    an ENC, or whether you're already using either extlookup() or hiera(),
    so it's really difficult to suggest something that integrates well with
    your current environment.
    Sorry I didn't provide more detail. We're using puppet 2.6.13. We
    have a single *.pp config file for each and every host, so specifying
    additional classes is not hard to do on a host-per-host basis. Here's
    the limits.conf config from the class that has been applied to these
    hosts: <snip>
    Basically I just want this "file" type to not be active on three
    hosts. I don't need to be able to detect the hosts, as I can specify
    the config manually in each of their config files.
    It's not really the cleanest-looking thing, but the easiest option for
    your particular case is to wrap the file resource in an if statement
    like this:
    if (! $::security_limits_disabled) {
    file { '/etc/security/limits.conf':
    ...
    }
    }
    then, on each of the nodes where you don't want to use the limits.conf
    file, you can just set the variable to true:
    node special_box {
    include some_classes
    $security_limits_disabled = true
    }
    --
    Calvin Walton <calvin.walton@kepstin.ca>

    --
    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.
  • Sean Carolan at Aug 20, 2012 at 8:19 pm

    It's not really the cleanest-looking thing, but the easiest option for
    your particular case is to wrap the file resource in an if statement
    like this:
    if (! $::security_limits_disabled) {
    file { '/etc/security/limits.conf':
    ...
    }
    }
    Thanks, this is just what I was looking for.

    --
    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.
  • Sean Carolan at Aug 20, 2012 at 9:08 pm

    It's not really the cleanest-looking thing, but the easiest option for
    your particular case is to wrap the file resource in an if statement
    like this:
    if (! $::security_limits_disabled) {
    file { '/etc/security/limits.conf':
    ...
    }
    }
    Thanks, this is just what I was looking for.
    One last question, is it possible to do this:

    class profile::server::java {
    $security_limits_disabled = true
    }

    and then simply include that class on my target node? I tried to do
    this but the file is still getting overwritten...

    --
    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 Alfke at Aug 21, 2012 at 6:34 am

    On 20.08.2012, at 23:08, Sean Carolan wrote:

    It's not really the cleanest-looking thing, but the easiest option for
    your particular case is to wrap the file resource in an if statement
    like this:
    if (! $::security_limits_disabled) {
    file { '/etc/security/limits.conf':
    ...
    }
    }
    Thanks, this is just what I was looking for.
    One last question, is it possible to do this:

    class profile::server::java {
    $security_limits_disabled = true
    }

    and then simply include that class on my target node? I tried to do
    this but the file is still getting overwritten...
    In this case you need to add the scope to the variable used in the if clause:
    if ( ! $profile::server::java::security_limits_disabled) { ........ <- add class name as scope

    hth,

    Martin

    --
    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.
  • Sean Carolan at Aug 21, 2012 at 10:22 pm

    It's not really the cleanest-looking thing, but the easiest option for
    your particular case is to wrap the file resource in an if statement
    like this:
    if (! $::security_limits_disabled) {
    file { '/etc/security/limits.conf':
    ...
    }
    }
    Super, thanks Martin!

    --
    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.
  • Keiran Sweet at Aug 23, 2012 at 10:14 am
    Another option worth mentioning, and this may not be suitable for your
    environment, is to allow host overrides of configuration files within your
    module using file precedence like the below.

    file { '/etc/security/limits.conf' :
    ensure => file,
    mode => 755,
    owner => root,
    group => root,
    source => [
    "puppet:///modules/modulename/limits.conf.$::hostname" ,
    "puppet:///modules/modulename/limits.conf",
    ],
    }

    By default, all nodes get the standard limits.conf file that is served out
    from your module, however, if you create a limits.conf.oracleserver1 file
    that contains the required settings, the server oracleserver1 will get
    the overridden limits.conf file when it checks in.

    This has been extremely useful in my environment when importing the odd
    'unique snowflake' type server quickly without having to make any
    code/logic changes or introduce large numbers of ENC values to disable
    certain functionality or alter the flow of your puppet code.

    Cheers,

    K








    On Monday, August 20, 2012 9:19:45 PM UTC+1, Sean wrote:

    It's not really the cleanest-looking thing, but the easiest option for
    your particular case is to wrap the file resource in an if statement
    like this:
    if (! $::security_limits_disabled) {
    file { '/etc/security/limits.conf':
    ...
    }
    }
    Thanks, this is just what I was looking for.
    --
    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/-/M1aiScBQy4UJ.
    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.
  • Sean Carolan at Aug 23, 2012 at 10:32 pm

    This has been extremely useful in my environment when importing the odd
    'unique snowflake' type server quickly without having to make any code/logic
    changes or introduce large numbers of ENC values to disable certain
    functionality or alter the flow of your puppet code.
    Yes. Puppet doesn't seem to deal with snowflakes well, thanks for sharing this.

    --
    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
postedAug 17, '12 at 6:46p
activeAug 23, '12 at 10:32p
posts10
users5
websitepuppetlabs.com

People

Translate

site design / logo © 2022 Grokbase