Wykorzystanie hash-y jest bardzo wygodne, gdyż pozwala utrzymać strukturę danych z informacją o ich wykorzystaniu. Wyobraźmy sobie, że chcemy zarządzać plikiem /etc/exports zarządzającym wyeksportowanymi systemami plików. Niech nasz hash opisujący udostępniane pliki ma postać:

	$fs= 
	{		
		"/export/repos/"  =>
			{
				"10.40.0.20" => 
				{ 
					"server"  => "10.40.0.20",
					"options" => "ro",
				},				
			},
		"/export/ks" =>
			{

				"10.40.0.20" => 
					{ 
						"server"  => "10.40.0.20",
						"options" => "ro",
					},				
			

				"10.40.0.21" => 
					{
						"server" => "10.40.0.21",
						"options" => "rw",
					},
			},

	}	

Wtedy template może wyglądać następująco:

<% @fs.each do |fs_key, fs_machines| %>
<%= fs_key %> <% fs_machines.each do |machine, options| %> <%= machine %>(<%= options['options'] %>) <% end %> 
<% end %>

Hiera czyli hierarchiczna baza danych bardzo często używana jest razem z puppetem. Jak sprawdzić jakie dane ona przekaże do puppeta? Spójrz na przykłady poniżej:

[root@master1 ~]# hiera -d classes environment=lab1
DEBUG: Sat Dec 20 18:59:05 -0500 2014: Hiera YAML backend starting
DEBUG: Sat Dec 20 18:59:05 -0500 2014: Looking up classes in YAML backend
DEBUG: Sat Dec 20 18:59:05 -0500 2014: Looking for data source lab1
DEBUG: Sat Dec 20 18:59:05 -0500 2014: Found classes in lab1
["u4y_base"]

albo przykład bardziej skomplikowany:

[root@master1 node]# hiera -d classes environment=lab1 ::fqdn=master1
DEBUG: Wed Feb 11 19:53:03 +0100 2015: Hiera YAML backend starting
DEBUG: Wed Feb 11 19:53:03 +0100 2015: Looking up classes in YAML backend
DEBUG: Wed Feb 11 19:53:03 +0100 2015: Looking for data source lab1/node/master1
DEBUG: Wed Feb 11 19:53:03 +0100 2015: Found classes in lab1/node/master1
["apache",
 "firewall_trojans_ignore",
 "u4y_dhcpd",
 "u4y_dhcpd::c_dhcp_client_firewall",
 "u4y_dns_server",
 "u4y_firewall",
 "u4y_nfs",
 "u4y_nfs::c_server_firewall",
 "u4y_host",
 "u4y_repo_sync",
 "u4y_host::c_install",
 "u4y_pxelinux",
 "u4y_pxelinux::c_centos",
 "u4y_firewall::c_service",
 "u4y_puppet_server",
 "u4y_kickstart_server",
 "u4y_kickstart_server::c_kickstart_file",
 "u4y_repo_sync::c_centos6",
 "u4y_repo_sync::c_centos7",
 "u4y_tftp_server",
 "u4y_users::c_users",
 "u4y_sshd",
 "u4y_packages::c_packages",
 "u4y_selinux"]

Nie zawsze musimy korzystać z architektury klient-server. Czasem możemy po prostu wprowadzić reguły zapisane w plikach lokalnych:

[root@vz13505 manifests]# ls -l test_firewall.pp
-rw-r--r-- 1 root root 158 Mar  2 13:18 test_firewall.pp

[root@vz13505 manifests]# puppet apply test_firewall.pp
Warning: Could not retrieve fact fqdn
Notice: /Firewall[000 allow ssh]/ensure: created
Notice: Finished catalog run in 0.46 seconds

[root@vz13505 manifests]# cat test_firewall.pp

## test of firewall module from puppet lab (modul: puppetlabs-firewall)
firewall { '000 allow ssh':
  dport  => 22,
  action => accept,
  proto  => 'tcp',
}