[ Lab 3.1 ] Creating Modules with Puppet - smitja21/group-a-oe2 GitHub Wiki

[!NOTE] Ticket #28: Deploy Puppet Modules for Sudo and MOTD Configuration

Build the sudo Module

Task 1: Verify prerequisites

everything is functional

sudo puppet config print modulepath

/etc/puppetlabs/code/environments/production/modules:/etc/puppetlabs/code/modules:/opt/puppetlabs/puppet/modules
group-a@mgmt-a:~$

Task 2: Create the module directory structure

Task 3: Write the init.pp manifest

Task 4:

  1. Copy the current sudoers file from the server

Puppet originally has only permission to read.

  1. Allow the puppet agent to read and write but not execute
  1. Run find $MODPATH/sudo
group-a@mgmt-a:~$ find $MODPATH/sudo
/opt/puppetlabs/puppet/modules/sudo
/opt/puppetlabs/puppet/modules/sudo/templates
/opt/puppetlabs/puppet/modules/sudo/manifests
/opt/puppetlabs/puppet/modules/sudo/manifests/init.pp
/opt/puppetlabs/puppet/modules/sudo/files
/opt/puppetlabs/puppet/modules/sudo/files/etc
/opt/puppetlabs/puppet/modules/sudo/files/etc/sudoers
group-a@mgmt-a:~$
  1. Open site.pp and inlude sudo
  1. on the database server, manual agent run

Part 2: Understanding Templates -- From Static to Dynamic

  1. Run sudo facter

This will need a symbolic link for the command to work

This provides information/facts about the mode to the puppet server

Facts in puppet code use dot notation in facter

Task 5: Explore facts on the agent nodes

  1. SSH into db-a and run facter

pipe to less for shortened information sudo facter | less

  1. Record the values of some facts from db-a
db-a
networking.hostname = db-a
networking.fqdn = db-a.oe2.org.nz
networking.ip = 10.2.0.7
os.distro.description = Ubuntu 24.04.4 LTS
processors.count = 2
  1. sudo facter on app-a. Are the networking.hostname and networking.ip facts different? What about os.distro.description?

For the facter command to be functional, each server needs the symbolic link: sudo ln -s /opt/puppetlabs/bin/facter /usr/local/bin/facter

on app-a: networking.hostname, is app-a - Different.

networking.ip, is 10.2.0.5 - Different

While the os.distro,description is the same as db-a: Ubuntu 24.04.4 LTS

Task 6: Create the motd module using an ERB template

  1. Create the module structure then create the ERB template
  1. Create init.pp for the motd module

Task 7: Apply the motd module to all nodes

  1. inlude motd to every node in site.pp
  1. Trigger manual agent run on db-a and app-a

3.1. What is the difference between content of etc/motd db-a and app-a

group-a@db-a:~$ cat /etc/motd
########################################################
# db-a
# IP Address : 10.2.0.7
# OS : Ubuntu 24.04.4 LTS
#
# This system is managed by Puppet.
# Unauthorised access is prohibited.
# Do not edit /etc/motd manually - changes will be
# overwritten on the next Puppet run.
########################################################
group-a@db-a:~$

########################################################
# app-a
# IP Address : 10.2.0.5
# OS : Ubuntu 24.04.4 LTS
#
# This system is managed by Puppet.
# Unauthorised access is prohibited.
# Do not edit /etc/motd manually - changes will be
# overwritten on the next Puppet run.
########################################################
group-a@app-a:~$

Difference is hostname and IP address

3.2

Info: Refreshing CA certificate
Info: CA certificate is unmodified, using existing CA certificate
Info: Refreshing CRL
Info: CRL is unmodified, using existing CRL
Info: Using environment 'production'
Info: Retrieving pluginfacts
Info: Retrieving plugin
Notice: Requesting catalog from mgmt-a.oe2.org.nz:8140 (10.2.0.4)
Notice: Catalog compiled by mgmt-a.oe2.org.nz
Info: Caching catalog for db-a.oe2.org.nz
Info: Applying configuration version '1773088411'
Notice: /Stage[main]/Motd/File[/etc/motd]/content: content changed '{sha256}b5209a74f1c3e0797f17f8126f533972e842e41df157efdda4783acc87812421' to '{sha256}ebce86c4b9a5652775e0f3d77894b5e9aecf45b0fd31d54cb72a450efad52ed6' (corrective)
Notice: Applied catalog in 0.53 seconds
group-a@db-a:~$

Has reapplied config:

########################################################
# db-a
# IP Address : 10.2.0.7
# OS : Ubuntu 24.04.4 LTS
#
# This system is managed by Puppet.
# Unauthorised access is prohibited.
# Do not edit /etc/motd manually - changes will be
# overwritten on the next Puppet run.
########################################################
group-a@db-a:~$

3.3. What does this say about how puppet enforces the desired state?

It dynamically checks the system and correcting any differences between the config and its current state

Part 3: Expand to All Nodes

Task 8: Register all agents with the Puppet Server

  1. Ensure certificates requests have been signed between agents to allow for communication.

Task 9: Add the sudo module to remaining Linux nodes

  1. Apply the include sudo on each node in site.pp
  1. Complete this table after running on all four nodes:
Node Sudo Applied MOTD Applied Errors
db-a Applied Applied N/A
app-a Applied Applied N/A
backup-a Applied Applied N/A
mgmt-a Applied Applied N/A

Task 10: Deliberately break and repair a managed resource

  1. Manually corrupt the sudoers file by simulating a misconfiguration of permissions
  2. Run puppet agent again
  3. Check permissions again
  1. What did puppet do to the sudoers file
group-a@db-a:~$ sudo puppet agent --no-daemonize --verbose --onetime
sudo: /etc/sudoers is world writable
sudo: error initializing audit plugin sudoers_audit
group-a@db-a:~$ sudo puppet agent --no-daemonize --verbose --onetime
[sudo] password for group-a:
Info: Refreshing CA certificate
Info: CA certificate is unmodified, using existing CA certificate
Info: Refreshing CRL
Info: CRL is unmodified, using existing CRL
Info: Using environment 'production'
Info: Retrieving pluginfacts
Info: Retrieving plugin
Notice: Requesting catalog from mgmt-a.oe2.org.nz:8140 (10.2.0.4)
Notice: Catalog compiled by mgmt-a.oe2.org.nz
Info: Caching catalog for db-a.oe2.org.nz
Info: Applying configuration version '1773094334'
Notice: Applied catalog in 0.45 seconds
group-a@db-a:~$ ls -l /etc/sudoers
-r--r----- 1 root root 1671 Mar  9 19:59 /etc/sudoers
group-a@db-a:~$
  1. Try a different break on db-a
  1. When might this behaviour be useful and when might it be problematic?

It would be useful in scenarios where unintentional changes are made in other servers like db-a which are then overwritten. In other scenarios, when a change was required and they had no permission/access to the management server, it would be problematic because their changes would be overwritten.

Part 4: Refactor with a Default Node and Common Class

Task 11: Use a common class to group shared modules

  1. in init.pp, add a module
  1. in site.pp the nodes can be simplified by only including the common module that contains the other modules
  1. Run the agent on all nodes again

[!IMPORTANT] $MODPATH only saves for the current session, so put it in .bashrc so $MODPATH transfers between sessions.

The issue was that without $MODPATH, the common module was saved in the wrong directory

  1. If you needed to add a new module (e.g. include ntp) to every node, how many files do you need to edit with the refactored structure vs the original?

In the original it would be four nodes (five if you include the default). Using the efficient refactored structure, only one node (the common module) needs the include ntp because the other nodes already use include common.

  1. What is the purpose of node default in site.pp? Under what circumstances would a node match the default block?

If a node is not manually specified, then it will still use common module.

  1. What potential risk exists in automatically applying the default node definition to every unknown node? How might you mitigate this in a production environment?

For example, if include sudo is included in a module and then is applied in the default node, then any unknown node will now have superuser permissions.