Our infrastructure uses puppet with public puppet modules. All our secrets and our installation-spesific parameters are thus placed in hiera.
Data distribution
The hieradata directory contains multiple .yaml files holding our information. When we have multiple puppet masters its important that each of the puppetmasters have an updated version of the hieradata, in addition to an updated list of puppet-modules. As the hiera-data are full of secrets we cannot publish them on github, and have all puppetmasters pull the information from there. What we do instead is to let the hieradata be a local git-repo which each puppetserver is pulling from eachother.
Hiera keys
Depending on what services you are handling with puppet, you might need various keys in hiera. This page tries to list which keys needs to be present to use our role/profile repositories.
General information
There are quite a bit of data which are not associated to a specific service, but are rather used by various modules, and should thus generally allways be present:
DHCP server
When running DHCP servers, the following keys are needed:
| Key | Description | Example | Created by | Data-type | Used by: |
|---|---|---|---|---|---|
| profile::dhcp::omapi::key | The omapi key used to update the DHCP servers | 'omapi_key==' | dnssec-keygen -r /dev/urandom -a HMAC-MD5 -b 512 -n HOST key_name | String | role::bootstrap, role::dhcp |
| profile::dhcp::omapi::name | The omapi key name | 'key_name' | ↑ | String | role::bootstrap, role::dhcp |
| profile::dhcp::searchdomain | The default search-domain handed to DHCP clients | 'cloud.domain.com' | N/A | String | role::bootstrap, role::dhcp |
| profile::dns::resolvers | The DNS resolvers for clients to use | - '<ip-addres-DNS1>' - '<ip-address-DNS2>' | N/A | List of strings | role::bootstrap, role::dhcp |
DNS server
If you are hosting a DNS server the following keys are needed:
| Key | Description | Example | Created by | Data-type | Used by: |
|---|---|---|---|---|---|
| profile::dns::forwarders | Which DNS servers your DNS server should use to resolve domainnames where it is not an authorative DNS | - '<ip-addres-DNS1>' - '<ip-address-DNS2>' | N/A | List of strings | role::bootstrap, role::dns::master |
| profile::dns::key::transfer | The TSIG keys used for zone-transfers | 'UvetjoX5zMiw/NbQr3biug==' | dnssec-keygen -a HMAC-MD5 -b 128 -n HOST <keyname> | String | role::bootstrap, role::dns::master, role::dns::slave |
| profile::dns::key::update | The TSIG keys used for DNS updates | 'UvetjoX5zMiw/NbQr3biug==' | dnssec-keygen -a HMAC-MD5 -b 128 -n HOST <keyname> | String | role::bootstrap, role::dns::master, role::dns::slave |
| profile::dns::slaves | A list over DNS slave-servers which replicates the zone-files from the main DNS server. The hash is structured as key=Servername and value=DNS-IPv4 | 'ns2.example.com': '192.0.2.130' | N/A | List of Hashes | role::bootstrap, role::dns::master, role::dns::slave |
| profile::dns::zones | A list over DNS zones managed by our DNS servers, or used by our dashboard. The hash is structured as key=DNS-zone and value=DNS-server-shortname. | 'zone.example.com': 'ns1' | N/A | List of Hashes | role::bootstrap, role::dashboard, role::dns::master, role::dns::slave |
I addition there are a set of keys which are needed for each DNS server managing a DNS zone used by us. Shortname is here the name used in "profile::dns::zones".
| Key | Description | Example | Created by | Data-type | Used by: |
|---|---|---|---|---|---|
| profile::dns::<shortname>::ipv4 | The IPv4 address of a specific DNS server. | '192.0.2.129' | N/A | String | role::bootstrap, role::dashboard, role::dns::master, role::dns::slave |
| profile::dns::<shortname>::name | The fqdn of a specific DNS server | 'ns1.example.com' | N/A | String | role::bootstrap, role::dns::master, role::dns::slave |
Dashboard
The general configuration of the dashboard are based on the following keys:
| Key | Description | Example | Created by | Data-type | Used by: |
|---|---|---|---|---|---|
| profile::dns::<shortname>::key | The TSIG key used for updates sent to this server. It can be useful to let this be a hiera-lookup for the zones managed by our own DNS servers. | 'UvetjoX5zMiw/NbQr3biug==' "%{hiera('profile::dns::key::update')}" | dnssec-keygen -a HMAC-MD5 -b 128 -n HOST <keyname> | String | role::dashboard |
profile::dashboard::api: 'http://%{hiera('profile::dashboard::name::v4only')}'
profile::dashboard::datadir: '/var/lib/machineadmin'
profile::dashboard::database::type: 'mysql'
profile::dashboard::database::name: '<mysql-database-name>'
profile::dashboard::database::user: '<mysql-database-user>'
profile::dashboard::database::pass: '<mysql-database-password>'
profile::dashboard::database::host: "%{hiera('profile::haproxy::management::ip')}"
profile::dashboard::database::grant: "%"
profile::dashboard::django::secret: '<pwgen -1 -y -s 50>'
profile::dashboard::ldap::url: 'ldaps://<ldaps-server>:636'
profile::dashboard::ldap::search_base: '<LDAP Search base>'
profile::dashboard::ldap::domain: '<LDAP domain>'
profile::dashboard::name: '<Main dashboard hostname (A and AAAA can be defined for this name)>'
profile::dashboard::name::v4only: '<v4-only dashboard hostname (Should only have an A record defined>'
The dashboard requires some service-specific keys in addition to the keys listed with each of the services:
profile::dhcp::servers:
'<server1-name>': '<server1-IP>'
- '<server2-name>': '<server2-IP>'
Redis
| Key | Description | Example | Created by | Data-type | Used by: |
|---|---|---|---|---|---|
| profile::redis::master | Name or IP address of initial redis master | 'redis1.cloud.domain.com' | N/A | String | role::redis |
| profile::redis::nodetype | Defined on each redis-node. Only valid values are 'master' or 'slave' | 'master' | N/A | String | role::redis |