After making the changes, which users will be added to /etc/ssh/sshd_config file on a RedHat node? The answer is root, gary, and jeff. Why? The root user will ALWAYS be included in /etc/ssh/sshd_config because the common.yaml file that EVERY node evaluates contains the value of ‘root’ for the ssh_users parameter. Next, because this is a RedHat node, Hiera will concatenate the values of ‘gary’ and ‘jeff’ to the array because those are the values for the ssh_users parameter in RedHat.yaml. What if we run this on a Debian node? The answer is root and hunter (because the value of the ssh_users parameter in the Debian.yaml file is ‘hunter’).
Hiera Best Practices
Hiera is still new to many people, and the concept of a hierarchical lookup system can seem a bit foreign initially. Because of this, there are a couple of best practices that are important to observe when getting started with Hiera and Puppet.
Keep hierarchies to a minimum
This is the time-proven rule of “Just because you can, doesn’t mean you should.” Hierarchy levels are incredibly dynamic tools that will allow you to do a number of things that were previously difficult, but too many of them can lead to problems when debugging (i.e. “Where was that parameter set, again?”). Three to four hierarchy levels should be enough for most sites; if you have more than that, you might want to re-think your approach.
Version control your Hiera data directory separately from your Puppet repository
The benefit of the :datadir: parameter in hiera.yaml is that you can use Facter fact values to determine the path of your Hiera data directory. For example, a site using two Puppet environments called ‘development’ and ‘production’ that has implemented the ssh module we outlined above might have the following directory tree at /etc/puppetlabs/puppet/environments