Still no joy with lookup despite re-writing Hiera as per you example. 

On Wednesday, February 26, 2020 at 10:20:09 AM UTC, Bart-Jan Vrielink wrote:
>
> Hello,
>
>
> What you have in Hiera is the following:
>
> ---
> sshdconfig:
>   match_address: "xx.xx.xx.xx"
>   permit_root_login: without-password
>
>
> This is a single key sshdconfig with the value:
>
> {
>           "match_address" => "xx.xx.xx.xx",
>           "permit_root_login" => "without-password"
> }
>
>
> If you want to use the contents of match_address in your Puppet code, you 
> would need to lookup sshdconfig and then access 
> $sshconfig['match_address'], or rewrite your yaml into something like:
>
> ---
> sshdconfig::match_address: "xx.xx.xx.xx"
> sshdconfig::permit_root_login: without-password
>
>
> Where you can lookup sshdconfig::match_address
>
>
> As you've already noted, this naming convention is most appropriate for a 
> module sshdconfig. If there is such a module, its parameters match_address 
> and permit_root_login would be automatically looked up in Hiera.
>
>
>  
>
>
> -----Original message-----
> *From:* Dan Crisp <djc...@gmail.com <javascript:>>
> *Sent:* Tuesday 25th February 2020 16:59
> *To:* Puppet Users <puppet...@googlegroups.com <javascript:>>
> *Subject:* Re: [Puppet Users] Hiera Setup Lookup Complaining
>
> Hello Bart, 
>
> Thanks for your reply.  Yes that threw me also.  I was originally looking 
> for sshdconfig::match_adddress however the output from lookup returned:
>
> Searching for "sshdconfig::match_address"
>   Global Data Provider (hiera configuration version 5)
>     Using configuration "/etc/puppetlabs/puppet/hiera.yaml"
>     No such key: "sshdconfig::match_address"
>   Environment Data Provider (hiera configuration version 5)
>     Using configuration 
> "/etc/puppetlabs/code/environments/production/hiera.yaml"
>     Hierarchy entry "Per-node data (yaml version)"
>       Path 
> "/etc/puppetlabs/code/environments/production/data/nodes/lhcsrvmtrrsl01.fixnetix.com.yaml"
>         Original path: "nodes/%{::trusted.certname}.yaml"
>         Path not found
>     Hierarchy entry "Other YAML hierarchy levels"
>       Path "/etc/puppetlabs/code/environments/production/data/common.yaml"
>         Original path: "common.yaml"
>         Path not found
>   *Module "sshdconfig" not found*
> Function lookup() did not find a value for the name 
> 'sshdconfig::match_address'
>
> Suggesting that it was expecting sshdconfig to be be a module.  Not the 
> case in this instance.  In fact, the hiera in question is not refferenced 
> in any module or class etc.  Is that the issue?
>
> On Tuesday, February 25, 2020 at 3:34:49 PM UTC, Bart-Jan Vrielink wrote: 
>>
>> Hello,
>>
>>
>> I see you are looking for 'match_address', but in Hiera it is stored as 
>> 'sshdconfig::match_address'.
>>
>>
>> -----Original message-----
>> *From:* Dan Crisp <djc...@gmail.com 
>> <#zarafa.5e564648.02f2.2753846926c53483@anjie.dontpanic.nl_>>
>> *Sent:* Tuesday 25th February 2020 13:42
>> *To:* Puppet Users <puppet...@googlegroups.com 
>> <#zarafa.5e564648.02f2.2753846926c53483@anjie.dontpanic.nl_>>
>> *Subject:* Re: [Puppet Users] Hiera Setup Lookup Complaining
>>
>> I included the --compile option.  Now (not sure whether as a result of 
>> use --option) I can see 
>> /etc/puppetlabs/code/environments/production/data/nodes/nodename.domain.com.yaml
>>  
>> in the output: 
>>
>> Searching for "lookup_options"
>>   Global Data Provider (hiera configuration version 5)
>>     No such key: "lookup_options"
>>   Environment Data Provider (hiera configuration version 5)
>>     Using configuration 
>> "/etc/puppetlabs/code/environments/production/hiera.yaml"
>>     Merge strategy hash
>>       Hierarchy entry "Per-node data"
>>         Path 
>> "/etc/puppetlabs/code/environments/production/data/nodes/nodename.fixnetix.com.yaml"
>>           Original path: "nodes/%{trusted.certname}.yaml"
>>           No such key: "lookup_options"
>>       Hierarchy entry "Per-OS defaults"
>>         Path 
>> "/etc/puppetlabs/code/environments/production/data/os/RedHat.yaml"
>>           Original path: "os/%{facts.os.family}.yaml"
>>           Path not found
>>       Hierarchy entry "Common data"
>>         Path 
>> "/etc/puppetlabs/code/environments/production/data/common.yaml"
>>           Original path: "common.yaml"
>>           Path not found
>> Searching for "match_address"
>>   Global Data Provider (hiera configuration version 5)
>>     No such key: "match_address"
>>   Environment Data Provider (hiera configuration version 5)
>>     Using configuration 
>> "/etc/puppetlabs/code/environments/production/hiera.yaml"
>>     Hierarchy entry "Per-node data"
>>       Path 
>> "/etc/puppetlabs/code/environments/production/data/nodes/lhcsrvmtrrsl01.fixnetix.com.yaml"
>>         Original path: "nodes/%{trusted.certname}.yaml"
>>         No such key: "match_address"
>>     Hierarchy entry "Per-OS defaults"
>>       Path 
>> "/etc/puppetlabs/code/environments/production/data/os/RedHat.yaml"
>>         Original path: "os/%{facts.os.family}.yaml"
>>         Path not found
>>     Hierarchy entry "Common data"
>>       Path "/etc/puppetlabs/code/environments/production/data/common.yaml"
>>         Original path: "common.yaml"
>>         Path not found
>> Function lookup() did not find a value for the name 'match_address'
>>
>> Still no luck finding the requested value though.
>>
>> Thanks,
>> Dan.
>>
>> On Monday, February 24, 2020 at 7:13:25 PM UTC, Henrik Lindberg wrote: 
>>>
>>> Dan Crisp wrote: 
>>> >  environment/production/data/nodes/nodename.domain.com.yaml 
>>> As you can see in the output - the hiera path expanded to: 
>>>
>>>    Path "/etc/puppetlabs/code/environments/production/data/nodes/.yaml" 
>>>
>>> Meaning that trusted.certname was empty. It would be empty if the node 
>>> "nodename.domain.com" never checked in with the puppet server to 
>>> deposit 
>>> any facts. It will do that on its first agent run though. 
>>>
>>> Meanwhile you have to supply your own facts (and trusted) to do lookups 
>>> as it will be done when the node later requests a catalog. Look at the 
>>> help for the various flags to the lookup command to learn how to give it 
>>> values for facts and trusted information. 
>>>
>>> - henrik 
>>>
>>>
>>> -- 
>>>
>>> Visit my Blog "Puppet on the Edge" 
>>> http://puppet-on-the-edge.blogspot.se/ 
>>>
>>>
>> -- 
>> 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...@googlegroups.com 
>> <#zarafa.5e564648.02f2.2753846926c53483@anjie.dontpanic.nl_>.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/puppet-users/51b5a4bd-0e18-42c9-8cc3-9b77bcfd4218%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/puppet-users/51b5a4bd-0e18-42c9-8cc3-9b77bcfd4218%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>>
> -- 
> 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...@googlegroups.com <javascript:>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/puppet-users/b14bdcca-7a45-45b7-9045-749c6633ae0e%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/puppet-users/b14bdcca-7a45-45b7-9045-749c6633ae0e%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/488bec22-e219-4a89-81f2-3c1bdefa2819%40googlegroups.com.

Reply via email to