FAQ
We have a small and growing Puppet infrastructure we started a few months
ago: about 30 modules and 40 hosts.

At this point, all of the modules we have written use parameterized
classes. That way, when we call the module from the host's node.pp file, we
can override defaults (if necessary).

We knew using parameterized classes wouldn't scale. Now that we've upgraded
to Puppet 3 on the server and all of our clients, we want to do things the
Hiera way.

The problem is, we've been unable to find any good documentation on how to
use hiera and Puppet together.

Yes, we've read the hiera documentation<http://docs.puppetlabs.com/hiera/1/>on the puppetlabs web site. That was helpful in explaining hiera general
concepts, but it doesn't really explain how to integrate hiera data lookup
with Puppet.

The main thing we're trying to understand is how each host manifest can
declare its own hiera hierarchy for data lookup. We can't do this with the
yaml backend, because the yaml backend will apply the same hierarchy to
EVERY client, because all Puppet clients use the /etc/puppet/hiera.yaml
file on the puppetmaster. Granted, we can customize the hierarchy on the
puppetmaster with facter facts, but that doesn't give us enough control.

For example, host foo might want:

:hierarchy:
- host/%{::fqdn}/config
- app/external-nameserver/config
- common/config

But host bar might want:

:hierarchy:
- host/%{::fqdn}/config
- app/internal-mailserver/config
- common/config

That's what we can't figure out how to do with hiera.

Frustratingly, the one section of the hiera documentation on the puppetlabs
web site that looks like it might explain what we need to know—the "Usage
with Puppet" section—just says "Coming soon".

There's just no way we're the only site out there using Puppet who needs to
vary the hiera lookup hierarchy per node. What's the secret to it? How do
you actually do it?

Thanks,
James

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

  • Brendan O'Bra at Mar 7, 2013 at 8:36 pm
    We use a "classifier pattern", using this as a starting point
    http://nuknad.com/2011/02/11/self-classifying-puppet-nodes/
    Basically, we have a few custom facts that tell a node what it is (the
    facts are set via a small MCollective plugin), and then the facts are
    consumed at Puppet runtime.

    2 gotchas:
    1) for hiera standalone, it uses /etc/hiera.yaml for config. For
    puppet/hiera, it uses /etc/puppet/hiera.yaml (yes, this is in the docs
    somewhere, but I have the attention span of a gnat)
    2) If you change hiera.yaml, you need to restart the Puppet Master service
    (last time I checked, anyways)

    On Thu, Mar 7, 2013 at 12:11 PM, James Ralston wrote:

    We have a small and growing Puppet infrastructure we started a few months
    ago: about 30 modules and 40 hosts.

    At this point, all of the modules we have written use parameterized
    classes. That way, when we call the module from the host's node.pp file, we
    can override defaults (if necessary).

    We knew using parameterized classes wouldn't scale. Now that we've
    upgraded to Puppet 3 on the server and all of our clients, we want to do
    things the Hiera way.

    The problem is, we've been unable to find any good documentation on how to
    use hiera and Puppet together.

    Yes, we've read the hiera documentation<http://docs.puppetlabs.com/hiera/1/>on the puppetlabs web site. That was helpful in explaining hiera general
    concepts, but it doesn't really explain how to integrate hiera data lookup
    with Puppet.

    The main thing we're trying to understand is how each host manifest can
    declare its own hiera hierarchy for data lookup. We can't do this with the
    yaml backend, because the yaml backend will apply the same hierarchy to
    EVERY client, because all Puppet clients use the /etc/puppet/hiera.yaml
    file on the puppetmaster. Granted, we can customize the hierarchy on the
    puppetmaster with facter facts, but that doesn't give us enough control.

    For example, host foo might want:

    :hierarchy:
    - host/%{::fqdn}/config
    - app/external-nameserver/config
    - common/config

    But host bar might want:

    :hierarchy:
    - host/%{::fqdn}/config
    - app/internal-mailserver/config
    - common/config

    That's what we can't figure out how to do with hiera.

    Frustratingly, the one section of the hiera documentation on the
    puppetlabs web site that looks like it might explain what we need to
    know—the "Usage with Puppet" section—just says "Coming soon".

    There's just no way we're the only site out there using Puppet who needs
    to vary the hiera lookup hierarchy per node. What's the secret to it? How
    do you actually do it?

    Thanks,
    James

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



    --
    GVoice: 707.410.0371
    LinkedIn: http://www.linkedin.com/in/brendanobra

    --
    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.
  • Chad Huneycutt at Mar 8, 2013 at 6:54 pm
    Hi James,
    We are in a similar situation. I think of it slightly
    differently, though. We are trying to use the roles/profiles pattern,
    and I am having trouble figuring out how to get hiera to use the
    profile to do the lookup. So rather than explicitly listing the
    values in the hierarchy, I want:

    :hierarchy:
    - host/%{::fqdn}
    - profiles/%{profile}
    - common

    So not per node, but per profile, but it seems like that is what you
    really want anyway?

    I could, as Brendan suggests, distribute a fact out to all the nodes,
    but I worry about the security of that solution since it puts the node
    in control of its configuration.

    I have come up with a scheme that will work if I can figure out the
    class that included the class that does the hiera lookup, but that is
    a bit of a hack and probably not scalable.

    Ideally, I would love it it puppet supported a pattern like
    roles/profiles directly in the dsl and could expose that to hiera.

    - Chad
    On Thu, Mar 7, 2013 at 3:11 PM, James Ralston wrote:
    We have a small and growing Puppet infrastructure we started a few months
    ago: about 30 modules and 40 hosts.

    At this point, all of the modules we have written use parameterized classes.
    That way, when we call the module from the host's node.pp file, we can
    override defaults (if necessary).

    We knew using parameterized classes wouldn't scale. Now that we've upgraded
    to Puppet 3 on the server and all of our clients, we want to do things the
    Hiera way.

    The problem is, we've been unable to find any good documentation on how to
    use hiera and Puppet together.

    Yes, we've read the hiera documentation on the puppetlabs web site. That was
    helpful in explaining hiera general concepts, but it doesn't really explain
    how to integrate hiera data lookup with Puppet.

    The main thing we're trying to understand is how each host manifest can
    declare its own hiera hierarchy for data lookup. We can't do this with the
    yaml backend, because the yaml backend will apply the same hierarchy to
    EVERY client, because all Puppet clients use the /etc/puppet/hiera.yaml file
    on the puppetmaster. Granted, we can customize the hierarchy on the
    puppetmaster with facter facts, but that doesn't give us enough control.

    For example, host foo might want:

    :hierarchy:
    - host/%{::fqdn}/config
    - app/external-nameserver/config
    - common/config

    But host bar might want:

    :hierarchy:
    - host/%{::fqdn}/config
    - app/internal-mailserver/config
    - common/config

    That's what we can't figure out how to do with hiera.

    Frustratingly, the one section of the hiera documentation on the puppetlabs
    web site that looks like it might explain what we need to know—the "Usage
    with Puppet" section—just says "Coming soon".

    There's just no way we're the only site out there using Puppet who needs to
    vary the hiera lookup hierarchy per node. What's the secret to it? How do
    you actually do it?

    Thanks,
    James

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


    --
    Chad M. Huneycutt

    --
    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.
  • Aaron Grewell at Mar 8, 2013 at 7:49 pm
    I don't know of a way to have multiple hierarchies, but if you need central
    control of parameters like profile you can use an ENC. At one point I even
    experimented with a yaml- based ENC that used my hiera data files to keep
    all the information in one place.
    On Mar 8, 2013 10:54 AM, "Chad Huneycutt" wrote:

    Hi James,
    We are in a similar situation. I think of it slightly
    differently, though. We are trying to use the roles/profiles pattern,
    and I am having trouble figuring out how to get hiera to use the
    profile to do the lookup. So rather than explicitly listing the
    values in the hierarchy, I want:

    :hierarchy:
    - host/%{::fqdn}
    - profiles/%{profile}
    - common

    So not per node, but per profile, but it seems like that is what you
    really want anyway?

    I could, as Brendan suggests, distribute a fact out to all the nodes,
    but I worry about the security of that solution since it puts the node
    in control of its configuration.

    I have come up with a scheme that will work if I can figure out the
    class that included the class that does the hiera lookup, but that is
    a bit of a hack and probably not scalable.

    Ideally, I would love it it puppet supported a pattern like
    roles/profiles directly in the dsl and could expose that to hiera.

    - Chad
    On Thu, Mar 7, 2013 at 3:11 PM, James Ralston wrote:
    We have a small and growing Puppet infrastructure we started a few months
    ago: about 30 modules and 40 hosts.

    At this point, all of the modules we have written use parameterized classes.
    That way, when we call the module from the host's node.pp file, we can
    override defaults (if necessary).

    We knew using parameterized classes wouldn't scale. Now that we've upgraded
    to Puppet 3 on the server and all of our clients, we want to do things the
    Hiera way.

    The problem is, we've been unable to find any good documentation on how to
    use hiera and Puppet together.

    Yes, we've read the hiera documentation on the puppetlabs web site. That was
    helpful in explaining hiera general concepts, but it doesn't really explain
    how to integrate hiera data lookup with Puppet.

    The main thing we're trying to understand is how each host manifest can
    declare its own hiera hierarchy for data lookup. We can't do this with the
    yaml backend, because the yaml backend will apply the same hierarchy to
    EVERY client, because all Puppet clients use the /etc/puppet/hiera.yaml file
    on the puppetmaster. Granted, we can customize the hierarchy on the
    puppetmaster with facter facts, but that doesn't give us enough control.

    For example, host foo might want:

    :hierarchy:
    - host/%{::fqdn}/config
    - app/external-nameserver/config
    - common/config

    But host bar might want:

    :hierarchy:
    - host/%{::fqdn}/config
    - app/internal-mailserver/config
    - common/config

    That's what we can't figure out how to do with hiera.

    Frustratingly, the one section of the hiera documentation on the
    puppetlabs
    web site that looks like it might explain what we need to know—the "Usage
    with Puppet" section—just says "Coming soon".

    There's just no way we're the only site out there using Puppet who needs to
    vary the hiera lookup hierarchy per node. What's the secret to it? How do
    you actually do it?

    Thanks,
    James

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


    --
    Chad M. Huneycutt

    --
    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.
  • Felix Frank at Mar 18, 2013 at 9:23 am
    Hi,
    On 03/08/2013 07:54 PM, Chad Huneycutt wrote:
    I could, as Brendan suggests, distribute a fact out to all the nodes,
    but I worry about the security of that solution since it puts the node
    in control of its configuration.
    I'm currenlty dealing with similar issues for the same security reason.
    I have come up with a scheme that will work if I can figure out the
    class that included the class that does the hiera lookup, but that is
    a bit of a hack and probably not scalable.
    Color me interested :-)

    A had hoped this thread would bear more fruit in the form of someone who
    knows how this can be solved.

    At this rate, I may go ahead and patch hiera towards some master-side
    external "meta" lookup so that parts of the hierarchy can be modified
    based on the $certname.

    Cheers,
    Felix

    --
    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.
  • Ellison Marks at Mar 8, 2013 at 7:55 pm
    I'm not really sure you're describing multiple hierarchies. From the
    limited hierarchies you posted, it sort of looks like the hierarchy you're
    describing is like so:

    :hierarchy:
    - host/%{::fqdn}/config
    - app/%{::some_custom_fact_app}/config
    - common/config

    which is pretty simple (if slightly manual) to accomplish with something
    like facter dot d from the stdlib.
    On Thursday, March 7, 2013 12:11:09 PM UTC-8, James Ralston wrote:

    We have a small and growing Puppet infrastructure we started a few months
    ago: about 30 modules and 40 hosts.

    At this point, all of the modules we have written use parameterized
    classes. That way, when we call the module from the host's node.pp file, we
    can override defaults (if necessary).

    We knew using parameterized classes wouldn't scale. Now that we've
    upgraded to Puppet 3 on the server and all of our clients, we want to do
    things the Hiera way.

    The problem is, we've been unable to find any good documentation on how to
    use hiera and Puppet together.

    Yes, we've read the hiera documentation<http://docs.puppetlabs.com/hiera/1/>on the puppetlabs web site. That was helpful in explaining hiera general
    concepts, but it doesn't really explain how to integrate hiera data lookup
    with Puppet.

    The main thing we're trying to understand is how each host manifest can
    declare its own hiera hierarchy for data lookup. We can't do this with the
    yaml backend, because the yaml backend will apply the same hierarchy to
    EVERY client, because all Puppet clients use the /etc/puppet/hiera.yaml
    file on the puppetmaster. Granted, we can customize the hierarchy on the
    puppetmaster with facter facts, but that doesn't give us enough control.

    For example, host foo might want:

    :hierarchy:
    - host/%{::fqdn}/config
    - app/external-nameserver/config
    - common/config

    But host bar might want:

    :hierarchy:
    - host/%{::fqdn}/config
    - app/internal-mailserver/config
    - common/config

    That's what we can't figure out how to do with hiera.

    Frustratingly, the one section of the hiera documentation on the
    puppetlabs web site that looks like it might explain what we need to
    know—the "Usage with Puppet" section—just says "Coming soon".

    There's just no way we're the only site out there using Puppet who needs
    to vary the hiera lookup hierarchy per node. What's the secret to it? How
    do you actually do it?

    Thanks,
    James
    --
    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.
  • Klavs Klavsen at Mar 18, 2013 at 2:03 pm
    I solved this issue, by using netgroups (in LDAP) - which is loaded into
    puppet, by a script which is run by external_nodes setting (it just
    provides parameters - no actual nodes).

    This way, a server can have multiple roles (by being in multiple
    netgroups).

    Unfortunately hiera can't currently handle if an array in it's lookup
    hierachy - now that would be a really great addition to hiera :)

    I then just group servers (or other netgroups) in netgroups as needed.


    --
    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.
  • Felix Frank at Mar 19, 2013 at 9:26 am

    On 03/18/2013 03:02 PM, Klavs Klavsen wrote:
    I solved this issue, by using netgroups (in LDAP) - which is loaded into
    puppet, by a script which is run by external_nodes setting (it just
    provides parameters - no actual nodes).

    This way, a server can have multiple roles (by being in multiple
    netgroups).
    Hmm, external nodes? You have an ENC?

    Well, sure - with one of those, the problem can be worked around, I guess...

    --
    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.
  • Peter Brown at Mar 19, 2013 at 11:02 pm
    You can apparently use LDAP as an ENC...
    I run FreeIPA here but I haven't tried setting it up as an ENC yet (I
    currently use Foreman)

    Here are the official docs on the subject.
    http://projects.puppetlabs.com/projects/puppet/wiki/LDAP_Nodes

    The ENC docs may help as well.
    http://docs.puppetlabs.com/guides/external_nodes.html


    On 19 March 2013 19:26, Felix Frank wrote:
    On 03/18/2013 03:02 PM, Klavs Klavsen wrote:
    I solved this issue, by using netgroups (in LDAP) - which is loaded into
    puppet, by a script which is run by external_nodes setting (it just
    provides parameters - no actual nodes).

    This way, a server can have multiple roles (by being in multiple
    netgroups).
    Hmm, external nodes? You have an ENC?

    Well, sure - with one of those, the problem can be worked around, I
    guess...

    --
    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.
  • Darryl Wisneski at Mar 20, 2013 at 2:39 am

    On Thu, Mar 07, 2013 at 12:11:09PM -0800, James Ralston wrote:

    At this point, all of the modules we have written use parameterized
    classes. That way, when we call the module from the host's node.pp file, we
    can override defaults (if necessary).
    I lump all nodes into the node default and send all hosts thru one
    manifest. It processes thru a hash of hashes derived from one yaml
    file with lookups based on ${hostname} only. There is no parameterized
    classes in use. $hostname is the only fact in use; we don't trust
    the nodes facts.

    node default {
    include processhosts
    }
    The main thing we're trying to understand is how each host manifest can
    declare its own hiera hierarchy for data lookup. We can't do this with the
    yaml backend, because the yaml backend will apply the same hierarchy to
    EVERY client, because all Puppet clients use the /etc/puppet/hiera.yaml
    file on the puppetmaster. Granted, we can customize the hierarchy on the
    puppetmaster with facter facts, but that doesn't give us enough control.
    You can use one yaml file for all hosts to accomplish the above.

    $ more hiera.yaml
    ---
    :backends:
    - yaml
    :hierarchy:
    - %{hostname}
    - common

    I could overlay individual hostname.yaml files but I just keep the
    hash of hashes in one yaml file, common.yaml.

    $ more hieradata/common.yaml
    servers :
    node-a :
    sshd_auth: local
    ClientAliveInterval: nil
    ClientAliveCountMax: nil
    server_role: site-server
    location: []
    smtp-server: nil
    node-b :
    sshd_auth: local
    ClientAliveInterval: nil
    ClientAliveCountMax: nil
    server_role: site-server
    location: []
    smtp-server: nil
    node-c :
    sshd_auth: ldap
    ClientAliveInterval: nil
    ClientAliveCountMax: nil
    server_role: linux-site-server
    location: []
    smtp-server: postfix


    $ more modules/processhosts/manifests/init.pp

    class processhosts {

    $all_data = hiera_hash('servers')
    $node_data = $all_data[$hostname]

    $sshd_type = $node_data['sshd_auth']
    $server_role = $node_data['server_role']
    $ClientAliveInterval = $node_data['ClientAliveInterval']
    $ClientAliveCountMax = $node_data['ClientAliveCountMax']
    $location = $node_data['location']
    $smtp = $node_data['smtp-server']

    notice "my name is $hostname and I am using hiera from YAML"
    notice ( "setting sshd_type: $sshd_type" )

    case $server_role {
    site-server: {
    notice "${hostname} is a site-server"
    }
    linux-site-server: {
    notice "${hostname} is a linux-site-server"
    }
    linux-site-vm: {
    notice "${hostname} is a linux-site-vm"
    include pkg::apt
    }
    general: {
    notice "${hostname} is a general-server"
    }
    fbsdhost: {
    notice "${hostname} is a fbsdhost"
    include admin::snmpd
    }
    nil: {
    notice "${hostname} is a server of undefined type"
    }
    default: {
    notice "${hostname} is a server of undefined type and not nil"
    }
    }

    case $mysudo {
    '': {
    include admin::sudo
    }
    }

    }

    The processhosts module imports other manifests based on the hostname
    lookup of the 'servers' hash of hashes in common.yaml. This has
    proven to be sane and flexible. If the node isn't defined in the
    common.yaml, you get a catalog error "err: Could not retrieve
    catalog from remote server:."

    Regards,
    -dkw

    --
    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.
  • Robin Lee Powell at Mar 24, 2013 at 11:50 pm

    On Wed, Mar 20, 2013 at 02:39:38AM +0000, Darryl Wisneski wrote:
    On Thu, Mar 07, 2013 at 12:11:09PM -0800, James Ralston wrote:

    At this point, all of the modules we have written use parameterized
    classes. That way, when we call the module from the host's node.pp file, we
    can override defaults (if necessary).
    I lump all nodes into the node default and send all hosts thru one
    manifest. It processes thru a hash of hashes derived from one yaml
    file with lookups based on ${hostname} only. There is no parameterized
    classes in use. $hostname is the only fact in use; we don't trust
    the nodes facts.

    node default {
    include processhosts
    }
    [snip extended explanation]

    That was *exactly* what I was looking for! Thank you so much.

    -Robin

    --
    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
postedMar 7, '13 at 8:11p
activeMar 24, '13 at 11:50p
posts11
users10
websitepuppetlabs.com

People

Translate

site design / logo © 2021 Grokbase