FAQ
Greetings,

I need help; I have been going in circles for too long now and I am sure it
is something silly that I over looked. I am attempting to use environments
with a new server build for Puppet 4 (never could get it working under the
Puppet 3 series; but I never put /that/ much effort into it either). I have
a lot of servers that I really don't want to manage by hand or manually set
anything per server. I would much rather have the agent contact the puppet
server to find out what group it should be in. Yes, there is documentation
on this but I can't get it to work and almost all of my internet sleuthing
has returned results for the old way of doing things which doesn't appear
to be working with Puppet 4 and Hiera 3. Any help would be much appreciated.

My objective: Have a top-level hiera source that tells agents which
environment to use for that host. Have hiera data in the environments
provide further details (ntp servers and what not) for configuring the host.

From my understanding of this[1] it should work. I also found several
online blog examples doing something similar but using the old puppet3 way
of doing things.
[1] https://docs.puppetlabs.com/guides/external_nodes.html

Everything in the production environment works all the time with Hiera. No
other environment works with Hiera calls. I have found it easier to test
for the ntp configuration because unless the system and environment are
"production", testing for the environment just gives 'nil' which doesn't
tell me squat about what is wrong. At least asking for the ntp gives me
errors to look at. :-)

First, lets look at my top level hiera. Pretty default. You can see that I
attempted to force the location for the yaml, but that didn't work either
and I don't want _all_ the servers in the top level anyway.

$ cat /etc/puppetlabs/code/hiera.yaml
---
:backends:
   - yaml
:hierarchy:
   - "nodes/%{::trusted.certname}"
   - common

:yaml:
# datadir is empty here, so hiera uses its defaults:
# - /etc/puppetlabs/code/environments/%{environment}/hieradata on *nix
# - %CommonAppData%\PuppetLabs\code\environments\%{environment}\hieradata
on Windows
# - /etc/puppetlabs/code/hieradata
# When specifying a datadir, make sure the directory exists.
   :datadir:



Now, lets look at the common file for the production environment.

$ cat /etc/puppetlabs/code/environments/production/hieradata/common.yaml
---
ntp::servers:
   - 192.168.109.2
   - 192.168.109.3
environment: 'production'

$ puppet apply --certname=puppetmaster01.me.fqdn -e
"notice(hiera('ntp::servers'))"
Notice: Scope(Class[main]): [192.168.109.2, 192.168.109.3]
Notice: Compiled catalog for puppetmaster01.me.fqdn in environment
production in 0.43 seconds
Notice: Applied catalog in 0.09 seconds

Great! Hiera is working! Now lets move that common file to the top level so
that we can specify which environment to use (again testing with ntp so we
get more than just 'nil' back).

$ mv /etc/puppetlabs/code/environments/production/hieradata/common.yaml
/etc/puppetlabs/code/hieradata/common.yaml
$ puppet apply --certname=puppetmaster01.me.fqdn -e
"notice(hiera('ntp::servers'))"
Error: Evaluation Error: Error while evaluating a Function Call, Could not
find data item ntp::servers in any Hiera data file and no default supplied
  at line 1:8 on node puppetmaster01.me.fqdn


I found a blog that said the puppetserver has to be restarted after every
yaml change (I think that is /way/ off base as that hasn't been quite my
experience) but even doing a restart doesn't change the outcome.


Where I am stuck:
* I can't get any host to work with any environment except "production".
Nothing seems to work. Not hiera, nor puppet agent -t. The host just isn't
found.
* I can't get the top level hiera to provide any details to the agent.

Any help would be greatly appreciated!
Thanks!

--
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 view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/0ba7a983-10be-4e37-9ead-73f184be5476%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

  • Ellison Marks at Jul 23, 2015 at 10:15 pm
    As far as I'm aware, in the default setup, there is no top level hieradata.
    as the comment says, the default datadir is

    /etc/puppetlabs/code/environments/%{environment}/hieradata

    So each environment will have it's own hieradata directory with it's own
    common.yaml. /etc/puppetlabs/code/hieradata will never be looked in.

    I can see some possible ways to accomplish your goal. The braindead one is
    to just link common.yaml into each environment's hieradata.

    A slightly more interesting approach would look like this:

    ---
    :backends:
       - yaml
    :hierarchy:
       - "%{::environment}/%{::trusted.certname}" # or however you want files
    organized under the environments
       - common

    :yaml:
    # datadir is empty here, so hiera uses its defaults:
    # - /etc/puppetlabs/code/environments/%{environment}/hieradata on *nix
    # - %CommonAppData%\PuppetLabs\code\environments\%{environment}\hieradata
    on Windows
    # When specifying a datadir, make sure the directory exists.
       :datadir: /etc/puppetlabs/code/hieradata

    Then your hieradata folder would look like this:

    /etc/puppetlabs/code/hieradata/
       common.yaml
       production/
         node1.example.com
         node2.example.com
       staging/
         node3.example.com
       dev/
         node4.example.com

    On Thursday, July 23, 2015 at 2:23:34 PM UTC-7, Stack Kororā wrote:

    Greetings,

    I need help; I have been going in circles for too long now and I am sure
    it is something silly that I over looked. I am attempting to use
    environments with a new server build for Puppet 4 (never could get it
    working under the Puppet 3 series; but I never put /that/ much effort into
    it either). I have a lot of servers that I really don't want to manage by
    hand or manually set anything per server. I would much rather have the
    agent contact the puppet server to find out what group it should be in.
    Yes, there is documentation on this but I can't get it to work and almost
    all of my internet sleuthing has returned results for the old way of doing
    things which doesn't appear to be working with Puppet 4 and Hiera 3. Any
    help would be much appreciated.

    My objective: Have a top-level hiera source that tells agents which
    environment to use for that host. Have hiera data in the environments
    provide further details (ntp servers and what not) for configuring the host.

    From my understanding of this[1] it should work. I also found several
    online blog examples doing something similar but using the old puppet3 way
    of doing things.
    [1] https://docs.puppetlabs.com/guides/external_nodes.html

    Everything in the production environment works all the time with Hiera. No
    other environment works with Hiera calls. I have found it easier to test
    for the ntp configuration because unless the system and environment are
    "production", testing for the environment just gives 'nil' which doesn't
    tell me squat about what is wrong. At least asking for the ntp gives me
    errors to look at. :-)

    First, lets look at my top level hiera. Pretty default. You can see that I
    attempted to force the location for the yaml, but that didn't work either
    and I don't want _all_ the servers in the top level anyway.

    $ cat /etc/puppetlabs/code/hiera.yaml
    ---
    :backends:
    - yaml
    :hierarchy:
    - "nodes/%{::trusted.certname}"
    - common

    :yaml:
    # datadir is empty here, so hiera uses its defaults:
    # - /etc/puppetlabs/code/environments/%{environment}/hieradata on *nix
    # - %CommonAppData%\PuppetLabs\code\environments\%{environment}\hieradata
    on Windows
    # - /etc/puppetlabs/code/hieradata
    # When specifying a datadir, make sure the directory exists.
    :datadir:



    Now, lets look at the common file for the production environment.

    $ cat /etc/puppetlabs/code/environments/production/hieradata/common.yaml
    ---
    ntp::servers:
    - 192.168.109.2
    - 192.168.109.3
    environment: 'production'

    $ puppet apply --certname=puppetmaster01.me.fqdn -e
    "notice(hiera('ntp::servers'))"
    Notice: Scope(Class[main]): [192.168.109.2, 192.168.109.3]
    Notice: Compiled catalog for puppetmaster01.me.fqdn in environment
    production in 0.43 seconds
    Notice: Applied catalog in 0.09 seconds

    Great! Hiera is working! Now lets move that common file to the top level
    so that we can specify which environment to use (again testing with ntp so
    we get more than just 'nil' back).

    $ mv /etc/puppetlabs/code/environments/production/hieradata/common.yaml
    /etc/puppetlabs/code/hieradata/common.yaml
    $ puppet apply --certname=puppetmaster01.me.fqdn -e
    "notice(hiera('ntp::servers'))"
    Error: Evaluation Error: Error while evaluating a Function Call, Could not
    find data item ntp::servers in any Hiera data file and no default supplied
    at line 1:8 on node puppetmaster01.me.fqdn


    I found a blog that said the puppetserver has to be restarted after every
    yaml change (I think that is /way/ off base as that hasn't been quite my
    experience) but even doing a restart doesn't change the outcome.


    Where I am stuck:
    * I can't get any host to work with any environment except "production".
    Nothing seems to work. Not hiera, nor puppet agent -t. The host just isn't
    found.
    * I can't get the top level hiera to provide any details to the agent.

    Any help would be greatly appreciated!
    Thanks!
    --
    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 view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/dadfcc02-f381-4b1a-8cda-fbac999d7e37%40googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Ellison Marks at Jul 23, 2015 at 10:19 pm
    Ah, sorry, forgot the .yaml part of the filenames. hieradata would actually
    look like this:
    /etc/puppetlabs/code/hieradata/
    common.yaml
    production/
    node1.example.com.yaml
    node2.example.com.yaml
    staging/
    node3.example.com.yaml
    dev/
    node4.example.com.yaml
    --
    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 view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/5f1750a8-f26d-4606-bce5-21c4fb5789af%40googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • ~Stack~ at Jul 23, 2015 at 10:21 pm
    Greetings,

    Thanks for the suggestions. I stepped out for a bit, but will try it as
    soon as I get back.
    On 07/23/2015 05:15 PM, Ellison Marks wrote:
    As far as I'm aware, in the default setup, there is no top level
    hieradata. as the comment says, the default datadir is

    /etc/puppetlabs/code/environments/%{environment}/hieradata

    So each environment will have it's own hieradata directory with it's own
    common.yaml. /etc/puppetlabs/code/hieradata will never be looked in.
    OK. I guess I miss understood that. I thought I would be able to define
    different types of environments which would be populated by that
    %{environment} variable. Thus, I thought there was something in the top
    level to tell the nodes which %{environment} variable (and subsequently
    which hieradata directory) to use.

    I can see some possible ways to accomplish your goal. The braindead one
    is to just link common.yaml into each environment's hieradata.
    So every host would be essentially defined in every common.yaml??
    Doesn't that seem a little weird?
    A slightly more interesting approach would look like this:

    ---
    :backends:
    - yaml
    :hierarchy:
    - "%{::environment}/%{::trusted.certname}" # or however you want files
    organized under the environments
    - common

    :yaml:
    # datadir is empty here, so hiera uses its defaults:
    # - /etc/puppetlabs/code/environments/%{environment}/hieradata on *nix
    # -
    %CommonAppData%\PuppetLabs\code\environments\%{environment}\hieradata on
    Windows
    # When specifying a datadir, make sure the directory exists.
    :datadir: /etc/puppetlabs/code/hieradata

    Then your hieradata folder would look like this:

    /etc/puppetlabs/code/hieradata/
    common.yaml
    production/
    node1.example.com
    node2.example.com
    staging/
    node3.example.com
    dev/
    node4.example.com
    I will gladly give this a try as soon as I get a chance.

    Thanks!!


    --
    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 view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/55B168D5.602%40gmail.com.
    For more options, visit https://groups.google.com/d/optout.
  • Ellison Marks at Jul 23, 2015 at 11:05 pm
    No, the environment variable is set in the puppet.conf of every host. I'm
    not even sure what the effect would be of trying to define environment in
    hiera.

    Please see:
    https://docs.puppetlabs.com/puppet/latest/reference/environments_assigning.html
    On Thursday, July 23, 2015 at 3:21:27 PM UTC-7, Stack Kororā wrote:

    Greetings,

    Thanks for the suggestions. I stepped out for a bit, but will try it as
    soon as I get back.
    On 07/23/2015 05:15 PM, Ellison Marks wrote:
    As far as I'm aware, in the default setup, there is no top level
    hieradata. as the comment says, the default datadir is

    /etc/puppetlabs/code/environments/%{environment}/hieradata

    So each environment will have it's own hieradata directory with it's own
    common.yaml. /etc/puppetlabs/code/hieradata will never be looked in.
    OK. I guess I miss understood that. I thought I would be able to define
    different types of environments which would be populated by that
    %{environment} variable. Thus, I thought there was something in the top
    level to tell the nodes which %{environment} variable (and subsequently
    which hieradata directory) to use.

    I can see some possible ways to accomplish your goal. The braindead one
    is to just link common.yaml into each environment's hieradata.
    So every host would be essentially defined in every common.yaml??
    Doesn't that seem a little weird?
    A slightly more interesting approach would look like this:

    ---
    :backends:
    - yaml
    :hierarchy:
    - "%{::environment}/%{::trusted.certname}" # or however you want files
    organized under the environments
    - common

    :yaml:
    # datadir is empty here, so hiera uses its defaults:
    # - /etc/puppetlabs/code/environments/%{environment}/hieradata on *nix
    # -
    %CommonAppData%\PuppetLabs\code\environments\%{environment}\hieradata on
    Windows
    # When specifying a datadir, make sure the directory exists.
    :datadir: /etc/puppetlabs/code/hieradata

    Then your hieradata folder would look like this:

    /etc/puppetlabs/code/hieradata/
    common.yaml
    production/
    node1.example.com
    node2.example.com
    staging/
    node3.example.com
    dev/
    node4.example.com
    I will gladly give this a try as soon as I get a chance.

    Thanks!!

    --
    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 view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/89be8506-e94e-48da-a0df-1dce4f3cf962%40googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Stack Kororā at Jul 24, 2015 at 2:01 am

    On Thursday, July 23, 2015 at 6:05:27 PM UTC-5, Ellison Marks wrote:
    No, the environment variable is set in the puppet.conf of every host. I'm
    not even sure what the effect would be of trying to define environment in
    hiera.

    Please see:
    https://docs.puppetlabs.com/puppet/latest/reference/environments_assigning.html
    OK...that just made my head hurt a bit more. :-)

    So that link says that I can do what I am after with an ENC (which that
    page doesn't tell you what that means...).
    "When writing an ENC, simply ensure that the environment: key is set in the
    YAML output that the ENC returns. See the documentation on writing ENCs for
    details.
    <https://docs.puppetlabs.com/guides/external_nodes.html#environment>"

    That link takes you here:
    https://docs.puppetlabs.com/guides/external_nodes.html#environment

    That gives an example of a hiera file. Plus it says " In Puppet 3 and
    later, this will become the only environment used by the node in its
    requests for catalogs and files." So if that is the only way things will
    happen in the future, I should probably do it this way. Things are looking
    good right? Except that documentation is not quite complete...I have read
    it like three times and I am still not sure how I am supposed to set that
    up to get it working...

    Let me poke at it for a while and see what happens.

    Thanks!

    --
    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 view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/6e33aaca-4d31-4e79-96f9-95064a3fe2e3%40googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Jcbollinger at Jul 24, 2015 at 1:05 pm

    On Thursday, July 23, 2015 at 9:01:42 PM UTC-5, Stack Kororā wrote:

    On Thursday, July 23, 2015 at 6:05:27 PM UTC-5, Ellison Marks wrote:

    No, the environment variable is set in the puppet.conf of every host. I'm
    not even sure what the effect would be of trying to define environment in
    hiera.

    Please see:
    https://docs.puppetlabs.com/puppet/latest/reference/environments_assigning.html
    OK...that just made my head hurt a bit more. :-)

    So that link says that I can do what I am after with an ENC (which that
    page doesn't tell you what that means...).
    "When writing an ENC, simply ensure that the environment: key is set in
    the YAML output that the ENC returns. See the documentation on writing
    ENCs for details.
    <https://docs.puppetlabs.com/guides/external_nodes.html#environment>"
    More specifically, it says that if what you are after is having the master
    assign nodes to non-default environments (as opposed to accepting nodes'
    self-assignment) then an ENC is the *only* way to accomplish that.


    That link takes you here:
    https://docs.puppetlabs.com/guides/external_nodes.html#environment

    That gives an example of a hiera file.

    No, it doesn't. It gives an example ENC output. ENC output is in YAML
    format, but that doesn't make it an Hiera file. Perhaps this is part of
    your confusion.


    Plus it says " In Puppet 3 and later, this will become the only
    environment used by the node in its requests for catalogs and files." So
    if that is the only way things will happen in the future, I should probably
    do it this way. Things are looking good right? Except that documentation is
    not quite complete...I have read it like three times and I am still not
    sure how I am supposed to set that up to get it working...
    From Puppet's perspective, an ENC is simply an external program that Puppet
    will run to obtain information about how to classify a node. Puppet will
    provide the node identifier (ordinarily $::clientcert) as the program's
    single command-line argument. The classification information is expected
    to be returned to Puppet via the ENC's standard output, in YAML format, and
    it can specify both global variables for use during catalog building and
    classes that must be included in the node's catalog (hence "classifier").
    Among the global variables an ENC can specify is $::environment, which is
    special to Puppet. The documentation link Ellison provided gives a brief
    but complete example of ENC output containing all these elements.

    Puppet will combine the classification information provided by any ENC with
    whatever is presented in your manifest set. Note one potential gotcha
    here: if you use an ENC, and your site manifest directly or indirectly
    contains any node blocks, then Puppet insists on being able to match *every*
    client node to a node block. That's not hard to accommodate (you can use a
    default node block, for example), but it's important to know.


    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 view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/566a6fa0-eaf8-40c9-a9aa-34d9336633ba%40googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppuppet-users @
categoriespuppet
postedJul 23, '15 at 9:23p
activeJul 24, '15 at 1:05p
posts7
users3
websitepuppetlabs.com

People

Translate

site design / logo © 2022 Grokbase