Create your first node: DNS

You can now create additional nodes and assign services via puppet. Included is a custom_fact and a site manifest that assigns roles to nodes based on the hostname. If the hostname matches the format role[##], the role is applied. For instance, our node called puppet received the role called puppet. Another node named puppet2 would receive the same role. The provided roles are:

• dns: single server, can handle multiple zones via hiera
• dhcp: single server, can handle multiple scopes and reservations via hiera
• puppet: all in one puppet master, hiera, and puppetdb roles
• build: includes FPM, rspec-puppet and puppetlabs_spec_helper (via RVM for CentOS 6.5), gcc, and rpmbuild. No managed git server is provided, the use of GitHub is encouraged for persistent repositories.
• yumrepo: Create yum repositories based on hiera data. Manages underlying directory structure as well
• webserver: generic Apache web server role. It can be improved upon or used as a base to build more specific roles targeted to specific apps
• mysql: MySQL database server with client. Requires an additional 41GB of unused space on the existing drive (more info).
• phpmyadmin: phpMyAdmin, a web interface for a MySQL database
• tftp: TFTP server for PXE boot/Auto Deploy or to host network device firmware updates.

DNS is required for almost everything, which makes it a great starting point. Without it, every node will need hosts entries, as we had to add to the puppet node during bootstrapping. This is the second node you should create.

Create a new node called dns or dns01 (suggested IP 10.0.1.253). Because DNS is not available yet, be sure to apply the hosts entries from the controlrepo before continuing. Use SCP, git clone, or just cat/vi to create the file on the new node. Modify the IPs in the file first if you are not using 10.0.1.0/24:

puppet apply hosts_add.pp

Next, we will assign it a zone file. This is done via hiera and the lab_config module. The provided hiera in the controlrepo will generate a zone file for example.com, using the contents of [files/dns/example.com] (https://github.com/puppetinabox/lab_config/blob/master/files/dns/example.com) (forward) and [files/dns/1.0.10] (https://github.com/puppetinabox/lab_config/blob/master/files/dns/1.0.10) (backward) from lab_config. If you are using the example network, then no changes are required. If you are using another network, adjust the contents of these files and commit/push the changes to the master branch of lab_config and re-run r10k, adding the environment name this time:

r10k deploy environment production -p

On the new dns node, run puppet:

puppet agent -t

On the puppet node, a certificate will be generated that needs signed. Use the following commands to list the cert and then sign it with the full name (ex: dns.example.com):

puppet cert list
puppet cert sign "dns.example.com"

Run the agent on dns again:

puppet agent -t

There is an outstanding bug with the thias/bind module related to resource ordering. Until the PR is merged, you may need to run puppet agent -t once more to complete the setup.

Now that the cert is signed, re-run puppet on dns and the DNS service will be installed, configured, provided the zone file(s), and started. You can now point a DNS client at the the IP of dns and resolve puppet, dns, and other records as provided in the zone files.

[root@dns ~]# nslookup
> server 127.0.0.1
Default server: 127.0.0.1
Address: 127.0.0.1#53
> build.example.com
Server:         127.0.0.1
Address:        127.0.0.1#53

Name:   build.example.com
Address: 10.0.1.10
> exit

You should update your VM templates to point to the IP of dns. You should also login as padmin and use sudo instead of direct root access.

Finally, enable the puppet service. This will force the node to check in once per interval (default 30m):

sudo systemctl start puppet
sudo systemctl enable puppet

To update the zone files, changes are made to the contents in the lab_config repository (and pushed upstream!), r10k is rerun on the master, and puppet is rerun on dns. If the changes are not urgent, the last step can be skipped and dns will pick up the changes on its next checkin, within 30 minutes.

Now that the DNS service exists, you can remove the hosts entries on dns using the hosts_remove.pp file from the controlrepo:

sudo puppet apply hosts_remove.pp