FAQ
Hi all,

I know that there are likely a few ways to solve the following. I just
don't know what the best way may be :)

We're trying to work out how do something similar to the following scenario.

How do we apply a policy to uninstall CUPS from all servers, except for a
configurable group of "some".

To put it another way, how can we have an policy that will configure CUPS
on a known list of servers (hiera array perhaps?), and uninstall from all
other $kernel=Linux machines?

Best to get the install list right first then feed via ENC, or?

Regs,

Stephen

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

  • Pete Brown at May 17, 2013 at 12:41 am

    On 17 May 2013 10:33, Stephen Wallace wrote:

    Hi all,

    I know that there are likely a few ways to solve the following. I just
    don't know what the best way may be :)

    We're trying to work out how do something similar to the following
    scenario.

    How do we apply a policy to uninstall CUPS from all servers, except for a
    configurable group of "some".

    To put it another way, how can we have an policy that will configure CUPS
    on a known list of servers (hiera array perhaps?), and uninstall from all
    other $kernel=Linux machines?
    Since you haven't actually mentioned how you are doing it I am going to
    assume you have your cups package resource in a class or module somewhere
    that gets included on all node.
    Am I right?

    If that is the case and you are running puppet 2.7+ or 3.x I would suggest
    using a hiera variable and then use that variable to decide if it gets
    uninstalled or setup.
    Since the most likely case is to make sure it is uninstalled I would set
    that as a default and override on the nodes you want it setup.

    Best to get the install list right first then feed via ENC, or?

    Regs,

    Stephen

    --
    You received this message because you are subscribed to the Google Groups
    "Puppet Users" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to puppet-users+unsubscribe@googlegroups.com.
    To post to this group, send email to puppet-users@googlegroups.com.
    Visit this group at http://groups.google.com/group/puppet-users?hl=en.
    For more options, visit https://groups.google.com/groups/opt_out.

    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com.
    To post to this group, send email to puppet-users@googlegroups.com.
    Visit this group at http://groups.google.com/group/puppet-users?hl=en.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Joe at May 17, 2013 at 3:06 am
    The easiest thing to do would to make a subclass called cups::enabled or
    similar and use an override:

    class cups::enabled inherits cups{ # The inherits is important

       Package['cups']{
         ensure => 'present,
       }

       Add service and config file resources here

    }

    The problem with trying to use hiera is it just gets you the package ensure
    parameter. With the override, you can add in the service and config file
    resources as well.
    On Thursday, May 16, 2013 6:33:25 PM UTC-6, Stephen Wallace wrote:

    Hi all,

    I know that there are likely a few ways to solve the following. I just
    don't know what the best way may be :)

    We're trying to work out how do something similar to the following
    scenario.

    How do we apply a policy to uninstall CUPS from all servers, except for a
    configurable group of "some".

    To put it another way, how can we have an policy that will configure CUPS
    on a known list of servers (hiera array perhaps?), and uninstall from all
    other $kernel=Linux machines?

    Best to get the install list right first then feed via ENC, or?

    Regs,

    Stephen
    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com.
    To post to this group, send email to puppet-users@googlegroups.com.
    Visit this group at http://groups.google.com/group/puppet-users?hl=en.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Pete Brown at May 17, 2013 at 3:34 am

    On 17 May 2013 13:05, joe wrote:

    The easiest thing to do would to make a subclass called cups::enabled or
    similar and use an override:

    class cups::enabled inherits cups{ # The inherits is important

    Package['cups']{
    ensure => 'present,
    }

    Add service and config file resources here

    }

    The problem with trying to use hiera is it just gets you the package
    ensure parameter. With the override, you can add in the service and config
    file resources as well.

    Um what?
    Hiera is only for setting variables, usually for paremeterized classes.

    Using your solution you will still needs include that class individually on
    the nodes that need cups installed.
    How will you decide that?

    If you have one module included on each node and a class variable set with
    hiera to determine which nodes need cups and which don't you can use that
    in the class to uninstall cups or turn off the service or whatever you like.

    Hiera is about separating that data from your code and making it more
    portable.
    So in this case it is the best way to achieve that with minimal headaches
    and code rewrites in the future.


    On Thursday, May 16, 2013 6:33:25 PM UTC-6, Stephen Wallace wrote:

    Hi all,

    I know that there are likely a few ways to solve the following. I just
    don't know what the best way may be :)

    We're trying to work out how do something similar to the following
    scenario.

    How do we apply a policy to uninstall CUPS from all servers, except for
    a configurable group of "some".

    To put it another way, how can we have an policy that will configure CUPS
    on a known list of servers (hiera array perhaps?), and uninstall from all
    other $kernel=Linux machines?

    Best to get the install list right first then feed via ENC, or?

    Regs,

    Stephen
    --
    You received this message because you are subscribed to the Google Groups
    "Puppet Users" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to puppet-users+unsubscribe@googlegroups.com.
    To post to this group, send email to puppet-users@googlegroups.com.
    Visit this group at http://groups.google.com/group/puppet-users?hl=en.
    For more options, visit https://groups.google.com/groups/opt_out.

    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com.
    To post to this group, send email to puppet-users@googlegroups.com.
    Visit this group at http://groups.google.com/group/puppet-users?hl=en.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Jcbollinger at May 17, 2013 at 2:00 pm

    On Thursday, May 16, 2013 10:34:26 PM UTC-5, Pete wrote:
    On 17 May 2013 13:05, joe <lav...@gmail.com <javascript:>> wrote:

    The easiest thing to do would to make a subclass called cups::enabled or
    similar and use an override:

    class cups::enabled inherits cups{ # The inherits is important

    Package['cups']{
    ensure => 'present,
    }

    Add service and config file resources here

    }

    The problem with trying to use hiera is it just gets you the package
    ensure parameter. With the override, you can add in the service and config
    file resources as well.

    Um what?
    Hiera is only for setting variables, usually for paremeterized classes.

    I think that's a mischaracterization. Hiera is for dynamically loading
    external data into Puppet. Often those data are used as the values of
    variables -- including, but not limited to, class parameters -- but not
    always. In any case, that misses the point: even if the data are stored
    puppet-side in variables, it's all about what you do with them.

    One thing you can do with hiera data is use it to choose which classes to
    apply. That could be via conditional statements, but more interestingly,
    it could also be by directly loading the names of the wanted classes from
    hiera, and passing them directly to the 'include' function.

    The most common other ultimate use of hiera data is to feed it to resources
    as resource parameters (or parts of them) and/or to interpolate it into
    templates. That's not disjoint from the other, however. For example, you
    can use hiera data as a parameter of a resource of a defined type, which
    might in turn use it in a conditional test to make decisions about which
    classes to apply.

    Using your solution you will still needs include that class individually
    on the nodes that need cups installed.
    How will you decide that?

    How will you do that via hiera? Hiera is a valuable tool, but it is not a
    silver bullet. If you use hiera for the job then you still need to arrange
    for the correct nodes to get the correct data. If the decision is based on
    some grouping already modeled in Puppet, then it might actually fall out
    easier to use that existing grouping directly, instead of pushing the data
    out to hiera. Example:

    node default {
       include site::printing
       include site::other_default_config
    }

    node /cups-[0-9]+/ inherits default {
       include site::printing::enabled
    }


    If you have one module included on each node and a class variable set with
    hiera to determine which nodes need cups and which don't you can use that
    in the class to uninstall cups or turn off the service or whatever you like.

    Hiera is about separating that data from your code and making it more
    portable.
    So in this case it is the best way to achieve that with minimal headaches
    and code rewrites in the future.
    The subclassing approach is a bit old-school, but it's perfectly viable.
    At one time it would have been the clear best choice for how to handle a
    problem of this kind, and I'm not persuaded that using external data
    instead is now always preferable. Indeed, a key question to answer is
    where you want the distinguishing data to reside: in your manifests (not
    necessarily in the form of a variable) or external.

    If the question of whether CUPS should be installed or absent is a function
    of nodes' roles, or something similar that has its own representation among
    your manifests (e.g. a class applied only to nodes belonging to the given
    group, or a node declaration by which group members are recognized and
    characterized) then it is logical to encode the data into your manifests as
    a characteristic of nodes having that role. If it's a node-by-node
    decision, however, or if the group otherwise corresponds to a division at
    some level of your hiera hierarchy, then it makes sense to put the data in
    hiera.

    In the end, though, there are still two general approaches to the problem:

        1. apply some class to all nodes that chooses, on some basis, whether to
        ensure CUPS uninstalled or installed and ready, or
        2. apply a class to all nodes that ensures the default case (CUPS
        uninstalled), and override it for those exceptional nodes that should
        provide CUPS services.

    Joe is right that option (1) would need more than just loading the value of
    an 'ensure' parameter from hiera. If CUPS is supposed to be configured on
    the node, then you need also to trigger the corresponding config file and
    service resources, and possibly other resources as well. On the other
    hand, that could still all be controlled by a single flag datum loaded via
    hiera:

    node default {
       include site::printing
    }

    class site::printing($enabled = 'no') {
       # parameter site::printing::enabled is expected to be loaded
       # via hiera, at least when the value need to be 'yes'
       if $enabled == 'yes' {
         package { 'cups': ensure => 'latest' }
         service { 'cups': ... }
         ...
       } else {
         package { 'cups': ensure => 'absent' }
       }
    }


    All solutions I have imagined are variants of one of those, but I don't
    have enough information to judge which might be more suitable for the OP's
    specific case. I think I am safe to say, however, that neither is
    inherently *un*suitable.


    John

    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com.
    To post to this group, send email to puppet-users@googlegroups.com.
    Visit this group at http://groups.google.com/group/puppet-users?hl=en.
    For more options, visit https://groups.google.com/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppuppet-users @
categoriespuppet
postedMay 17, '13 at 12:33a
activeMay 17, '13 at 2:00p
posts5
users4
websitepuppetlabs.com

People

Translate

site design / logo © 2022 Grokbase