[ Lab 4.1 ] Puppet: Managing MariaDB - smitja21/group-a-oe2 GitHub Wiki

[!NOTE] Ticket #33: Deploy and Manage MariaDB using Puppet on db-x

Note: The module mariadb file has been uploaded in the repo

Part 1: Module Structure and Manifests

Task 1: Verify prerequisites and create the module structure

Note: we had to set the MODPATH based on our config location.

Task 2: Write init.pp — the module entry point

Task 3: Write install.pp

Task 4: Write config.pp

Task 5: Write service.pp

Part 2: The Configuration File

Task 6: Create the 50-server.cnf configuration file

Downloaded config file, had to use sudo. Used sudo !!

Paste the output of find $MODPATH/mariadb -type f | sort.

find $MODPATH/mariadb -type f | sort
/opt/puppetlabs/puppet/modules/mariadb/files/etc/mysql/mariadb.conf.d/50-server.cnf
/opt/puppetlabs/puppet/modules/mariadb/manifests/config.pp
/opt/puppetlabs/puppet/modules/mariadb/manifests/init.pp
/opt/puppetlabs/puppet/modules/mariadb/manifests/install.pp
/opt/puppetlabs/puppet/modules/mariadb/manifests/service.pp

Validate all four manifests:

We had an issue with install.pp had forgotten to include add an end quote

Part 3: Apply the Module

Task 7: Add the mariadb module to db-x in site.pp

Task 8: Run the Puppet agent on db-x

Had issue config path contained 'myql' rather than 'mysql'.

Fixed issue and worked:

Which resources were applied and in what order? List them in sequence as they appear in your agent run output.
mariadb:install
mariadb:config
mariadb:service
The diff output in Figure ?? shows lines being added and removed from 50-server.cnf. What does this tell you about the file that was already on db-x before Puppet ran?

That it contained existing config which some was kept while some was replaced

Run the agent a second time immediately. How many resources change? Why?

Done was changed, since nothing had been modified since the last apply.

Part 4: Verify the Installation

Task 9: Verify the MariaDB service and version

What MariaDB version is installed on db-x?

Ver 15.1

What does sudo ss -tlnp | grep mariadb show? On which address and port is MariaDB listening? Does this match the bind-address in the config?

Listening on 127.0.0.1 (localhost), Port: 3306

Yes, it matches the config file:

Are there any errors or warnings in the log? No:

Task 10: Connect to MariaDB and run verification queries

Paste the output of SHOW DATABASES;. What databases are present after a fresh install? Which of these are system databases and which are potentially unsafe?

SHOW DATABASES;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| mysql              |
| performance_schema |
| sys                |
+--------------------+
4 rows in set (0.001 sec)

information_schema, mysql, performance_schema and sys are databases present after a fresh install

Don't believe any are unsafe as they are required for operations.

Paste the output of the SELECT user, host, plugin... query. How many user accounts exist? Are there any anonymous (”) users?

SELECT user, host, plugin, authentication_string FROM mysql.user;
+-------------+-----------+-----------------------+-----------------------+
| User        | Host      | plugin                | authentication_string |
+-------------+-----------+-----------------------+-----------------------+
| mariadb.sys | localhost | mysql_native_password |                       |
| root        | localhost | mysql_native_password | invalid               |
| mysql       | localhost | mysql_native_password | invalid               |
+-------------+-----------+-----------------------+-----------------------+

3 user accounts, nothere are no anonymous users.

What authentication plugin does the root account use? Why is unix_socket authentication more secure than a password for the root account in this context?

Root uses mysql_native_password auth plugin. unix_socket is a lot more secure as if someone gaines access to the password for your root account they have access to all your databases.

Part 5: Test Desired State Enforcement

Task 11: Simulate configuration drift and observe Puppet repair it

When you stopped the service and ran Puppet, what did the agent output show? Did it restart the service?

group-a@db-a:~$ sudo puppet agent --no-daemonize --verbose --onetime
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 '1773692697'
Notice: /Stage[main]/Mariadb::Service/Service[mariadb]/ensure: ensure changed 'stopped' to 'running  ' (corrective)
Info: /Stage[main]/Mariadb::Service/Service[mariadb]: Unscheduling refresh on Service[mariadb]
Notice: Applied catalog in 1.56 seconds

Yes, it started the service again: changed 'stopped' to 'running '

When you changed max_connections, did Puppet restore the original value? Paste the relevant agent output lines.

Yes it did

Notice: /Stage[main]/Mariadb::Config/File[/etc/mysql/mariadb.conf.d/50-server.cnf]/content: content   changed '{sha256}67db9de02360c843bfdd237e46173a12a6ca2ce284c5c927a2c5130bee6408c0' to '{sha256}5c9  64fe707c3ec74c1bd504ac9e060f6b983c45d525a52fabaef2cd22e54f22f' (corrective

Did Puppet restart MariaDB after restoring the config? Which relationship in the manifests caused this? Trace the chain: config file change → which arrow in init.pp? → service refresh.

        #Notification: when config changes, trigger a service refresh
        Class['mariadb::config']
        ~> Class['mariadb::service']
}

The config caused the service to reload

Consider a real-world scenario: a DBA manually increases max_connections to cope with a load spike at 2 AM. The next Puppet run at 3 AM reverts it. What processes or Puppet features would you use to prevent this while still managing the config file with Puppet?

Edit the config on mgmt server so it is persistent so that puppet des not override the config. Manually changing the config is not advised.