Hello, Its configuration file is hiera.yaml, and path depends on how it is invoked, which can be one of the following ways:
-When Is invoked from puppet, the path will be: /etc/puppet/hiera.yaml -When Is invoked from CLI or when used in the Ruby code: /etc/hiera.yaml So you have to see for the rights. The establishment of a hierarchy allows control over the deployment of modules. By including the package in the common file. The entire node receive packages. Hence the use of the hierarchy for that installed on one or more dedicated server for application. The problem here is that it does not find the class PostgreSQL. We must therefore indicate the missing class. http://docs.puppetlabs.com/hiera/1/puppet.html#assigning-classes-to-nodes-with-hiera-hierainclude http://docs.puppetlabs.com/hiera/1/complete_example.html Le mardi 8 septembre 2015 16:19:39 UTC+2, jcbollinger a écrit : > > > > On Friday, September 4, 2015 at 6:54:52 AM UTC-5, David Levray wrote: >> >> Thanks for your return. >> >> It is noted that hiera your search directly in the common.yaml, it is not >> your path hierarchy. >> > > > Oh, come on. It is not erroneous to have an Hiera hierarchy consisting of > only one level. Correct operation of Hiera does not depend on there being > more than one, as evidenced, for example, by the fact that Alfredo's > configuration *has been working for him* except with respect to > postgres. All appearances point to the issue being associated with the > details of the data that Hiera is providing to Puppet, not Hiera's general > configuration. > > > >> >> >> Here's an example search or hiera good in the order of hierarchy: >> >> My hierarchy is: >> >> >> :hierarchy: >> >> - "node/%{fqdn}" >> >> - "virtual/%{virtual}" >> >> - "osfamily/%{osfamily}" >> >> - common >> >> >> > > > Very good, but Alfredo's hierarchy does not need to look like yours. > > > >> >> >> >> >> So check the following: >> >> 1 / verifies that the file points /etc/hiera.yaml of your file >> /etc/puppet/hiera.yaml: >> >> ls -rtla /etc/hiera.yaml >> >> /etc/hiera.yaml -> /etc/puppet/hiera.yaml >> >> >> >> 2 / Check the owners: >> >> Chown puppet: puppet /etc/puppet/hiera.yaml >> >> Chown -R puppet: puppet / etc / puppet / hieradata / >> >> >> > > > Hiera data files do not need to be owned by 'puppet' so long as 'puppet' > can read them. In fact, it is better for them to be owned by root and > writable only by root, for, as a general rule, it is preferable for > services to be unable to modify their own data and configuration. That > reduces the surface area accessible to malicious actors. > > > 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/83b7272f-d037-40ba-bce4-27dccbf67176%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
