Official Puppet Mysql & MariaDB on CentOS

Published
1 min read

Hi all,

Today, I'm going to cover making the official puppetlabs-mysql usable with the MariaDB official repositories on CentOS. For some completely incomprehensible reason, the official MariaDB RPMs for CentOS6 don’t create the MariaDB folder in /var/run, meaning that we have to crack out a little hack to make the puppetlabs-mysql Puppet module work as it's intended.

The process will cover the following steps:

Manage the MariaDB package ourselves
Manually create the MariaDB rundir
Ensure proper ownership of the rundir

I'll assume you've already added the MariaDB repository to your copy of CentOS. If not, the excellent guides on the MariaDB website should be enough to get you started. I'm going to put the code directly into a node classification, but you can do it pretty much anywhere you like. If you need to use this code more than once, consider putting it in a definition or class of its own.

node 'puppet-mariadb.alexshepherd.me' {
    $mariadb_package_name = ‘MariaDB-Server’
    $mariadb_service_name = ‘mysql’

    package { "mysql-server":
        ensure =&gt; installed,
        name =&gt; $mariadb_package_name
    } -&gt;
    file { 'mysql_rundir':
        path =&gt; '/var/run/mysqld',
        ensure =&gt; directory,
        owner =&gt; 'mysql',
        group =&gt; 'mysql'
    } -&gt;
    class { '::mysql::server':
        package_manage =&gt; false,
        package_name =&gt; $mariadb_package_name,
        service_name =&gt; $mariadb_service_name
    }
}

It is important that we use this exact dependency sequence, and these exact options in order to make it work. Particularly, the puppetlabs-mysql module depends on a package called mysql-server, so we alias it using the name attribute on the package resource We also need to include package_name on ::mysql::server, as there are internal dependencies that cause issues if we don't set it, even though we choose specifically not to manage the package with the module.

Puppet, while an amazing tool that solves so many issues, does still feel a little hackish in places, but we wouldn't be managing servers if we minded performing the odd messy hack where appropriate! That's all for today - expect more devops-related posts moving forwards.